mitmproxy, DevTools, Gradle: tri plasti za VPN
Loopback nikoli ne vstopi v tunel. Razvrstite simptom kot poslušalec, shramba zaupanja ali paketni filter in popravite plast, ki je res odpovedala.
VPN se poveže, in tri nepovezana orodja odpovedo na tri različne načine isto popoldne. mitmproxy ne vidi več zahtev, Chrome zavrne razhroščevalnik, Gradle pa vrže BindException med vezavo lokalnega vtiča. Skupni sum je, da tunel blokira localhost. Ne more: 127.0.0.1 se obdeluje znotraj jedra in nikoli ne doseže adapterja, kaj šele prehoda.
Tri plasti, tri različne okvare
Kar se je spremenilo s odjemalcem, ni pot do loopbacka. To so lokalni proxy, shramba zaupanja stroja in paketni filter, in vsak od njih zlomi drug del razvijalčevega delovnega toka. Razvrščanje simptoma v pravo vrstico je večina diagnoze:
| 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? |
Skoraj vsako poročilo te vrste se začne pri zadnji vrstici in gre navzgor, kar je obrnjeno. Tunel je edina plast, ki dokazljivo ne more videti prometa loopback, zato si zasluži najmanj suma. Začnite s tem, kar je proces vezal, nato vprašajte, katerim potrdilom zaupa, in šele nato poglejte politiko na stroju.
Začnite s poslušalcem, ne s tunelom
Ko proxy na 127.0.0.1:8080 preneha prejemati promet, se je zgodilo eno od treh: ni se nikoli zagnal, vezal je druga vrata ali pa je filter spustil povezavo loopback. Seznam poslušajočih vtičev odgovori na to z enim ukazom in pokaže tudi, kateri proces ima vrata, ko se dve orodji ne strinjata, kdo je bil prvi.
Lokalni naslov pri iskanju poti potrjuje isto z druge strani. ip route get proti cilju loopback poroča napravo loopback, nikoli tunela, kar je koristen stavek, ki ga velja imeti pripravljenega, ko nekdo predlaga spremembo usmerjanja kot rešitev.
Plast proxyja: okolje ni konfiguracija
Mnogi poslovni odjemalci poganjajo proxy HTTP in pričakujejo, da ga bodo aplikacije uporabljale. Nastavitev HTTPS_PROXY v lupini popravi orodja ukazne vrstice, ki ga spoštujejo, in ne naredi ničesar za orodje, ki bere svojo lastno nastavitveno datoteko. Gradle, Selenium in gRPC se vsak posvetuje s svojo konfiguracijo, proxy, izvožen v enem terminalu, pa je neviden za demonski proces, ki ga zažene IDE.
Orodja za vsebnike so običajno mesto, kjer to postane vidno. Loopback vsebnika je njegov lasten, zato 127.0.0.1 znotraj vsebnika nikoli ne pomeni proxyja gostitelja; potreben je naslov gostitelja ali nastavitev gostiteljskega omrežja. Popravek, ki deluje v lupini in odpove pri gradnji, je običajno ta vrstica, ne tunel.
Plast zaupanja: orodje bere drugo shrambo
Prestrezanje je druga sprememba in ustvarja najbolj zavajajoče napake. Odjemalec predstavi lastno potrdilo za pregledane povezave, zato brskalnik, ki zaupa poslovnemu korenu, uspe, medtem ko orodje z vgrajeno shrambo CA odpove. requests Pythona prek certifi je klasičen primer: shramba operacijskega sistema je lahko pravilna, zahteva pa vseeno odpove, ker to izvajalno okolje je nikoli ne prebere. Besedilo napake redko omenja prestrezanje, zato je ta vrstica napačno diagnosticirana kot pokvarjena končna točka.
Primerjajte, kaj končna točka dejansko predstavi, s tem, kar je orodje preverilo. openssl s_client prikaže verigo, ki jo je poslal strežnik; lastni izhod preverjanja orodja pokaže, kaj se je odločilo. Ko se ne ujemata, REQUESTS_CA_BUNDLE ali SSL_CERT_FILE je vzvod za to izvajalno okolje, in poslovni koren spada v shrambo, ki jo to okolje bere, ne na globalno mesto, ki ga spoštuje le nekaj orodij.
Sprememba različice, ki popravi napako SSL, je dokaz o politiki zaupanja in šifriranja, ne o VPN. Znižanje različice Pythona, zaradi katerega odjemalec SOAP začne delovati, je spremenilo vgrajeno shrambo CA in privzete nastavitve TLS; omrežna pot se ni premaknila.
Plast filtra: tudi ta lahko spusti loopback
Tretja sprememba je paketni filter in nekateri izdelki namestijo pravila, ki spustijo promet, ki ne vstopi v tunel. Zajeti so lahko tudi lokalni poslušalci. To spremeni delujoč vtič v zavrnjeno ali poteklo povezavo, nastala napaka pa je videti kot hrošč v aplikaciji, ne kot politika na stroju.
Lastništvo vrat je druga polovica te plasti. BindException pomeni, da vtiča ni bilo mogoče odpreti, kar je drugačna okvara od zavrnjene povezave. Preden obtožite filter, preverite, ali vrata že drži drug proces, nato poiščite pravilo, ki spusti lokalni promet, in dodajte najožje dovoljenje, ki ga izdelek podpira. Dve orodji, ki tekmujeta za ista vrata za razhroščevanje, ustvarita natanko enako sporočilo kot blokada s politiko, in le eno od njiju popravi sprememba požarnega zidu.
Vrata za razhroščevanje Chrome odpovejo v isti družini. Brskalnik se zažene, gonilnik ne doseže končne točke DevTools in sporočilo navede DevTools namesto omrežja. Dodatne zagonske zastavice in odvečni upravitelj gonilnikov spremenijo, kateri proces ima vrata, zato je videti, da njihova odstranitev včasih popravi VPN.
Popravite plast, ki je odpovedala
Popravite plast, ki je odpovedala, ne tunela. Nedosegljiv poslušalec loopback potrebuje popravek poslušalca ali vrat. Nekemu potrdilu je treba poslovni koren namestiti tja, kamor gleda to določeno izvajalno okolje, izjema pa naj bo ozka. Filter, ki spusti lokalni promet, potrebuje posebno pravilo dovoljenja namesto izklopljenega filtra, ker izklop znova odpre tudi vse drugo, kar je ščitil.
Ponovna povezava VPN ne preizkusi nobene od teh plasti. Samo znova izvede spremembo, ki jih je zlomila, zato se iste tri okvare vrnejo po vsaki ponovni povezavi in izginejo po vsakem ponovnem zagonu, ki odjemalca pusti neaktivnega.