Eine nur per VPN erreichbare HTTPS-Seite über eine SSH-Weiterleitung erreichen

Eine Maschine hat bereits genehmigten VPN-Zugriff, eine zweite Maschine braucht genau einen privaten HTTPS-Dienst, und eine lokale SSH-Weiterleitung kann diese Lücke überbrücken, ohne der zweiten Maschine einen Tunnel zu geben. Die Weiterleitung trägt ein einziges TCP-Ziel statt des ganzen Netzes, und genau diese Grenze ist der Punkt. Arbeiten Sie die fünf Schritte unten der Reihe nach ab, denn jeder scheitert aus einem anderen Grund, und ein späterer Schritt kann eine frühere Lücke nicht retten. Fehlt eine Voraussetzung, löst dieses Design sie nicht, und keine noch so gute Befehlseinstellung hilft.

Schritt eins: die drei Voraussetzungen bestätigen

Drei Dinge müssen bereits zutreffen, bevor ein Befehl eine Rolle spielt. Sie brauchen die Erlaubnis, die erste Maschine als Weiterleitungshost zu nutzen, funktionierenden SSH-Zugang zu ihr und eine Serverrichtlinie, die das beabsichtigte Ziel erlaubt. Ein SSH-Konto, das für Dateiübertragung angelegt wurde, kann Weiterleitung deaktiviert haben, und ein Server, der Weiterleitung erlaubt, kann dennoch einschränken, welche Ziele darüber erreichbar sind. Fragen Sie vor dem Test, denn eine Arbeitsstation eines Kollegen ohne Absprache als Sprungpunkt zu nutzen ist ein Richtlinienproblem, selbst wenn der Befehl einwandfrei läuft.

Zwei Befehle klären die technische Hälfte dieser Liste. Der erste belegt, dass Konto und Schlüssel ohne interaktive Abfrage funktionieren, und der zweite gibt die tatsächlich wirksame Serverrichtlinie aus statt des auskommentierten Beispiels in der Konfigurationsdatei.

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

Schritt zwei: einen Loopback-Port binden und die Sitzung am Leben halten

Öffnen Sie auf der Maschine, die die Client-Anwendung ausführt, eine lokale Weiterleitung zum privaten Dienst. Binden Sie sie ausdrücklich an Loopback, damit sie nicht im lokalen Netz veröffentlicht wird, und wählen Sie einen hohen Port, den kein lokaler Dienst bereits belegt. Halten Sie die Sitzung während der Arbeit offen, denn ihr Ende beendet auch den Listener. ExitOnForwardFailure macht aus einer abgelehnten Bindung oder einem belegten Port einen sofortigen Abbruch statt einer Sitzung, die ohne Weiterleitung bestehen bleibt, und das ist der Fehlermodus, der die meiste Zeit kostet.

Die private Verbindung wird vom Sprunghost aus aufgebaut, also müssen dessen DNS, Routen, VPN-Richtlinie und Dienstzugang alle funktionieren. Die SSH-Sitzung erzeugt keine Erreichbarkeit, die dem Sprunghost fehlt, und sie kann keine Route reparieren, die das VPN nie geschoben hat. Bestätigen Sie den Listener dort, wo er tatsächlich ist, statt sich auf die Stille des Befehls zu verlassen.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

Schritt drei: den HTTPS-Namen behalten, wenn der Socket lokal ist

Der Aufruf von https://127.0.0.1:9443/ ändert den TLS-Servernamen und die Anwendungsautorität. Ein für portal.lab.example ausgestelltes Zertifikat validiert nicht gegen eine Loopback-Adresse, und der resultierende Fehler sieht wie ein kaputtes Zertifikat aus statt wie eine Weiterleitungsabkürzung. Behalten Sie für einen Kommandozeilentest die echte URL und ändern Sie nur das Socket-Ziel. Das ist, was --connect-to tut, und das curl-Handbuch dokumentiert die unten verwendete Vier-Felder-Form.

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

Der Name bleibt in der URL, im TLS-Handshake und im Host-Header, während die TCP-Verbindung zum lokalen Listener geht. Die Ohne-Proxy-Option hält den Test auf dieser Weiterleitung, statt einen konfigurierten HTTP-Proxy eingreifen zu lassen, und die Zertifikatsprüfung eingeschaltet zu lassen ist es, was das Ergebnis aussagekräftig macht.

Schritt vier: wissen, was eine Weiterleitung nicht abdeckt

Eine einzelne TCP-Weiterleitung deckt einen Zielport ab. Eine Seite, die auf einen zweiten Hostnamen umleitet, Ressourcen von einem Host im privaten Netz lädt oder an einen anderen Port sendet, braucht ihre eigene Weiterleitung, und jede davon braucht dieselbe Richtlinienprüfung wie die erste. Browser-Abläufe bringen eigene Anforderungen mit, denn dem Browser muss über eine Proxy-Konfiguration oder ein lokales Mapping gesagt werden, den echten Namen an den lokalen Port zu senden. Ein erfolgreicher Kommandozeilentest beweist daher nicht, dass der Browser es schafft, auch wenn er den Weg belegt.

UDP, SMB-Erkennung und Domänenanmeldung laufen überhaupt nicht durch eine TCP-Weiterleitung. Ist die eigentliche Anforderung allgemeiner Netzzugang, ist dieses Design das falsche Werkzeug und ein unterstütztes Fernzugriffs-Gateway das richtige.

Schritt fünf: aufräumen und dokumentieren

Beenden Sie die Sitzung, wenn der Test fertig ist, und bestätigen Sie, dass der Listener weg ist. War der gewählte Port bereits belegt, wählen Sie einen anderen ungenutzten Loopback-Port und aktualisieren URL, Testbefehl und Notiz gemeinsam, statt einen fremden lokalen Dienst zu beenden, um die Nummer freizugeben. Eine offen gelassene Weiterleitung auf einem Laptop macht aus einer Diagnose einen unverwalteten Dienst.

Notieren Sie Sprunghost, weitergeleitetes Ziel, lokalen Port und wer die Vereinbarung genehmigt hat. Eine Weiterleitung, die nur in der Shell-Historie von jemandem existiert, ist einen Neustart von einer erneuten Untersuchung entfernt, und die nächste Person wird nicht wissen, welche der drei Voraussetzungen bereits geprüft wurde.