mitmproxy, DevTools, Gradle: drei Schichten hinter dem VPN
Loopback gelangt nie in den Tunnel. Ordnen Sie das Symptom einem Listener, einem Trust Store oder einem Paketfilter zu und reparieren Sie die Schicht, die tatsächlich versagt hat.
Das VPN verbindet sich, und drei unabhängige Werkzeuge versagen auf drei verschiedene Arten am selben Nachmittag. mitmproxy sieht keine Anfragen mehr, Chrome verweigert den Debugger, und Gradle wirft BindException beim Binden eines lokalen Sockets. Der gemeinsame Verdacht ist, dass der Tunnel localhost blockiert. Das kann er nicht: 127.0.0.1 wird im Kernel behandelt und erreicht nie einen Adapter, geschweige denn ein Gateway.
Drei Schichten, drei verschiedene Defekte
Was sich mit dem Client geändert hat, ist nicht die Route zu Loopback. Es sind ein lokaler Proxy, ein Trust Store der Maschine und ein Paketfilter, und jeder bricht einen anderen Teil des Arbeitsablaufs eines Entwicklers. Ein Symptom in die richtige Zeile einzuordnen, ist der größte Teil der Diagnose:
| Symptom | Layer | First check |
|---|---|---|
| Proxy sees no traffic | Local proxy or listener | ss -lntp, or netstat -ano on Windows |
| TLS error in one tool only | Trust store | Which CA bundle does that runtime read? |
| Local bind or connect refused | Packet filter or port owner | Who holds the port, and what rule drops it? |
Fast jeder Bericht dieser Art beginnt bei der letzten Zeile und arbeitet sich nach oben, was verkehrt ist. Der Tunnel ist die eine Schicht, die nachweislich keinen Loopback-Verkehr sehen kann, also verdient er das geringste Misstrauen. Beginnen Sie mit dem, was der Prozess gebunden hat, fragen Sie dann, welchen Zertifikaten er vertraut, und schauen Sie erst danach auf die Richtlinie der Maschine.
Beginnen Sie beim Listener, nicht beim Tunnel
Wenn ein Proxy auf 127.0.0.1:8080 keinen Verkehr mehr empfängt, ist eines von drei Dingen passiert: er wurde nie gestartet, er hat einen anderen Port gebunden, oder der Filter hat die Loopback-Verbindung verworfen. Das Auflisten der lauschenden Sockets beantwortet das mit einem Befehl und zeigt auch, welcher Prozess den Port besitzt, wenn zwei Werkzeuge sich uneinig sind, wer zuerst da war.
Eine lokale Adresse in einer Routensuche bestätigt dasselbe aus der anderen Richtung. ip route get gegen ein Loopback-Ziel meldet das Loopback-Gerät, nie den Tunnel, was ein nützlicher Satz ist, den man bereithält, wenn jemand eine Routing-Änderung als Lösung vorschlägt.
Die Proxy-Schicht: Umgebung ist keine Konfiguration
Viele Unternehmensclients betreiben einen HTTP-Proxy und erwarten, dass Anwendungen ihn verwenden. Das Setzen von HTTPS_PROXY in einer Shell repariert Kommandozeilenwerkzeuge, die ihn respektieren, und bewirkt nichts für ein Werkzeug, das seine eigene Einstellungsdatei liest. Gradle, Selenium und gRPC konsultieren jeweils ihre eigene Konfiguration, und ein in einem Terminal exportierter Proxy ist für einen von der IDE gestarteten Daemon unsichtbar.
Container-Werkzeuge sind der übliche Ort, an dem dies sichtbar wird. Der Loopback eines Containers ist sein eigener, daher 127.0.0.1 innerhalb des Containers nie den Proxy des Hosts bedeutet; die Host-Adresse oder eine Host-Netzwerk-Einstellung ist erforderlich. Eine Reparatur, die in der Shell funktioniert und im Build scheitert, ist normalerweise diese Zeile, nicht der Tunnel.
Die Vertrauensschicht: das Werkzeug liest einen anderen Speicher
Abfangen ist die zweite Änderung, und sie erzeugt die irreführendsten Fehler. Der Client präsentiert sein eigenes Zertifikat für inspizierte Verbindungen, sodass ein Browser, der der Unternehmenswurzel vertraut, erfolgreich ist, während ein Werkzeug mit einem mitgelieferten CA-Speicher scheitert. Pythons requests über certifi ist der klassische Fall: der Speicher des Betriebssystems kann korrekt sein und die Anfrage scheitert dennoch, weil diese Laufzeit ihn nie liest. Der Fehlertext erwähnt das Abfangen selten, weshalb diese Zeile fälschlich als defekter Endpunkt diagnostiziert wird.
Vergleichen Sie, was der Endpunkt tatsächlich präsentiert, mit dem, was das Werkzeug validiert hat. openssl s_client zeigt die Kette, die der Server gesendet hat; die eigene Validierungsausgabe des Werkzeugs zeigt, was es entschieden hat. Wenn sie nicht übereinstimmen, REQUESTS_CA_BUNDLE oder SSL_CERT_FILE ist der Hebel für diese Laufzeit, und die Unternehmenswurzel gehört in den Speicher, den diese Laufzeit liest, statt an einen globalen Ort, den nur manche Werkzeuge respektieren.
Eine Versionsänderung, die einen SSL-Fehler behebt, ist ein Beweis über Vertrauens- und Cipher-Richtlinie, nicht über das VPN. Ein Python-Downgrade, das einen SOAP-Client zum Laufen bringt, änderte den mitgelieferten CA-Speicher und die Standard-TLS-Einstellungen; der Netzwerkpfad bewegte sich nicht.
Die Filter-Schicht: auch sie kann Loopback verwerfen
Die dritte Änderung ist ein Paketfilter, und manche Produkte installieren Regeln, die Verkehr verwerfen, der nicht in den Tunnel gelangt. Lokale Listener können einbezogen sein. Das macht aus einem funktionierenden Socket eine abgelehnte oder zeitlich überschrittene Verbindung, und der resultierende Fehler sieht wie ein Fehler in der Anwendung aus, nicht wie eine Richtlinie der Maschine.
Portbesitz ist die andere Hälfte dieser Schicht. BindException bedeutet, dass der Socket nicht geöffnet werden konnte, was ein anderer Fehler ist als eine abgelehnte Verbindung. Prüfen Sie, ob ein anderer Prozess den Port bereits hält, bevor Sie den Filter beschuldigen, suchen Sie dann nach einer Regel, die lokalen Verkehr verwirft, und fügen Sie die engste Freigabe hinzu, die das Produkt unterstützt. Zwei Werkzeuge, die um denselben Debug-Port konkurrieren, erzeugen genau dieselbe Meldung wie eine Richtlinienblockade, und nur eines von ihnen wird durch eine Firewall-Änderung behoben.
Der Debug-Port von Chrome scheitert in derselben Familie. Der Browser startet, der Treiber erreicht den DevTools-Endpunkt nicht, und die Meldung nennt DevTools statt das Netzwerk. Zusätzliche Startflags und ein überflüssiger Treibermanager ändern, welcher Prozess den Port besitzt, weshalb das Entfernen manchmal das VPN zu reparieren scheint.
Reparieren Sie die Schicht, die versagt hat
Reparieren Sie die Schicht, die versagt hat, nicht den Tunnel. Ein nicht erreichbarer Loopback-Listener braucht eine Korrektur seines Listeners oder seines Ports. Ein nicht vertrauenswürdiges Zertifikat braucht die Unternehmenswurzel dort installiert, wo genau diese Laufzeit nachsieht, mit eng gehaltener Ausnahme. Ein Filter, der lokalen Verkehr verwirft, braucht eine bestimmte Freigaberegel statt eines deaktivierten Filters, denn das Deaktivieren öffnet auch alles andere wieder, was er schützte.
Ein erneutes Verbinden des VPN testet keine dieser Schichten. Es führt nur die Änderung erneut aus, die sie gebrochen hat, weshalb dieselben drei Fehler nach jeder Wiederverbindung zurückkehren und nach jedem Neustart verschwinden, der den Client inaktiv lässt.