HTTP-Proxy, SSH-Tunnel oder VPN: die richtige Schicht wählen

Fragen Sie drei Ingenieure, wie man einen internen Dienst erreicht, und Sie erhalten drei Entwürfe: einen Web-Proxy, einen SSH-Tunnel oder ein volles VPN. Alle drei bringen einen entfernten Dienst in Reichweite, und alle drei lassen Verkehr so aussehen, als käme er von woanders. Die Unterschiede zeigen sich später, wenn das verwendete Protokoll nicht das ist, das das gewählte Werkzeug annimmt. Ein Entwurf, der eine schnelle Browserprüfung besteht, scheitert regelmäßig an der Anwendung, die die Anfrage ausgelöst hat.

Entscheiden Sie nach zwei Tatsachen: welche Protokolle passieren müssen und wer die beteiligten Namen auflösen kann. Alles andere ist Vorliebe.

Ein Proxy bewegt nur, was er versteht

Ein Web-Proxy wertet das Protokoll aus, für das er gebaut wurde. Der Client übergibt ihm eine Anfrage, und er gibt diese Anfrage weiter, sodass eine Anwendung ohne Proxy-Einstellung gar nicht teilnimmt. Für HTTPS braucht der Client einen undurchsichtigen Kanal, den der Proxy über CONNECT bereitstellt, statt die Anfrage zu lesen.

Eine dynamische SSH-Weiterleitung öffnet einen lokalen Port, der SOCKS spricht, und dieser Port leitet einen TCP-Strom an jedes Ziel weiter, das der Client benennt. Auf TCP aufgebaute Protokolle funktionieren meist darüber. UDP nicht, es sei denn, ein Werkzeug ergänzt die Unterstützung ausdrücklich. Eine lokale Weiterleitung ist noch enger: ein lokaler Port auf einen festen Host und Port abgebildet, was einem einzigen bekannten Dienst dient und nichts weiter.

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

Ein VPN bewegt Pakete. Alles, was der Client in den Tunnel leitet, durchquert ihn, UDP und ICMP eingeschlossen, deshalb passt es zu einer Netzwerkanforderung und nicht zu einer einzelnen Verbindung.

Irgendwer muss den Namen auflösen

Wenn der Zielname nur im DNS des entfernten Netzes existiert, muss die Maschine, die die Abfrage ausführt, diese Zone sehen können. Ein Web-Proxy führt die Abfrage selbst aus, sodass ein interner Name darüber funktioniert, selbst wenn der Laptop den Namen überhaupt nicht auflösen kann. SOCKS kann sich genauso verhalten, aber nur wenn der Client den Namen weiterreicht, statt sich mit einer bereits aufgelösten Adresse zu verbinden. Diese Entscheidung liegt im Client, nicht im Server.

curl zeigt die Trennung deutlich: ein Schalter übergibt den Hostnamen an den Proxy, ein anderer löst ihn zuerst lokal auf. Bei lokaler Auflösung scheitert ein nur interner Name, bevor irgendein Tunnel berührt wird, und der Fehler gibt dem Proxy die Schuld an etwas, das in Wahrheit eine DNS-Entscheidung war.

Ein VPN nimmt den dritten Weg, indem es den privaten Resolver und die Suchdomäne neben den Routen installiert. Das ist bequem, und es erzeugt eine vertraute Illusion: eine Route, die mit einem Resolver existiert, der nicht antwortet, sieht genau wie ein toter Tunnel aus, obwohl Pakete die Gegenseite erreichen.

Wenn das Netz nur einen Ausgang erlaubt

Viele Unternehmensnetze erlauben ausgehende Verbindungen nur über einen authentifizierten Web-Proxy. OpenVPN und SSH lassen sich dort beide zum Laufen bringen, ersteres indem sein eigener Transport durch den Proxy getunnelt wird, letzteres über einen Proxy-Befehl, der einen kleinen CONNECT-Helfer ausführt.

Auf TCP aufgebaute Tunnel überstehen diese Einschränkung, ein UDP-basiertes VPN nicht, was sehr viele Konfigurationen erklärt, die zu Hause funktionieren und im Büro scheitern. Ein zweiter Preis ist leicht zu übersehen: Ein TCP-Tunnel, der in einer über einen Proxy geführten TCP-Verbindung steckt, hat nun zwei Schichten, die erneut senden, und unter Verlust stockt dieses Paar auf eine Weise, die keine Schicht allein erzeugt.

Vermittler zu verketten ist eine andere Frage als eine Schicht zu wählen. Ein zweiter Proxy oder Tor ändert, wer was beobachtet, und die Position in der Kette entscheidet, welcher Hop den Geheimtext sieht.

Die Reihenfolge zählt mehr als die Zahl der Hops. Ein äußerer Hop beobachtet einen verschlüsselten Strom, während ein innerer den Klartext sieht, den er trägt, also ist eine Kette nur so privat wie ihr unvorsichtigstes Glied. Protokolle über Hops zu mischen verbessert das nicht automatisch. Es macht die Fehlermodi meist schwerer nachzuvollziehen.

Eine gefälschte Adresse ist keine der Optionen

Pakete mit fremder Quelladresse zu bauen, erreicht nichts Nützliches: Antworten reisen zum echten Inhaber, und die meisten Netze verwerfen den Verkehr rundweg. Ein Vermittler ist gerade deshalb nötig, weil die Quelle nicht erfunden werden kann, und das ist die ehrliche Begründung für alle drei Entwürfe.

Es begrenzt auch, was jedes von ihnen behaupten darf. So zu wirken, als stamme es von einer bestimmten Adresse, ist eine Frage dessen, wo diese Adresse rechtmäßig vergeben ist und wer sie routen darf, nicht dessen, welches Werkzeug einen Header fälschen kann. Nimmt ein Entwurf etwas anderes an, scheitert die Annahme beim ersten Anbieter, der sie filtert. Schreiben Sie die Annahme auf, damit der Fehler erkennbar ist, wenn er eintritt.

Entscheiden Sie nach Protokollen und Namen

Greifen Sie zum Proxy, wenn ein einzelner Web-Client einen einzelnen Webdienst braucht und Proxy-Einstellungen hat. Greifen Sie zum SSH-Tunnel, wenn eine Handvoll bekannter TCP-Dienste reicht und SSH-Zugang bereits besteht. Greifen Sie zum VPN, wenn mehrere Anwendungen, Nicht-TCP-Verkehr, privates DNS oder ein wiederverwendbarer Pfad Teil der Anforderung sind.

Prüfen Sie dann mit dem echten Client und dem echten Namen. Eine Seite durch einen Proxy zu laden, lehrt Sie nichts über UDP, und ein Werkzeug über SOCKS zum Laufen zu bringen, lehrt Sie nichts über den System-Resolver. Lesen Sie, an welche lokale Adresse der Prozess gebunden war und welcher Resolver geantwortet hat. Das ist der Unterschied zwischen einem Pfad, der funktioniert, und einem, der zufällig einmal funktioniert hat.