Proxy hängt nach einem VPN-Reconnect noch an der alten Tunneladresse?

Ein Neustart des VPN-Clients beweist nur, dass der Tunnel zurück ist. Über den Proxy, der angewiesen wurde, durch ihn hinauszugehen, sagt er nichts. Squid, tinyproxy und die meisten anderen Forwarder halten die lokale Quelladresse, die sie beim Start aufgelöst haben, bis etwas sie zum Neuladen zwingt. Wenn ein Reconnect eine neue Tunneladresse vergibt, scheitert der Forwarder bei jedem ausgehenden Verbindungsaufbau oder beginnt, über Ihre gewöhnliche Route hinauszugehen.

Der zweite Fehler ist der gefährliche: Der Tunnel steht, Seiten laden, und nur die Ausgangsadresse ist falsch.

Beginnen Sie beim Listener, nicht beim Tunnel

Drei Adressen sind im Spiel, und ein Reconnect verschiebt nur einige davon. Der Listener ist der Punkt, auf den Ihr Browser zeigt, meist 127.0.0.1 oder eine LAN-Adresse, und es ist ihm egal, dass sich der Tunnel geändert hat. Die ausgehende lokale Quelle ist das, was der Forwarder den Kernel bitten lässt zu verwenden, wenn er den nächsten Hop anwählt, und sie ist an das Tunnelgerät gebunden. Der öffentliche Ausgang ist das, was ein Webserver protokolliert, und er kann eine übersetzte Adresse mehrere Hops entfernt sein.

Eine Abfrage der öffentlichen IP beantwortet nur die letzte Frage. Sie kann Ihnen nicht sagen, an welche lokale Adresse ein Forwarder binden soll, denn ein öffentlicher Ausgang kann mehrere interne Quellen verbergen. Lesen Sie die Adresse bei dem, der die Verbindung besitzt: die Statusausgabe des Clients, die Schnittstelle selbst oder der Namespace, in dem der Tunnel lebt. Das erste Interface zu greifen, dessen Name wie ein Tunnel aussieht, liefert die falsche Antwort, sobald ein zweites Profil existiert.

Container- und Namespace-Layouts brechen diese Annahme still. Ein Forwarder in einem Netzwerk-Namespace kann keinen Tunnel binden, der in einem anderen existiert, und kein Bearbeiten der Konfiguration repariert das.

Vier Prüfungen, bevor Sie etwas bearbeiten

Arbeiten Sie sie der Reihe nach ab. Die erste Prüfung, die fehlschlägt, ist die Stelle, an der Sie aufhören, denn die späteren setzen voraus, dass die früheren gelten.

1. Bestätigen Sie, dass der genutzte Tunnel das Profil ist, um das herum der Proxy gebaut wurde, nicht ein zweites Profil, das sich von selbst verbunden hat.
2. Geben Sie die Adresse aus, die derzeit auf diesem Gerät steht, und vergleichen Sie sie mit der Adresse in der laufenden Konfiguration.
3. Fragen Sie den Forwarder, welche Quelle er aufgelöst hat, statt was die Datei auf der Platte behauptet.
4. Bestätigen Sie, dass der Verkehr vom Forwarder tatsächlich der Routing- und Firewallrichtlinie unterliegt, die Sie erwarten.

Die Geräteadresse ist einfach: ip -4 addr show dev tun0 gibt die aktuelle aus, und ip -4 route get 1.1.1.1 zeigt, welche Schnittstelle der Kernel für dieses Ziel wählen würde. Ein Forwarder, der eine exakte Adresse bindet, scheitert laut, wenn die Adresse verschwindet. Ein Forwarder, der ein Gerät bindet oder auf die Standardquelle zurückfällt, funktioniert weiter und leckt, und das ist das stille Ergebnis.

Gleichen Sie die Dokumentation auf die Ausgabe ab, die Sie ausführen, nicht auf das oberste Suchergebnis. Squids Direktive für die ausgehende Adresse ist für v7 und früher dokumentiert, und die v8-Dokumentation sagt klar, dass die Direktive dort nicht verfügbar ist, sodass ein darum gebautes Skript diese Grenze nicht überlebt (siehe die Squid-Referenz tcp_outgoing_address). Prüfen Sie mit dem Parser des Produkts selbst, bevor irgendetwas neu geladen wird: squid -k parse meldet Fehler und beendet sich, ohne den laufenden Prozess anzufassen.

