mitmproxy, DevTools, Gradle: tři vrstvy za VPN
Loopback se do tunelu nikdy nedostane. Zařaďte příznak k posluchači, úložišti důvěry nebo paketovému filtru a opravte vrstvu, která skutečně selhala.
VPN se připojí a tři nesouvisející nástroje selžou třemi různými způsoby téhož odpoledne. mitmproxy přestane vídat požadavky, Chrome odmítne debugger a Gradle vyhodí BindException při navazování lokálního socketu. Společná podezření jsou, že tunel blokuje localhost. Nemůže: 127.0.0.1 se zpracovává uvnitř jádra a nikdy se nedostane k adaptéru, natož k bráně.
Tři vrstvy, tři různá selhání
Co se změnilo s klientem, není cesta k loopbacku. Jde o lokální proxy, strojové úložiště důvěry a paketový filtr a každé z nich rozbíjí jinou část vývojářského postupu. Zařazení příznaku do správného řádku je většina diagnostiky:
| 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? |
Téměř každé hlášení tohoto druhu začíná u posledního řádku a postupuje nahoru, což je obráceně. Tunel je jediná vrstva, která prokazatelně nemůže vidět provoz na loopback, takže si zaslouží nejmenší podezření. Začněte tím, co proces navázal, pak se ptejte, kterým certifikátům věří, a teprve potom se dívejte na politiku na stroji.
Začněte u posluchače, ne u tunelu
Když proxy na 127.0.0.1:8080 přestane přijímat provoz, stala se jedna ze tří věcí: nikdy se nespustila, navázala jiný port nebo filtr zahodil loopbackové spojení. Výpis naslouchajících socketů to zodpoví jedním příkazem a také ukáže, který proces drží port, když se dva nástroje neshodnou na tom, kdo byl první.
Lokální adresa ve vyhledání trasy potvrzuje totéž z opačné strany. ip route get vůči cíli na loopback hlásí loopbackové zařízení, nikdy tunel, což je užitečná věta, když někdo navrhne změnu směrování jako opravu.
Vrstva proxy: prostředí není konfigurace
Mnoho firemních klientů provozuje HTTP proxy a očekává, že aplikace ji použijí. Nastavení HTTPS_PROXY v shellu opraví nástroje příkazové řádky, které ji respektují, a neudělá nic pro nástroj, který čte vlastní soubor nastavení. Gradle, Selenium a gRPC každý nahlíží do vlastní konfigurace a proxy exportovaná v jednom terminálu je neviditelná pro démona spuštěného v IDE.
Nástroje pro kontejnery jsou obvyklé místo, kde to vyjde najevo. Loopback kontejneru je jeho vlastní, takže 127.0.0.1 uvnitř kontejneru nikdy neznamená proxy hostitele; je potřeba adresa hostitele nebo nastavení hostitelské sítě. Oprava, která funguje v shellu a selhává při sestavení, je obvykle tento řádek, ne tunel.
Vrstva důvěry: nástroj čte jiné úložiště
Zachytávání je druhá změna a produkuje nejzavádějící chyby. Klient předkládá vlastní certifikát pro kontrolovaná spojení, takže prohlížeč, který důvěřuje firemnímu kořeni, uspěje, zatímco nástroj s vestavěným úložištěm CA selže. Pythoní requests přes certifi je klasický případ: úložiště operačního systému může být správné a požadavek přesto selže, protože toto běhové prostředí ho nikdy nečte. Text chyby zřídka zmiňuje zachytávání, a proto je tento řádek chybně diagnostikován jako rozbitý koncový bod.
Porovnejte, co koncový bod skutečně předkládá, s tím, co nástroj ověřil. openssl s_client ukazuje řetěz, který server odeslal; vlastní výstup ověření nástroje ukazuje, co rozhodl. Když se neshodují, REQUESTS_CA_BUNDLE nebo SSL_CERT_FILE je páka pro toto běhové prostředí a firemní kořen patří do úložiště, které toto prostředí čte, nikoli na globální místo, které respektují jen některé nástroje.
Změna verze, která opraví chybu SSL, je důkazem o politice důvěry a šifer, ne o VPN. Snížení verze Pythonu, po kterém klient SOAP funguje, změnilo vestavěné úložiště CA a výchozí nastavení TLS; síťová cesta se nepohnula.
Vrstva filtru: i ta může zahodit loopback
Třetí změnou je paketový filtr a některé produkty instalují pravidla, která zahazují provoz, jenž nevstupuje do tunelu. Lokální posluchače mohou být zahrnuty. To promění funkční socket v odmítnuté nebo vypršené spojení a výsledná chyba vypadá jako chyba v aplikaci, ne jako politika na stroji.
Vlastnictví portu je druhá polovina této vrstvy. BindException znamená, že socket nešlo otevřít, což je jiné selhání než odmítnuté spojení. Než obviníte filtr, zkontrolujte, zda port už nedrží jiný proces, pak hledejte pravidlo, které zahazuje lokální provoz, a přidejte nejužší povolení, které produkt podporuje. Dva nástroje soutěžící o stejný ladicí port dávají přesně stejnou zprávu jako blokování politikou a jen jeden z nich se opraví změnou firewallu.
Ladicí port Chrome selhává ve stejné rodině. Prohlížeč se spustí, ovladač nedosáhne na koncový bod DevTools a zpráva jmenuje DevTools, ne síť. Další spouštěcí přepínače a nadbytečný správce ovladačů mění, který proces port drží, a proto se jejich odstranění někdy jeví jako oprava VPN.
Opravte vrstvu, která selhala
Opravte vrstvu, která selhala, ne tunel. Nedostupný loopbackový posluchač potřebuje opravit svého posluchače nebo port. Nedůvěryhodný certifikát potřebuje firemní kořen nainstalovaný tam, kam toto konkrétní běhové prostředí kouká, s úzkou výjimkou. Filtr, který zahazuje lokální provoz, potřebuje konkrétní povolovací pravidlo, ne vypnutý filtr, protože vypnutí znovu otevře i vše ostatní, co chránil.
Opětovné připojení VPN neprověří žádnou z těchto vrstev. Jen znovu spustí změnu, která je rozbila, a proto se stejná tři selhání vracejí po každém opětovném připojení a mizí po každém restartu, který klienta nechá neaktivního.