Reverse-Tunnel für den Zugriff auf externe API auf einem Firewall-Server, auf den nur über Bastion zugegriffen werden kann

869
Trevor Hartman

Wenn der Titel verwirrend klingt, ist er sehr verwirrt. Hier ist die Situation:

  1. Ich habe einen Prod-Server prod1, der eingehenden / ausgehenden Datenverkehr von / zu dem gesamten externen Internet durch eine Firewall blockiert
  2. Die einzige Möglichkeit, SSH auf diesen Server zu setzen, besteht darin, zunächst auf eine interne Bastion zu setzen bastion.foo.com, dann ssh mit sshconfig, z ProxyCommand ssh -W %h:%p bastion.foo.com.

Auf prod1Ich möchte ein API - Endpunkt zB in der Lage Hit werden curl -I https://api.com(der Port verwendet 443, wie es https ist) durch irgendwie zu diesem Server meine SSH - Verbindung getunnelt durch (nur, wenn ich natürlich verbunden bin). Nachdem ich einige Blogeinträge gelesen hatte, dachte ich, dass RemoteForward die Antwort war:

Host prod1 HostName ... User ... IdentityFile ... RemoteForward 443 api.com:443 ProxyCommand ssh -W %h:%p bastion.foo.com

Aber wenn ich ssh prod1das erste sage, sagt der Server:

Warnung: Remote-Port-Weiterleitung für Listen-Port 443 fehlgeschlagen

Wie mache ich das, was ich versuche? Bin ich auf dem richtigen Weg?

1

1 Antwort auf die Frage

1
Jakuje

Es gibt wirklich nette Zeichnung, die RemoteForwardin openssh erklärt . Die Remote-Weiterleitung ist in Ihrem Anwendungsfall jedoch wahrscheinlich komplizierter als Sie beschreiben.

Sie müssen mindestens ändern /etc/hosts, um es für Ihre Anwendung ein wenig transparent zu machen:

127.0.0.1 api.com

Oder ändern Sie Ihre Anwendung so, dass sie sich direkt mit localhost anstatt mit api.com verbindet.

Und bitte beachten Sie das

Privilegierte Ports können nur weitergeleitet werden, wenn Sie sich als Root auf dem Remote-Computer anmelden.

von man ssh_config(5). Das bedeutet, dass Sie Port 443 nicht ohne Root-Privilegien binden können (oder sogar andere Mechanismen wie SELinux können Sie daran hindern). Sie benötigen diese Berechtigungen, oder Sie sollten sich einen anderen lokalen Port aussuchen, wodurch dieser für Ihre Anwendung noch weniger transparent wird.

Großes Diagramm; so viel hilfreicher als docs und blog posts! Mit Ihrem `/ etc / hosts'-Vorschlag und dem Umstieg auf Port 4433 ist dies gelungen! Vielen Dank. Ich dachte, die Bastion / der Stellvertreter würde stören, aber anscheinend hatte es keinen Einfluss. Trevor Hartman vor 8 Jahren 0

Verwandte Probleme