Der Debug-Proxy erblindet, sobald die Firmen-VPN verbindet

Das Aufzeichnungswerkzeug arbeitet den ganzen Morgen, der Tunnel wählt sich ein, und es verstummt. Trennen Sie die Verbindung, und es läuft wieder. Der erste Gedanke ist, die VPN habe den Proxy kaputtgemacht, doch an der Proxy-Konfiguration hat sich nichts geändert. Geändert hat sich, welche Konfiguration die Anwendungen jetzt lesen: Ein Tunneleintrag kann eigene Proxy-Einstellungen tragen, ein verwaltetes Profil kann die automatische Konfiguration wieder aktivieren, und manche Laufzeitumgebungen lesen nur einen Teil dessen, was das Betriebssystem anbietet. Lesen Sie den Wert pro Verbindung, bevor Sie den globalen anfassen.

Windows führt einen Proxy pro Verbindung

In den Internetoptionen gibt es zwei Ebenen, die im Dialog gleich aussehen. Die LAN-Einstellungen gelten für die gewöhnliche lokale Verbindung, während ein Einwähl- oder VPN-Eintrag seine eigene Kopie unter HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections als Binärwert speichert. Die bekannten globalen Registrierungswerte zu schreiben, aktualisiert diese Kopie nicht.

Genau so verhält sich ein Werkzeug vor dem Verbinden richtig und danach falsch, ohne sichtbare Änderung an seinen Einstellungen. Der Dialog, den Sie anstarrten, war die LAN-Ebene. Sie war richtig und sie war irrelevant. Der Eintrag, den Windows tatsächlich verwendete, war der für den Tunnel angelegte.

Der unterstützte Weg, einen Eintrag zu ändern, ist die WinINET-API für Verbindungsoptionen: Füllen Sie INTERNET_PER_CONN_OPTION_LIST mit Verbindungsnamen, Flags, Proxyserver und Umgehungsliste, wenden Sie es an und aktualisieren Sie dann. Für eine schnelle Prüfung öffnen Sie den eigenen Einstellungsdialog des Tunneleintrags und vergleichen dessen Proxy-Bereich mit dem LAN-Bereich; der Unterschied ist meist offensichtlich, sobald man weiß, wo man hinsehen muss.

Ein verwaltetes PAC kann sich selbst wieder einschalten

Unter macOS sind das automatische Proxy-Konfigurationsskript und die Proxy-Autoermittlung Eigenschaften eines Netzwerkdienstes, nicht des Rechners. Ein Konfigurationsprofil kann sie vorschreiben, also erscheinen sie nach dem Abwählen wieder, und jede Anfrage geht dann an den Proxy, den das Skript auswählt.

Prüfen Sie und, sofern Sie berechtigt sind, schalten Sie diese beiden Schalter für den Dienst ab, der den Datenverkehr trägt:

networksetup -setautoproxystate "Wi-Fi" off
networksetup -setproxyautodiscovery "Wi-Fi" off
scutil --proxy

Verwenden Sie den echten Dienstnamen statt einer Vermutung. Ein Laptop mit WLAN und USB-Ethernet-Adapter hat zwei davon, und nur einer trägt Ihren Datenverkehr. scutil --proxy gibt die Werte für den aktuellen primären Dienst aus. Vergleichen Sie diese Ausgabe mit dem, was Sie bearbeitet haben, bevor Sie schließen, dass das Profil gewonnen hat.

Richten Sie das Werkzeug auf das echte Upstream

Wenn das Skript den Firmenproxy enthält, lesen Sie es und tragen Sie dieselbe Adresse als externen Proxy im Aufzeichnungswerkzeug ein. Dann leitet das Werkzeug an das echte Upstream weiter, was der Firmenproxy erwartet, und es bleibt im Anfragepfad, statt gegen die Richtlinie zu kämpfen.

Das ist der Zug, der Sie beim Debuggen hält statt beim Umkonfigurieren.

Schieben Sie den Proxy in den Tunnel

Ein Client auf OpenVPN-Basis kann Proxy-Optionen annehmen, die gelten, sobald der Tunnel steht, was praktisch ist, wenn der Client die Routen besitzt:

dhcp-option HTTPPROXY 127.0.0.1:8888
dhcp-option HTTPSPROXY 127.0.0.1:8888

Nur Clients, die die Option beachten, nutzen sie, und sie schreibt Ihren Lauschport fest in ein Profil. Behandeln Sie das als Laborbequemlichkeit und nicht als Bereitstellungsstandard, denn der nächste Profilausstoß entfernt sie.

Manche Clients lesen den Systemproxy nie

Firefox führt eigene Proxy-Einstellungen, weshalb er manchmal weiter aufzeichnet, wenn ein Browser mit Systemproxy es nicht tut. Ein älterer .NET-Client, der automatische Konfiguration nicht versteht, verbindet direkt, wo er auch läuft, sodass eine Seite, die über den Tunneleintrag lädt, innerhalb der Anwendung dennoch scheitern kann.

Netzwerkwerkzeuge haben auch ihre eigenen Ursachen. Eine FTP-Sitzung, die über einen Tunnel oder ein Handy-Tethering hängt, ist oft ein Problem zwischen aktivem und passivem Modus, das der Client aushandelt, und keine Proxy-Einstellung ändert das.

Lesen Sie die Konfiguration, nicht den Schalter

Arbeiten Sie in dieser Reihenfolge: der eigene Proxy-Wert des Tunneleintrags, der PAC- und Autoermittlungszustand pro Dienst, dann die eigene Proxy-Behandlung der Anwendung. Halten Sie beim ersten an, das von Ihrer Annahme abweicht.

Jeder Fall hier ist ein Problem der Konfigurationsrangfolge. Keiner davon ist der Tunnel, der Ihr Werkzeug kaputtmacht.