mitmproxy, DevTools, Gradle: tre lag bak VPN-en
Loopback kommer aldri inn i tunnelen. Sorter symptomet som lytter, tillitslager eller pakkefilter, og reparer laget som faktisk feilet.
VPN-en kobler til, og tre uavhengige verktøy feiler på tre forskjellige måter samme ettermiddag. mitmproxy slutter å se forespørsler, Chrome nekter debuggeren, og Gradle kaster BindException mens den binder en lokal socket. Den felles mistanken er at tunnelen blokkerer localhost. Det kan den ikke: 127.0.0.1 håndteres inne i kjernen og når aldri en adapter, enn si en gateway.
Tre lag, tre forskjellige brudd
Det som endret seg med klienten, er ikke ruten til loopback. Det er en lokal proxy, et maskinelt tillitslager og et pakkefilter, og hver av dem ødelegger en ulik del av en utviklers arbeidsflyt. Å sortere et symptom i riktig rad er det meste av diagnosen:
| 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? |
Nesten hver rapport av denne typen starter ved den siste raden og arbeider oppover, noe som er bakvendt. Tunnelen er det ene laget som beviselig ikke kan se loopback-trafikk, så den fortjener minst mistanke. Begynn med det prosessen bandt, spør deretter hvilke sertifikater den stoler på, og se først etterpå på policyen på maskinen.
Begynn med lytteren, ikke tunnelen
Når en proxy på 127.0.0.1:8080 slutter å motta trafikk, har en av tre ting skjedd: den startet aldri, den bandt en annen port, eller filteret droppet loopback-forbindelsen. Å liste de lyttende socketene svarer på det med én kommando, og det viser også hvilken prosess som eier porten når to verktøy er uenige om hvem som var først.
En lokal adresse i et ruteoppslag bekrefter det samme fra den andre siden. ip route get mot en loopback-destinasjon rapporterer loopback-enheten, aldri tunnelen, noe som er en nyttig setning å ha klar når noen foreslår en ruteendring som løsning.
Proxy-laget: miljø er ikke konfigurasjon
Mange bedriftsklienter kjører en HTTP-proxy og forventer at applikasjoner bruker den. Å sette HTTPS_PROXY i et skall reparerer kommandolinjeverktøy som respekterer den, og gjør ingenting for et verktøy som leser sin egen innstillingsfil. Gradle, Selenium og gRPC konsulterer hver sin konfigurasjon, og en proxy eksportert i én terminal er usynlig for en daemon startet av IDE-en.
Containerverktøy er det vanlige stedet der dette blir synlig. En containers loopback er dens egen, så 127.0.0.1 inne i containeren betyr aldri vertens proxy; vertens adresse eller en vertsnettverksinnstilling er nødvendig. En rettelse som virker i skallet og feiler i bygget, er vanligvis denne raden, ikke tunnelen.
Tillitslaget: verktøyet leser et annet lager
Avlytting er den andre endringen, og den produserer de mest misvisende feilene. Klienten presenterer sitt eget sertifikat for inspiserte forbindelser, så en nettleser som stoler på bedriftsroten lykkes, mens et verktøy med et innebygd CA-lager feiler. Pythons requests via certifi er det klassiske tilfellet: operativsystemets lager kan være riktig, og forespørselen feiler likevel, fordi den kjøretiden aldri leser det. Feilteksten nevner sjelden avlytting, og derfor diagnostiseres denne raden feil som et ødelagt endepunkt.
Sammenlign hva endepunktet faktisk presenterer med hva verktøyet validerte. openssl s_client viser kjeden serveren sendte; verktøyets egen valideringsutdata viser hva det bestemte. Når de ikke stemmer, REQUESTS_CA_BUNDLE eller SSL_CERT_FILE er spaken for den kjøretiden, og bedriftsroten hører hjemme i lageret den kjøretiden leser, ikke på et globalt sted som bare noen verktøy respekterer.
En versjonsendring som retter en SSL-feil, er bevis om tillits- og chifferpolicy, ikke om VPN-en. En Python-nedgradering som får en SOAP-klient til å virke, endret det innebygde CA-lageret og standard-TLS-innstillingene; nettverksstien flyttet seg ikke.
Filterlaget: det kan også droppe loopback
Den tredje endringen er et pakkefilter, og noen produkter installerer regler som dropper trafikk som ikke kommer inn i tunnelen. Lokale lyttere kan være inkludert. Det gjør en fungerende socket til en avvist eller utløpt forbindelse, og feilen som oppstår, ser ut som en feil i applikasjonen snarere enn en policy på maskinen.
Porteierskap er den andre halvdelen av dette laget. BindException betyr at socketen ikke kunne åpnes, noe som er en annen feil enn en avvist forbindelse. Sjekk om en annen prosess allerede holder porten før du klandrer filteret, og se deretter etter en regel som dropper lokal trafikk, og legg til den smaleste tillatelsen produktet støtter. To verktøy som konkurrerer om samme debug-port gir nøyaktig samme melding som en policyblokkering, og bare ett av dem rettes av en brannmur-endring.
Chromedebugporten feiler i samme familie. Nettleseren starter, driveren når ikke DevTools-endepunktet, og meldingen nevner DevTools i stedet for nettverket. Ekstra oppstartsflagg og en overflødig driverbehandler endrer hvilken prosess som eier porten, og derfor ser det noen ganger ut som om fjerning av dem retter VPN-en.
Reparer laget som feilet
Reparer laget som feilet, ikke tunnelen. En uoppnåelig loopback-lytter trenger at lytteren eller porten rettes. Et ikke-klarert sertifikat trenger bedriftsroten installert der nettopp den kjøretiden ser, med unntaket holdt smalt. Et filter som dropper lokal trafikk, trenger en spesifikk tillatelsesregel i stedet for et deaktivert filter, fordi deaktivering også åpner alt annet det beskyttet.
Å koble til VPN-en på nytt tester ingen av disse lagene. Det kjører bare endringen som brøt dem, på nytt, og derfor kommer de samme tre feilene tilbake etter hver tilkobling og forsvinner etter hver omstart som lar klienten være inaktiv.