mitmproxy, DevTools, Gradle: trzy warstwy za VPN-em
Loopback nigdy nie trafia do tunelu. Sklasyfikuj objaw jako nasłuch, magazyn zaufania lub filtr pakietów i napraw warstwę, która naprawdę zawiodła.
VPN się łączy, a trzy niezwiązane narzędzia zawodzą na trzy różne sposoby tego samego popołudnia. mitmproxy przestaje widzieć żądania, Chrome odmawia debuggerowi, a Gradle rzuca BindException podczas wiązania lokalnego gniazda. Wspólne podejrzenie jest takie, że tunel blokuje localhost. Nie może: 127.0.0.1 jest obsługiwany wewnątrz jądra i nigdy nie dociera do adaptera, a co dopiero do bramy.
Trzy warstwy, trzy różne awarie
To, co zmieniło się z klientem, to nie trasa do loopbacku. To lokalny proxy, magazyn zaufania maszyny i filtr pakietów, i każdy z nich psuje inną część przepływu pracy programisty. Zaklasyfikowanie objawu do właściwego wiersza to większość diagnozy:
| 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? |
Niemal każdy raport tego rodzaju zaczyna się od ostatniego wiersza i idzie w górę, co jest odwrotnością. Tunel to jedyna warstwa, która udowodnialnie nie widzi ruchu loopback, więc zasługuje na najmniejsze podejrzenie. Zacznij od tego, co związał proces, potem zapytaj, którym certyfikatom ufa, a dopiero na końcu spójrz na politykę maszyny.
Zacznij od nasłuchu, nie od tunelu
Gdy proxy na 127.0.0.1:8080 przestaje odbierać ruch, stało się jedno z trzech: nigdy nie wystartowało, związało inny port albo filtr odrzucił połączenie loopback. Wyliczenie nasłuchujących gniazd odpowiada na to jedną komendą i pokazuje też, który proces trzyma port, gdy dwa narzędzia nie zgadzają się co do tego, kto był pierwszy.
Lokalny adres w wyszukiwaniu trasy potwierdza to samo z drugiej strony. ip route get wobec celu loopback zgłasza urządzenie loopback, nigdy tunel, co jest przydatnym zdaniem do przygotowania, gdy ktoś proponuje zmianę routingu jako rozwiązanie.
Warstwa proxy: środowisko nie jest konfiguracją
Wiele klientów korporacyjnych uruchamia proxy HTTP i oczekuje, że aplikacje będą go używać. Ustawienie HTTPS_PROXY w powłoce naprawia narzędzia wiersza poleceń, które je respektują, i nie robi nic dla narzędzia czytającego własny plik ustawień. Gradle, Selenium i gRPC każdy konsultuje własną konfigurację, a proxy wyeksportowane w jednym terminalu jest niewidoczne dla demona uruchomionego przez IDE.
Narzędzia kontenerowe to zwykłe miejsce, w którym staje się to widoczne. Loopback kontenera jest jego własny, więc 127.0.0.1 wewnątrz kontenera nigdy nie oznacza proxy hosta; potrzebny jest adres hosta lub ustawienie sieci hosta. Poprawka, która działa w powłoce, a zawodzi w kompilacji, to zwykle ten wiersz, nie tunel.
Warstwa zaufania: narzędzie czyta inny magazyn
Przechwytywanie to druga zmiana i produkuje najbardziej mylące błędy. Klient przedstawia własny certyfikat dla sprawdzanych połączeń, więc przeglądarka ufająca korporacyjnemu korzeniowi odnosi sukces, podczas gdy narzędzie z wbudowanym magazynem CA zawodzi. requests Pythona przez certifi to klasyczny przypadek: magazyn systemu operacyjnego może być poprawny, a żądanie mimo to zawodzi, bo to środowisko nigdy go nie czyta. Tekst błędu rzadko wspomina o przechwytywaniu, dlatego ten wiersz bywa błędnie diagnozowany jako zepsuty punkt końcowy.
Porównaj, co punkt końcowy faktycznie przedstawia, z tym, co narzędzie zweryfikowało. openssl s_client pokazuje łańcuch wysłany przez serwer; własne wyjście walidacji narzędzia pokazuje, co zdecydowało. Gdy się nie zgadzają, REQUESTS_CA_BUNDLE lub SSL_CERT_FILE jest dźwignią dla tego środowiska, a korporacyjny korzeń należy do magazynu, który to środowisko czyta, a nie do globalnego miejsca, które respektują tylko niektóre narzędzia.
Zmiana wersji, która naprawia błąd SSL, jest dowodem o polityce zaufania i szyfrów, nie o VPN. Obniżenie wersji Pythona, po którym klient SOAP zaczął działać, zmieniło wbudowany magazyn CA i domyślne ustawienia TLS; ścieżka sieciowa się nie przesunęła.
Warstwa filtra: ona też może odrzucić loopback
Trzecia zmiana to filtr pakietów, a niektóre produkty instalują reguły odrzucające ruch, który nie wchodzi do tunelu. Lokalne nasłuchy mogą zostać objęte. To zamienia działające gniazdo w połączenie odrzucone lub przekroczone czasowo, a wynikowy błąd wygląda jak błąd aplikacji, a nie polityka maszyny.
Własność portu to druga połowa tej warstwy. BindException oznacza, że nie udało się otworzyć gniazda, co jest innym niepowodzeniem niż odrzucone połączenie. Sprawdź, czy portu nie trzyma już inny proces, zanim obwinisz filtr, potem poszukaj reguły odrzucającej lokalny ruch i dodaj najwęższe pozwolenie, które obsługuje produkt. Dwa narzędzia walczące o ten sam port debugowania dają dokładnie ten sam komunikat co blokada polityki, a tylko jedno z nich naprawia zmiana zapory.
Port debugowania Chrome zawodzi w tej samej rodzinie. Przeglądarka startuje, sterownik nie dociera do punktu końcowego DevTools, a komunikat wymienia DevTools, a nie sieć. Dodatkowe flagi startowe i zbędny menedżer sterowników zmieniają to, który proces trzyma port, dlatego ich usunięcie czasem wygląda jak naprawa VPN.
Napraw warstwę, która zawiodła
Napraw warstwę, która zawiodła, nie tunel. Nieosiągalny nasłuch loopback wymaga poprawienia nasłuchu lub portu. Niezaufany certyfikat wymaga korporacyjnego korzenia zainstalowanego tam, gdzie patrzy to konkretne środowisko, z wyjątkiem trzymanym wąsko. Filtr odrzucający lokalny ruch wymaga konkretnej reguły pozwolenia, a nie wyłączonego filtra, bo wyłączenie otwiera też wszystko inne, co chronił.
Ponowne połączenie VPN nie testuje żadnej z tych warstw. Wykonuje tylko ponownie zmianę, która je zepsuła, dlatego te same trzy awarie wracają po każdym ponownym połączeniu i znikają po każdym restarcie, który pozostawia klienta nieaktywnym.