Nur-IPv6-Verbindung, IPv4-Dienst: Lassen Sie einen SOCKS-Proxy überbrücken

Sie brauchen keine Adresse aus der Zieladressfamilie, um es zu erreichen, solange etwas auf dem Weg bereit ist weiterzuleiten. Die Anwendung verbindet sich mit dem Proxy, und der Proxy öffnet eine zweite Verbindung zum Ziel. Das sind zwei Sockets mit unabhängigen Adressfamilien, und nichts in einem der beiden Protokolle verlangt, dass sie übereinstimmen. Das ist Weiterleitung auf Anwendungsebene und kein nativer IPv4-Pfad, und dieser Unterschied entscheidet, was funktioniert und was nicht. Die beiden zu verwechseln ist der Grund, warum ein Laptop als IPv4-fähig beschrieben wird, obwohl alles, was er hat, ein Proxy ist.

Zwei Sockets, zwei Adressfamilien

Eine SOCKS5-Anfrage nennt das Ziel in einer von drei Formen: eine literale v4-Adresse, eine literale v6-Adresse oder einen Namen, den der Proxy auflösen soll. Die Anfrage beschreibt, wohin der Proxy sich verbinden soll, nicht wie die Client-zu-Proxy-Verbindung aussieht.

Lesen Sie diese Adresstypen als drei unabhängige Entscheidungen innerhalb einer Nachricht. Ein über IPv6 erreichbarer Proxy kann einen Ziel-Socket für IPv4 öffnen, sobald er einen funktionierenden IPv4-Ausgang hat und seine Richtlinie die Anfrage erlaubt. Die SOCKS5-Spezifikation definiert sie ganz ohne Bezug auf den Transport des Clients.

Ein kontrolliertes SSH-Beispiel

Nehmen Sie einen SSH-Host, den Sie nutzen dürfen, der über IPv6 antwortet und selbst einen HTTPS-Dienst erreichen kann, der nur auf v4 existiert. Die dynamische Weiterleitung von OpenSSH legt einen lokalen SOCKS-Listener auf Ihrem Rechner an, während die Login-Sitzung über v6 läuft.

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

Host und Konto oben sind Beispiele, und die Loopback-Bindung hält den Listener auf diesem Computer. Ersetzen Sie sie nicht durch eine Wildcard-Bindung, damit ein Büro einen nicht authentifizierten Proxy teilen kann. ExitOnForwardFailure=yes existiert, damit eine fehlgeschlagene Weiterleitung die Sitzung beendet, statt einen stillen Befehl im Hintergrund laufen zu lassen.

Wenn die Sitzung läuft, sieht die Anfrage so aus:

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

Die Loopback-Verbindung ist kein IPv4-Internetpfad. Was Ihren Rechner verlässt, ist die Login-Sitzung über v6, und die Gegenseite öffnet den Ziel-Socket. Die Form socks5h delegiert auch die Namensauflösung an diese Seite, was zählt, wenn der Client keinen eigenen IPv4-Resolver-Pfad hat.

Was das Ziel tatsächlich sieht

Das Ziel sieht die Ausgangsadresse der Weiterleitung. Keine Adresse, die zu Ihrem Laptop gehört, erscheint dort. Eine Quell-Allowlist bei diesem Dienst muss die Weiterleitung nennen. Ihre Protokolle werden den Verkehr ebenfalls der Weiterleitung zuschreiben. Schreiben Sie das vor dem Audit in den Änderungsdatensatz, denn eine Allowlist, die um Client-Adressen herum gebaut ist, scheitert bei der ersten Anfrage.

Die Weiterleitung ist auch der Ort, an dem die beiden Hälften des Gesprächs sichtbar sind, was bei der Diagnose nützlich und eine Belastung ist, wenn die Weiterleitung ohne Richtlinie geteilt wird.

Das ist weder DNS64 noch NAT64

DNS64 antwortet mit synthetisierten Datensätzen, die v4-Ziele vertreten, und NAT64 schreibt Pakete entlang eines konfigurierten Pfads um. Keines von beiden beschreibt, was hier geschieht, wo ein Transportgespräch endet und ein anderes beginnt und keine syntetisierte Adresse das Ergebnis erklärt. Eine erfolgreiche Anfrage sagt daher nichts darüber aus, welche Übersetzungsdienste Ihr Anbieter betreibt, und der Proxy kann auf seinem eigenen Ausgang gewöhnliches NAT ausführen.

Beide Mechanismen können im selben Netz existieren, beschreiben Sie also den, den Sie tatsächlich überprüft haben, statt den, der am nächsten klingt.

Kennen Sie den Umfang, bevor Sie ihn versprechen

Die dynamische Weiterleitung von OpenSSH überträgt TCP-Verbindungen, nicht beliebigen IP-Verkehr, daher brauchen UDP, ICMP und jedes Protokoll, das den Proxy ignoriert, ein anderes unterstütztes Design. Behalten Sie die SSH-Hostschlüsselprüfung, die Weiterleitungsbeschränkungen des Servers und die HTTPS-Zertifikatsprüfung bei, denn der Proxy ist ein zusätzlicher vertrauenswürdiger Teilnehmer und kein Grund, Identitätsprüfungen abzuschwächen. Wenn das Ziel ist, den äußeren Transport eines VPN durch den Proxy zu führen, prüfen Sie, ob beide Enden diesen Transport unterstützen, statt anzunehmen, jeder SOCKS-Listener könne ihn weiterleiten.

Nichts davon macht den Client dual-stack, und nichts davon muss es. Es lässt eine Anwendung einen Dienst über eine Weiterleitung erreichen, was eine kleinere Behauptung und viel leichter zu überprüfen ist.