mitmproxy, DevTools, Gradle: tri vrstvy za VPN
Loopback sa do tunela nikdy nedostane. Zaradte príznak k poslucháčovi, úložisku dôvery alebo paketovému filtru a opravte vrstvu, ktorá skutočne zlyhala.
VPN sa pripojí a tri nesúvisiace nástroje zlyhajú tromi rôznymi spôsobmi toho istého popoludnia. mitmproxy prestane vidieť požiadavky, Chrome odmietne debugger a Gradle vyhodí BindException pri naväzovaní lokálneho socketu. Spoločné podozrenie je, že tunel blokuje localhost. Nemôže: 127.0.0.1 sa spracúva vnútri jadra a nikdy sa nedostane k adaptéru, a tobôž k bráne.
Tri vrstvy, tri rôzne zlyhania
To, čo sa zmenilo s klientom, nie je cesta k loopbacku. Ide o lokálny proxy, úložisko dôvery stroja a paketový filter, a každý z nich rozbíja inú časť vývojárskeho pracovného postupu. Zaradenie príznaku do správneho riadku je väčš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? |
Takmer každé hlásenie tohto druhu začína pri poslednom riadku a postupuje nahor, čo je naopak. Tunel je jediná vrstva, ktorá preukázateľne nemôže vidieť prevádzku loopback, takže si zaslúži najmenšie podozrenie. Začnite tým, čo proces naviazal, potom sa spýtajte, ktorým certifikátom dôveruje, a až potom sa pozrite na politiku na stroji.
Začnite pri poslucháčovi, nie pri tuneli
Keď proxy na 127.0.0.1:8080 prestane prijímať prevádzku, stala sa jedna z troch vecí: nikdy sa nespustil, naviazal iný port alebo filter zahodil loopbackové spojenie. Výpis počúvajúcich socketov to zodpovie jedným príkazom a tiež ukáže, ktorý proces drží port, keď sa dva nástroje nezhodnú, kto bol prvý.
Lokálna adresa vo vyhľadaní trasy potvrdzuje to isté z opačnej strany. ip route get voči cieľu na loopback hlási loopbackové zariadenie, nikdy tunel, čo je užitočná veta, keď niekto navrhne zmenu smerovania ako riešenie.
Vrstva proxy: prostredie nie je konfigurácia
Mnohí firemní klienti prevádzkujú HTTP proxy a očakávajú, že aplikácie ho použijú. Nastavenie HTTPS_PROXY v shelli opraví nástroje príkazového riadku, ktoré ho rešpektujú, a nič neurobí pre nástroj, ktorý číta vlastný súbor nastavení. Gradle, Selenium a gRPC každý nahliadne do vlastnej konfigurácie a proxy exportovaná v jednom termináli je neviditeľná pre démona spusteného v IDE.
Nástroje pre kontajnery sú obvyklé miesto, kde to vyjde najavo. Loopback kontajnera je jeho vlastný, takže 127.0.0.1 vnútri kontajnera nikdy neznamená proxy hostiteľa; je potrebná adresa hostiteľa alebo nastavenie hostiteľskej siete. Oprava, ktorá funguje v shelli a zlyháva pri zostavení, je zvyčajne tento riadok, nie tunel.
Vrstva dôvery: nástroj číta iné úložisko
Zachytávanie je druhá zmena a produkuje najzavádzajúcejšie chyby. Klient predkladá vlastný certifikát pre kontrolované spojenia, takže prehliadač, ktorý dôveruje firemnému koreňu, uspeje, zatiaľ čo nástroj s vstavaným úložiskom CA zlyhá. requests Pythonu cez certifi je klasický prípad: úložisko operačného systému môže byť správne a požiadavka napriek tomu zlyhá, pretože toto behové prostredie ho nikdy nečíta. Text chyby zriedka spomína zachytávanie, a preto je tento riadok nesprávne diagnostikovaný ako pokazený koncový bod.
Porovnajte, čo koncový bod skutočne predkladá, s tým, čo nástroj overil. openssl s_client ukazuje reťaz, ktorú server odoslal; vlastný výstup overenia nástroja ukazuje, čo rozhodol. Keď sa nezhodujú, REQUESTS_CA_BUNDLE alebo SSL_CERT_FILE je páka pre toto behové prostredie a firemný koreň patrí do úložiska, ktoré toto prostredie číta, nie na globálne miesto, ktoré rešpektujú len niektoré nástroje.
Zmena verzie, ktorá opraví chybu SSL, je dôkazom o politike dôvery a šifier, nie o VPN. Zníženie verzie Pythonu, po ktorom klient SOAP funguje, zmenilo vstavané úložisko CA a predvolené nastavenia TLS; sieťová cesta sa nepohla.
Vrstva filtra: aj tá môže zahodiť loopback
Treťou zmenou je paketový filter a niektoré produkty inštalujú pravidlá, ktoré zahadzujú prevádzku, ktorá nevstupuje do tunela. Môžu byť zahrnuté aj lokálne poslucháče. To premení funkčný socket na odmietnuté alebo vypršané spojenie a výsledná chyba vyzerá ako chyba v aplikácii, nie ako politika na stroji.
Vlastníctvo portu je druhá polovica tejto vrstvy. BindException znamená, že socket sa nepodarilo otvoriť, čo je iné zlyhanie než odmietnuté spojenie. Pred obvinením filtra skontrolujte, či port už nedrží iný proces, potom hľadajte pravidlo, ktoré zahadzuje lokálnu prevádzku, a pridajte najužšie povolenie, ktoré produkt podporuje. Dva nástroje súťažiace o rovnaký ladiaci port dávajú presne rovnakú správu ako blokovanie politikou a iba jeden z nich sa opraví zmenou firewallu.
Ladiaci port Chrome zlyháva v tej istej rodine. Prehliadač sa spustí, ovládač nedosiahne koncový bod DevTools a správa pomenuje DevTools, nie sieť. Ďalšie spúšťacie prepínače a nadbytočný správca ovládačov menia, ktorý proces drží port, preto sa ich odstránenie niekedy javí ako oprava VPN.
Opravte vrstvu, ktorá zlyhala
Opravte vrstvu, ktorá zlyhala, nie tunel. Nedostupný loopbackový poslucháč potrebuje opravu poslucháča alebo portu. Nedôveryhodný certifikát potrebuje firemný koreň nainštalovaný tam, kam toto konkrétne behové prostredie pozerá, s úzkou výnimkou. Filter, ktorý zahadzuje lokálnu prevádzku, potrebuje konkrétne povoľovacie pravidlo, nie vypnutý filter, pretože vypnutie znovu otvorí aj všetko ostatné, čo chránil.
Opätovné pripojenie VPN nepreverí žiadnu z týchto vrstiev. Len znovu spustí zmenu, ktorá ich rozbila, a preto sa tie isté tri zlyhania vracajú po každom opätovnom pripojení a miznú po každom reštarte, ktorý nechá klienta neaktívneho.