Welchen App-Verkehr trägt eine SSH-Weiterleitung tatsächlich?

Eine Shell, eine lokale Weiterleitung, SOCKS und der Tunnelgerät-Modus stellen unterschiedliche Schnittstellen bereit. Benennen Sie die, die Ihre App nutzen kann, bevor Sie sie mit einem gerouteten VPN vergleichen.

Das Terminal verbindet sich, die Eingabeaufforderung erscheint, und alle sind sich einig, dass der SSH-Zugang funktioniert. Dann erreicht ein Datenbankclient auf dem Laptop den privaten Host immer noch nicht, und die Sitzung wird beschuldigt. Gebaut wurde eine Shell, und die ist eine von vier recht unterschiedlichen Schnittstellen, die SSH anbieten kann. Benennen Sie zuerst die Schnittstelle und prüfen Sie dann, ob die Anwendung sie wirklich nutzt. Die Reihenfolge zählt, denn jede Schnittstelle scheitert auf ihre eigene Weise.

Benennen Sie die Schnittstelle, bevor Sie irgendetwas vergleichen

Das Handbuch des OpenSSH-Clients unterscheidet vier Mechanismen, die leicht verwechselt werden. Eine Shell oder ein entferntes Kommando läuft auf dem SSH-Host. Eine lokale Weiterleitung öffnet einen lauschenden Socket auf dem Client und stellt die weitere Verbindung von der entfernten Seite her. Eine entfernte Weiterleitung macht das Gegenteil und lauscht auf der Serverseite. Die dynamische Weiterleitung stellt einen SOCKS-Endpunkt für Programme bereit, die damit umgehen können.

  • Shell: das Programm läuft auf der entfernten Maschine, lokal lauscht nichts.
  • Lokale Weiterleitung: Ihr Laptop hat einen Port, der entfernte Host baut die ausgehende Verbindung auf.
  • Entfernte Weiterleitung: die entfernte Seite hat einen Port, der Verkehr kommt zu Ihnen zurück.
  • Dynamisch: ein SOCKS-Proxy auf dem Client, nur von proxyfähigen Anwendungen genutzt.

Nichts davon installiert eine Route. Ein Programm, das Proxy-Einstellungen ignoriert, UDP spricht oder Namen selbst auflöst, bleibt von einer aktiven SSH-Sitzung unberührt. Das ist kein Fehler in SSH; es ist der Umfang der Schnittstelle, für die Sie sich entschieden haben.

Lokale, entfernte und dynamische Weiterleitungen unterscheiden sich darin, wer lauscht

Der Unterschied, der die meisten Fälle entscheidet, ist, wer den lauschenden Socket besitzt. Bei einer lokalen Weiterleitung lauscht der Client, und das ferne Ende wählt das Ziel an, weshalb die Zieladresse aus Sicht des Servers aufgelöst wird. Bei einer entfernten Weiterleitung lauscht der Server, und die Verbindung wird zu Ihrer Seite zurückgetragen, und so stellen Sie einen lokalen Dienst bereit, ohne ihn direkt zu veröffentlichen.

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

Der erste Befehl bindet Port 5432 auf dem Laptop und leitet ihn an die Datenbank weiter, wie sie von der Bastion aus gesehen wird. Der zweite erzeugt einen SOCKS-Proxy auf Port 1080. Der dritte Befehl bestätigt, welche Prozesse tatsächlich lauschen, und das ist der einzige Beweis, dass die Weiterleitung existiert und nicht wegen eines Portkonflikts still gescheitert ist.

Die dynamische Weiterleitung verdient eine eigene Warnung: sie deckt nur Anwendungen ab, die SOCKS respektieren. Ein Browser lässt sich darauf richten, einem Kommandozeilenwerkzeug kann man sagen, es solle sie nutzen, und ein Datenbanktreiber mit eigenem Verbindungsstapel kann das meist nicht. Die Annahme, dass nun jedes Programm auf der Maschine den Tunnel nutzt, ist der häufigste Fehler in diesem ganzen Bereich.

Der Tunnelgerät-Modus ist die einzige echte Netzwerkausnahme

OpenSSH unterstützt außerdem die Tunnelgerät-Weiterleitung -w, die eine Punkt-zu-Punkt-Schnittstelle statt eines TCP-Listeners durchreicht. Das ist ein echter Netzwerktunnel, und er wird bewusst konfiguriert, nicht als Nebenwirkung des Öffnens einer Shell.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

Er braucht die entsprechenden Schnittstellennummern an beiden Enden, die richtige Konfiguration auf dem Server und ausreichende Rechte auf dem Client, um das Gerät zu erzeugen. Er braucht außerdem einen Adressierungs- und Routingplan, denn eine nackte Schnittstelle trägt keine Vorgabe darüber, welche Ziele sie nutzen sollen.

Selbst dann endet der Tunnel am fernen Host. Welchen Schutz der SSH-Transport auch bot, er endet dort, und die weitere Verbindung ist ein eigener Sprung. Ein VPN-Gateway hat dieselbe Form der Grenze, weshalb der Vergleich Umfang und Endpunkt betreffen sollte und nicht die Frage, welches Werkzeug stärker ist. Diese Grenze laut zu benennen beendet auch den Streit darüber, ob ein Tunnel „alles verschlüsselt“, denn das tut er offensichtlich nicht.

Prüfen Sie, dass Ihre Anwendung die Schnittstelle nutzt, die Sie gebaut haben

Die Prüfung erfolgt je Anwendung, nicht je Sitzung. Eine funktionierende Weiterleitung beweist, dass der Port gebunden ist und die ferne Seite anwählen kann; sie beweist nicht, dass das Programm, das Ihnen wichtig ist, darüber verbunden hat.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

Der erste Befehl schickt eine Anfrage über den SOCKS-Endpunkt, wobei der Hostname entfernt aufgelöst wird, und der zweite übt den weitergeleiteten Datenbankport mit weiterhin erforderlichem TLS. Führen Sie dieselben Tests bei gestoppter Weiterleitung aus, um zu bestätigen, dass sie scheitern, denn ein Test, der beide Wege besteht, hat den Tunnel nie benutzt.

Vergleichen Sie dann mit einem gerouteten VPN nur in den Dimensionen, die zählen: welche Ziele abgedeckt sind, welche Protokolle funktionieren, wo der Schutz endet und wer den Zugang genehmigen muss. Eine Weiterleitung für einen einzelnen Dienst kann die engere und bessere Antwort sein, während ein VPN die richtige Form ist, wenn viele Anwendungen denselben Netzwerkpfad brauchen. Keines von beiden gewährt alles, was von seinem fernen Endpunkt erreichbar ist.

Ähnliche Artikel