sshuttle gegen ein vollwertiges VPN: was seine Methode wirklich abdeckt
sshuttle überträgt nur, was seine Weiterleitungsmethode unterstützt: Prüfen Sie zuerst die Abdeckung von TCP, DNS und UDP, die nötigen lokalen Rechte und den entfernten Helfer.
sshuttle wird gewählt, weil SSH bereits funktioniert und die Kryptografie vertraut aussieht, und diese Begründung überspringt die einzige Frage, die über die Eignung entscheidet. Welche Pakete die Maschine verlassen, welches Konto sie auf der Gegenseite trägt und wie viele lokale Rechte das Werkzeug verlangt. Diese drei Antworten unterscheiden sich je nach Weiterleitungsmethode, deshalb kann ein Aufbau, der für eine Anwendung funktioniert, für die nächste still scheitern. Der Durchgang unten beginnt bei dem Protokoll, das die Anwendung tatsächlich braucht.
Beginnen Sie beim Protokoll, das die Anwendung braucht
Die Protokollunterstützung in sshuttle 2.0 hängt von der gewählten Methode ab. Die Linux-Methoden NAT und nft behandeln TCP und DNS, und TPROXY ergänzt allgemeines UDP. Jede Plattform und jede Methode bringt eigene Grenzen mit, und macOS fängt über einen völlig anderen Mechanismus ab. Notieren Sie die installierte Version, die gewählte Methode und die Protokolle, die die Anwendung braucht, bevor Sie etwas wählen.
Eine funktionierende TCP-Anfrage beweist daher sehr wenig über eine UDP-Anwendung oder über jede DNS-Abfrage. sshuttle behandelt TCP außerdem als Ströme, statt ganze IP-Pakete zu tunneln, sodass eine von einem herkömmlichen VPN entliehene Durchsatzschlussfolgerung nicht übertragbar ist. Vergleichen Sie den Mechanismus, den Sie tatsächlich betreiben, mit der Last, die Sie tatsächlich haben.
| Approach | What it carries | What it needs locally |
|---|---|---|
| SSH local forward | One explicitly named TCP destination | Nothing beyond the SSH client |
| sshuttle, nft or nat method | TCP and DNS to the routed prefixes | Root or sudo for firewall rules |
| sshuttle, tproxy method | TCP, DNS and general UDP | Root or sudo, and kernel support |
| IP VPN | Routed IP traffic in a tunnel | A client with the required privileges |
Was der Client lokal braucht
Der dokumentierte Clientaufbau benötigt root oder sudo, weil er lokale Abfangregeln installiert, statt eine Tunnelschnittstelle zu erzeugen. Diese eine Tatsache verändert die Sicherheitsgeschichte: Ein Prozess mit diesem Recht kann den Verkehr der ganzen Maschine umleiten, nicht nur den einer Anwendung. Behandeln Sie das Recht als Teil des Entwurfs und nicht als Installationsdetail.
Bestätigen Sie, welche Regeln das Werkzeug installiert hat und dass sie beim Beenden verschwinden. Eine abgestürzte Sitzung, die Abfangregeln hinterlässt, kann Verkehr noch lange nach dem Zeitpunkt ins Leere laufen lassen, an dem der Betreiber den Verbindungsabbau annimmt, und das Symptom sieht wie ein Netzausfall aus, nicht wie eine übrig gebliebene Regel.
sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip route
Der erste Befehl zeigt die Form eines typischen Aufrufs mit dem Präfix, das Sie tatsächlich brauchen. Der zweite zeigt, was das Werkzeug installiert hat, und der dritte bestätigt, dass keine Tunnelschnittstelle erschienen ist, was für diesen Entwurf das erwartete Ergebnis ist.
Was die Gegenseite ausführt
Die Gegenseite ist ein autorisiertes SSH-Konto plus eine kompatible Python-Hilfsumgebung. Eine Anmeldung, die unter einer eingeschränkten Shell gelingt, erteilt nicht automatisch die Erlaubnis, diesen Helfer auszuführen, und ein Konto, das den Helfer ausführen kann, erreicht nicht automatisch jeden Zieldienst. Beide Tatsachen gehören in die Zugriffsanfrage und nicht in die Fehlerbehebungsnotizen.
Schützen Sie die Prüfung der Hostidentität und die Authentifizierung des Kontos. Wer einen unbekannten Hostschlüssel annimmt, damit die erste Verbindung klappt, entfernt die Prüfung, dass die Gegenseite die beabsichtigte Maschine ist, und das wiegt hier schwerer als bei einer Weiterleitung für einen einzigen Zweck.
Beschränken Sie das entfernte Konto auf die Dienste, die der Arbeitsablauf braucht, und verhandeln Sie diesen Umfang mit den Betreibern des Hosts. Sie sind Teil der Vertrauensbeziehung, und keine Einstellung auf Clientseite ändert das.
Wo die Vertrauensgrenze liegt
Die Weiterleitung einer privaten API-Verbindung über SSH berechtigt nicht zu jeder API-Operation. Anwendungs-TLS und Anmeldung in der Anwendung gelten weiterhin, und das Werkzeug kann einen nicht authentifizierten Dienst nicht sicher machen. Auch ein weiterer Sprung vom entfernten Host ist nicht automatisch dasselbe geschützte Segment wie der SSH-Kanal, weil diese zweite Verbindung der Richtlinie folgt, die der entfernte Host hat.
Schreiben Sie die Grenze als einen Satz: Verkehr zu diesen Präfixen verlässt sie über dieses Konto auf jenem Host. Braucht der Satz einen Absatz voller Ausnahmen, leistet der Entwurf mehr, als seine Dokumentation behauptet, und verdient einen zweiten Blick, bevor er die Produktion erreicht.
Beweisen Sie es je Protokoll und wählen Sie dann das Werkzeug
Prüfen Sie jedes benötigte Protokoll mit einer harmlosen Anfrage, einschließlich des Resolverpfads und der Adressfamilien, die die Anwendung nutzt. Nehmen Sie einen Verbindungsabbruch in den Test auf, damit das erlaubte Fehlerverhalten der Anwendung ein bekanntes Ergebnis wird statt einer Überraschung im Störfall. Eine Sitzung, die während ihres Bestehens korrekt weiterleitete, sagt nichts darüber, was nach ihrem Abriss geschieht.
Für eine Handvoll ausdrücklich genannter Dienste ist eine gewöhnliche lokale Weiterleitung leichter zu besitzen und leichter zu prüfen. Für Anwendungsverkehr, der zu seiner Methode passt, bietet sshuttle einen legitimen Mittelweg. Ist die Anforderung breite IP-Konnektivität, ist ein VPN-Entwurf die ehrliche Antwort, und die Wahl folgt Abdeckung und betrieblicher Verantwortung statt einer Rangliste von Verschlüsselungsalgorithmen.