mitmproxy, DevTools, Gradle: trys sluoksniai už VPN
Loopback niekada nepatenka į tunelį. Priskirkite simptomą klausytojui, patikimumo saugyklai arba paketų filtrui ir sutaisykite sluoksnį, kuris iš tikrųjų sugedo.
VPN prisijungia, ir trys nesusiję įrankiai sugenda trimis skirtingais būdais tą pačią popietę. mitmproxy nustoja matyti užklausas, Chrome atsisako derintuvo, o Gradle meta BindException rišdamas vietinį socketą. Bendras įtarimas yra tas, kad tunelis blokuoja localhost. Jis negali: 127.0.0.1 apdorojamas branduolio viduje ir niekada nepasiekia adapterio, jau nekalbant apie tinklų sietuvą.
Trys sluoksniai, trys skirtingi gedimai
Tai, kas pasikeitė su klientu, nėra kelias į loopback. Tai vietinis proxy, mašinos patikimumo saugykla ir paketų filtras, ir kiekvienas jų laužo skirtingą kūrėjo darbo eigos dalį. Simptomo priskyrimas teisingai eilutei yra didžioji diagnostikos dalis:
| 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? |
Beveik kiekviena tokia ataskaita prasideda nuo paskutinės eilutės ir kyla aukštyn, o tai yra atvirkščiai. Tunelis yra vienintelis sluoksnis, kuris įrodomai negali matyti loopback srauto, todėl jam tenka mažiausias įtarimas. Pradėkite nuo to, ką prisirišo procesas, tada paklauskite, kuriomis sertifikatų dalimis jis pasitiki, ir tik tada žiūrėkite į mašinos politiką.
Pradėkite nuo klausytojo, o ne nuo tunelio
Kai proxy adresu 127.0.0.1:8080 nustoja gauti srautą, įvyko vienas iš trijų dalykų: jis niekada nebuvo paleistas, prisirišo kitą prievadą arba filtras numetė loopback ryšį. Klausančių socketų sąrašas atsako į tai viena komanda, o taip pat parodo, kuris procesas valdo prievadą, kai du įrankiai nesutaria, kas buvo pirmas.
Vietinis adresas maršruto paieškoje patvirtina tą patį iš kitos pusės. ip route get link loopback paskirties vietos praneša loopback įrenginį, niekada tunelio, o tai yra naudingas sakinys, kurį verta turėti paruoštą, kai kas nors siūlo maršruto pakeitimą kaip sprendimą.
Proxy sluoksnis: aplinka nėra konfigūracija
Daugelis įmonių klientų naudoja HTTP proxy ir tikisi, kad programos juo naudosis. Nustatymas HTTPS_PROXY apvalkale sutvarko komandinės eilutės įrankius, kurie jį gerbia, ir nieko nedaro įrankiui, kuris skaito savo nustatymų failą. Gradle, Selenium ir gRPC kiekvienas konsultuojasi su savo konfigūracija, o viename terminale eksportuotas proxy yra nematomas IDE paleistam demonui.
Konteinerių įrankiai yra įprasta vieta, kur tai tampa matoma. Konteinerio loopback yra jo paties, todėl 127.0.0.1 konteinerio viduje niekada nereiškia hosto proxy; reikia hosto adreso arba hosto tinklo nustatymo. Pataisa, kuri veikia apvalkale ir sugenda kūrime, paprastai yra ši eilutė, o ne tunelis.
Pasitikėjimo sluoksnis: įrankis skaito kitą saugyklą
Perėmimas yra antrasis pakeitimas, ir jis sukuria klaidinančiausias klaidas. Klientas pateikia savo sertifikatą tikrinamiems ryšiams, todėl naršyklė, kuri pasitiki įmonės šaknimi, pavyksta, o įrankis su įterpta CA saugykla sugenda. Python requests per certifi yra klasikinis atvejis: operacinės sistemos saugykla gali būti teisinga, o užklausa vis tiek sugenda, nes ta vykdymo aplinka jos niekada neskaito. Klaidos tekstas retai mini perėmimą, todėl ši eilutė klaidingai diagnozuojama kaip sugedęs galinis taškas.
Palyginkite, ką galinis taškas iš tikrųjų pateikia, su tuo, ką įrankis patvirtino. openssl s_client rodo serverio atsiųstą grandinę; paties įrankio tikrinimo išvestis rodo, ką jis nusprendė. Kai jie nesutampa, REQUESTS_CA_BUNDLE arba SSL_CERT_FILE yra tos vykdymo aplinkos svirtis, o įmonės šaknis priklauso saugyklai, kurią ta aplinka skaito, o ne globaliai vietai, kurią gerbia tik kai kurie įrankiai.
Versijos pakeitimas, kuris ištaiso SSL klaidą, yra įrodymas apie pasitikėjimo ir šifravimo politiką, o ne apie VPN. Python versijos sumažinimas, po kurio SOAP klientas pradėjo veikti, pakeitė įterptą CA saugyklą ir numatytuosius TLS nustatymus; tinklo kelias nepajudėjo.
Filtro sluoksnis: jis gali numesti ir loopback
Trečiasis pakeitimas yra paketų filtras, ir kai kurie produktai įdiegia taisykles, kurios numeta srautą, nepatenkantį į tunelį. Vietiniai klausytojai gali būti įtraukti. Tai paverčia veikiantį socketą atmestu arba pasibaigusiu ryšiu, o atsirandanti klaida atrodo kaip programos klaida, o ne mašinos politika.
Prievado nuosavybė yra kita šio sluoksnio pusė. BindException reiškia, kad socketo nepavyko atidaryti, o tai yra kitokia nesėkmė nei atmestas ryšys. Prieš kaltindami filtrą patikrinkite, ar prievado jau nelaiko kitas procesas, tada ieškokite taisyklės, kuri numeta vietinį srautą, ir pridėkite siauriausią leidimą, kurį produktas palaiko. Du įrankiai, konkuruojantys dėl to paties derinimo prievado, pateikia lygiai tą pačią žinutę kaip politikos blokavimas, ir tik vienas iš jų sutvarkomas pakeitus užkardą.
Chrome derinimo prievadas sugenda toje pačioje šeimoje. Naršyklė paleidžiama, tvarkyklė nepasiekia DevTools galinio taško, o žinutė įvardija DevTools, o ne tinklą. Papildomi paleidimo parametrai ir nereikalingas tvarkyklių tvarkytuvas pakeičia, kuris procesas valdo prievadą, todėl juos pašalinus kartais atrodo, kad VPN sutvarkytas.
Sutaisykite sluoksnį, kuris sugedo
Sutaisykite sluoksnį, kuris sugedo, o ne tunelį. Nepasiekiamam loopback klausytojui reikia sutvarkyti jo klausytoją arba prievadą. Nepatikimam sertifikatui reikia įmonės šaknies, įdiegtos ten, kur žiūri ta konkreti vykdymo aplinka, išimtį laikant siaurą. Filtras, numetantis vietinį srautą, reikia konkrečios leidimo taisyklės, o ne išjungto filtro, nes išjungimas vėl atidaro ir visa kita, ką jis saugojo.
VPN prijungimas iš naujo netikrina nė vieno iš šių sluoksnių. Jis tik pakartoja pakeitimą, kuris juos sugadino, todėl tie patys trys gedimai grįžta po kiekvieno prisijungimo iš naujo ir dingsta po kiekvieno perkrovimo, kuris palieka klientą neaktyvų.