Grünes Symbol, gleiche öffentliche IP: Welche Route die VPN ausließ

Verbunden, grünes Symbol im Infobereich und eine Seite, die Ihre Adresse zurückspiegelt und weiterhin die Adresse des Anbieters zeigt, bedeuten nicht automatisch einen Fehler. Ein Client erledigt zwei getrennte Aufgaben: Er baut einen Tunnel auf, und er ändert die Routing-Tabelle. Beides kann ohne das andere geschehen, und selektives Routing ist die Konfiguration, in der die zweite bewusst übersprungen wird.

Was der Client tatsächlich installiert hat

Fragen Sie, welche Schnittstelle ein Paket zu einem echten Ziel tragen würde, statt zu fragen, ob der Tunnel steht. Ein Tunnel ohne Route zu diesem Ziel ist eine Privatstraße, die niemand befährt.

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

Der erste Befehl antwortet unter Linux und macOS, die beiden anderen sind die Windows-Entsprechungen, wo eine genügt. Nennt die Antwort den physischen Adapter, steht der Tunnel, und die Standardroute hat sich nie bewegt. Wiederholen Sie die Abfrage für ein Ziel, das den Tunnel nutzen sollte, denn zwei Abfragen, eine entfernte und eine gewöhnliche, sagen Ihnen, welches Design im Einsatz ist.

Drei Formen des selektiven Routings

Ein Volltunnelprofil schreibt üblicherweise eine Standardroute auf die Schnittstelle oder schreibt das Paar halber Bereichspräfixe, das über die Präfixlänge gewinnt, während die ursprüngliche Standardroute in der Tabelle bleibt. Selektives Routing ist die andere Wahl, und es kommt in mehreren Formen. Ein Profil leitet einen einzelnen Host wie einen RDP-Server, ein anderes leitet einen öffentlichen Bereich, der von einem bestimmten Ort aus erreichbar sein muss, und ein drittes schließt eine Anwendung bewusst aus. Alle drei sind legitim, und keines ändert die Adresse, die eine gewöhnliche Website sieht.

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

Lesen Sie das Profil auf die Anweisung, die entscheidet, und dann die Tabelle darauf, was sie erzeugt hat. Eine geschobene Anweisung lässt sich auch auf dem Client unterdrücken, deshalb müssen Profil und Tabelle übereinstimmen, bevor Sie den Server beschuldigen.

Die Gegenseite muss die Quelladresse umschreiben

Es gibt einen zweiten Fehler, der aus dem Browser identisch aussieht. Die Route zeigt in den Tunnel, der Server empfängt die Pakete und leitet sie dann mit unveränderter privater Adresse des Clients weiter. Der nächste Hop hat keinen Rückweg für diese Adresse, also verschwinden Antworten und Seiten hängen. Der Server muss überhaupt weiterleiten, und er muss die Quelle in etwas übersetzen, das das Internet zurück leiten kann.

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

Benennen Sie die Schnittstelle, die tatsächlich ins Internet zeigt, was auf einer modernen Distribution nicht immer eth0 ist. Ein gehosteter Server mit fester Adresse kann ausdrücklich auf diese Adresse übersetzen, statt masquerade zu verwenden. Beide Hälften zählen, denn Weiterleitung ohne Übersetzung lässt nicht routbare Quellen durchsickern, während Übersetzung ohne Weiterleitung das Paket nie sieht.

Die Namensauflösung nimmt ihren eigenen Weg

Der Verkehr kann durch den Tunnel austreten, während die Abfrage, die den Namen fand, zu einem Resolver im lokalen Netz ging. Die sichtbare Adresse bleibt gleich, die Abfragen nicht, und genau diese Lücke wählt ein geteiltes DNS-Design.

resolvectl status | head -20
resolvectl query example.org

Achten Sie darauf, welcher Server geantwortet hat und ob er von der Ausgangsbasis vor dem Tunnel abweicht. Bei einem geteilten Tunnel ist das meist die Einstellung, die Leute ändern wollten, als sie sich über die Adresse beschwerten, und es ist die, die sie nie angesehen haben.

Vier Beobachtungen, die die Sache klären

Erfassen Sie die Ausgangsadresse bei abgeschaltetem Tunnel und dann bei eingeschaltetem. Führen Sie die Zielabfrage in beiden Zuständen aus und notieren Sie jedes Mal die Schnittstelle.

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

Wenn die Abfrage im Tunnel landet und das Echo weiterhin die Adresse des Anbieters zeigt, fehlt die Übersetzung am Ausgang. Wenn die Abfrage auf dem physischen Adapter landet, ist das Profil selektiv und die öffentliche Adresse war nie im Spiel. Ersetzen Sie den Echo-Dienst durch einen, dem Sie vertrauen, und notieren Sie die vier Beobachtungen zusammen, denn einzeln sind sie Anekdoten. Zusammen zeigen sie, welche der beiden Aufgaben der Client tatsächlich erledigt hat.