Nummerieren Sie jeden Tunnel und verwerfen Sie veraltete Wechsel

Ein Reconnect ist eine Übergabe, und Übergaben brauchen eine Reihenfolge. Versehen Sie jede beobachtete Verbindung mit einem Zähler oder Zeitstempel, der bei jeder erfolgreichen Herstellung steigt, und tragen Sie dieses Kennzeichen in der Kandidatenkonfiguration. Wenn das Kennzeichen eines Kandidaten älter ist als das aktuelle, verwerfen Sie den Kandidaten, statt ihn anzuwenden, denn eine langsam geschriebene Aktualisierung für den vorherigen Tunnel würde sonst die Einstellungen für den aktuellen überschreiben. Fassen Sie Schübe von Ereignissen zusammen, damit eine flatternde Verbindung einen Übergang statt fünfzehn erzeugt.

Ordnen Sie die Arbeit in vier Schritten: den alten Ausgangszustand für ungültig erklären, auf die Fertigmeldung des Verbindungseigentümers warten, nur das verwaltete Fragment bauen, dann über den Dienstmanager prüfen und aktivieren. Die ganze Datei aus zwei Adresswerten neu zu erzeugen ist der Weg, auf dem Listenerbeschränkungen, Authentifizierung und Zielrichtlinie still verschwinden. Respektieren Sie auch ein bewusstes Stoppen. Ein Helfer, der weiter einen Tunnel anwählt, den der Nutzer abgeschaltet hat, ist ein Fehler, keine Robustheit.

Offene Sockets folgen der neuen Adresse nicht

Das Umkonfigurieren des Forwarders sagt nichts über bereits aufgebaute Verbindungen. Ob sie auslaufen oder sterben, hängt vom Produkt ab, also beobachten Sie das Verhalten, statt es anzunehmen.

Eine Anfrage, die über einen vor dem Wechsel geöffneten Socket bedient wird, geht weiterhin über den alten Pfad hinaus, selbst wenn die neue Konfiguration korrekt ist. Wenn das zählt, entscheiden Sie ausdrücklich: ein kurzes Auslaufen zulassen und keine neue Arbeit mehr annehmen oder die alten Sockets beenden und die Fehler akzeptieren. Testen Sie dann mit einer frischen Verbindung und halten Sie dieses Ergebnis getrennt von der Auslaufprüfung. Auch Quellbindung ist keine Sicherheitsgrenze. Wenn Verkehr niemals die gewöhnliche Route berühren darf, erzwingen Sie das mit Markierungen und Firewallregeln, DNS und IPv6 eingeschlossen, damit ein fehlgeschlagenes Neuladen den Proxy ausdrücklich abgeschaltet statt offen lässt.

Beweisen Sie den neuen Ausgang mit einer frischen Anfrage

Entscheidend ist eine nach der Aktivierung geöffnete Anfrage, kein Ping und keine bereits zwischengespeicherte Seite. Bitten Sie den Proxy um eine echte URL und lesen Sie die Ausgangsadresse, die die Gegenseite meldet, und vergleichen Sie sie mit der Sicht des Clients auf den Tunnel, wenn der Anbieter eine anzeigt.

Halten Sie Parsen, Neuladen und Anfrage als getrennte Befehle, damit ein Fehlschlag auf einen einzigen Schritt zeigt. Die ersten beiden ändern nichts, wenn sie scheitern, und genau deshalb laufen sie vor dem Neustart.

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

Wenn das Neuladen scheitert, stoppen Sie den Dienst und reparieren Sie das Fragment; ein Proxy, der mit veraltetem Ausgang dient, ist schlimmer als eine kurze Unterbrechung. Wenn das Neuladen gelingt, die frische Anfrage aber weiterhin irgendwo Unerwartetes hinausgeht, kehren Sie zur Routingprüfung zurück, statt erneut Adressen zu bearbeiten. Notieren Sie die Tunnelgeneration, gegen die Sie geprüft haben, damit der nächste Reconnect etwas Konkretes zum Vergleichen hat.