SSH-Lokalweiterleitung zu einem vorhandenen HTTP-Proxy: zwei Loopback-Adressen

Ihr freigegebener Proxy läuft auf einem Sprunghost, wo er nur auf Loopback lauscht, sodass nichts außerhalb dieser Maschine ihn erreichen kann. Sie brauchen kein VPN und keinen neuen Proxy; Sie brauchen einen Port dieser Maschine, herübergetragen zu einem Port bei Ihnen. Eine lokale Weiterleitung macht genau das, und sie kostet einen Befehl plus eine Anwendungseinstellung. Die Verwirrung entsteht meist daraus, dass man verwechselt, welche Loopback-Adresse zu welcher Maschine gehört.

Entscheiden Sie, ob schon ein fester Proxy existiert

Diese Technik leitet einen Dienst weiter, der bereits läuft. Hat der entfernte Host nur einen SSH-Daemon und keinen Proxy, erzeugt keine Menge an Weiterleitung einen, und die Verbindung wird von der Gegenseite abgelehnt. Prüfen Sie, ob der Proxy gebunden ist, welchen Port er nutzt und ob er auf 127.0.0.1 oder auf einer bestimmten Interface-Adresse lauscht, denn genau diese Adresse muss die Weiterleitung anzielen.

Wenn Sie das zuerst prüfen, ersparen Sie sich die Fehlersuche an einem Tunnel, der nie mit etwas verbunden war.

Bauen Sie die Weiterleitung und lesen Sie den Befehl

Die gewünschte Form bindet einen Loopback-Port auf Ihrem Laptop und verbindet ihn von der Serverseite aus mit der Adresse des Proxys, wie der Server sie sieht.

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N unterdrückt einen entfernten Befehl, und -T unterdrückt die termios-Zuweisung, weil Sie einen Tunnel und keine Shell wollen. Die erste Loopback-Adresse ist die, auf der der Laptop lauscht; die zweite wird vom SSH-Server aufgelöst, sodass 127.0.0.1 dort den Proxy auf jener Maschine meint. ExitOnForwardFailure lässt den Befehl laut scheitern, wenn der lokale Port schon belegt ist, statt eine Sitzung zu starten, die nichts weiterleitet. Schreiben Sie die Zieladresse so, wie der Server sie auflöst, denn ein Name, den nur Ihr Laptop auflösen kann, wird auf der Gegenseite scheitern.

Die eigene Politik des Servers gilt, bevor irgendetwas davon funktioniert. AllowTcpForwarding muss es erlauben, und PermitOpen kann einschränken, welche Ziele und Ports eine Sitzung erreichen darf, sodass eine Weiterleitung, die der Client akzeptiert, vom Server trotzdem abgelehnt werden kann. Die Ablehnung erscheint als Weiterleitungs- oder Kanalfehler beim Client, und diese Meldung zu lesen ist schneller, als den Befehl zu ändern.

Richten Sie eine Anwendung auf die Weiterleitung

Konfigurieren Sie die Anwendung so, dass sie einen HTTP-Proxy unter http://127.0.0.1:13128 verwendet, mit Anmeldedaten, falls der entfernte Proxy sie verlangt. Behalten Sie die eigene Zertifikatsprüfung der Anwendung für HTTPS-Ziele bei, denn der Proxy-Tunnel ersetzt sie nicht. Dies ist eine feste Weiterleitung eines Dienstes, also muss der Anwendung ein Proxy mitgeteilt werden, statt sie einen selbst entdecken zu lassen.

Ein schneller Test, bevor Sie etwas Dauerhaftes konfigurieren: curl -x http://127.0.0.1:13128 -I https://example.com, was die HTTP-CONNECT-Methode ausübt, die der Proxy unterstützen muss.

Lassen Sie die Autorität, wo sie war

Der entfernte Proxy entscheidet weiterhin, welche Ziele und Methoden er zulässt, und eine SSH-Anmeldung sollte nicht stillschweigend jedem Konto ein allgemeines Web-Relay geben. Die Bindung an 127.0.0.1 auf dem Laptop vermeidet, den Port in Ihrem lokalen Netz bekannt zu machen, und sie macht den Port nicht privat gegenüber anderen Prozessen auf derselben Maschine. Diese Bindung durch eine Wildcard-Adresse zu ersetzen, um den Proxy zu teilen, ist der Weg, auf dem ein unverwaltetes offenes Relay entsteht.

Der SSH-Transport schützt den Sprung zum Server. Danach öffnet der Proxy seine eigene Verbindung, sodass eine einfache HTTP-Anfrage an ein Ziel jenseits des Servers einfach bleibt, obwohl das erste Teilstück verschlüsselt war.

Prüfen Sie beide Enden, dann räumen Sie auf

Lokaler Tunnelaufbau und Erfolg des entfernten Dienstes sind verschiedene Ergebnisse, und der Exit-Status des Befehls sagt Ihnen nur etwas über das erste. Prüfen Sie mit ss -ltn, ob der Listener existiert, und stellen Sie dann eine erlaubte Anwendungsanfrage und eine Anfrage, die der Proxy ablehnen sollte. Verhalten sich beide wie erwartet, ist der Weg real; steht der Tunnel und scheitert jede Anfrage, lehnt der Proxy ab oder erreicht das Ziel nicht.

Wenn Sie fertig sind, stoppen Sie den besitzenden SSH-Prozess, entfernen Sie die Proxy-Einstellung aus der Anwendung und bestätigen Sie, dass der lokale Port weg ist, statt einen Listener zu hinterlassen, der die Aufgabe überlebt.