mitmproxy, DevTools, Gradle: tre lag bak VPN-en
Loopback kjem aldri inn i tunnelen. Sorter symptomet som lyttar, tillitslager eller pakkefilter, og reparer laget som faktisk feila.
VPN-en koplar til, og tre uavhengige verktøy feilar på tre ulike måtar same ettermiddag. mitmproxy sluttar å sjå førespurnader, Chrome nektar debuggeren, og Gradle kastar BindException medan han bind ein lokal socket. Den felles mistanken er at tunnelen blokkerer localhost. Det kan han ikkje: 127.0.0.1 vert handsama inne i kjernen og når aldri ein adapter, enn se ein gateway.
Tre lag, tre ulike brot
Det som endra seg med klienten, er ikkje ruta til loopback. Det er ein lokal proxy, eit maskinelt tillitslager og eit pakkefilter, og kvar av dei øydelegg ein ulik del av arbeidsflyten til ein utviklar. Å sortere eit symptom i rett 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 kvar rapport av denne typen startar ved den siste rada og arbeider oppover, noko som er bakvendt. Tunnelen er det eine laget som provbart ikkje kan sjå loopback-trafikk, så han fortener minst mistanke. Byrja med det prosessen bandt, spør deretter kva sertifikat han stolar på, og sjå først etterpå på policyen på maskinen.
Byrja med lyttaren, ikkje tunnelen
Når ein proxy på 127.0.0.1:8080 sluttar å ta imot trafikk, har ein av tre ting skjedd: han starta aldri, han bandt ein annan port, eller filteret slapp loopback-sambandet. Å liste dei lyttande socketane svarar på det med éin kommando, og det viser også kva prosess som eig porten når to verktøy er usamde om kven som var først.
Ei lokal adresse i eit ruteoppslag stadfestar det same frå den andre sida. ip route get mot ein loopback-destinasjon rapporterer loopback-eininga, aldri tunnelen, noko som er ei nyttig setning å ha klar når nokon føreslår ei ruteendring som løysing.
Proxy-laget: miljø er ikkje konfigurasjon
Mange bedriftsklientar køyrer ein HTTP-proxy og forventar at applikasjonar brukar han. Å setje HTTPS_PROXY i eit skal reparerer kommandolinjeverktøy som respekterer han, og gjer ingenting for eit verktøy som les si eiga innstillingsfil. Gradle, Selenium og gRPC konsulterer kvar sin konfigurasjon, og ein proxy eksportert i éin terminal er usynleg for ein daemon starta av IDE-en.
Containerverktøy er den vanlege staden der dette blir synleg. Loopbacken til ein container er hans eigen, så 127.0.0.1 inne i containeren betyr aldri proxyen til verten; vertsadressa eller ei vertsnettverksinnstilling er nødvendig. Ei retting som verkar i skalet og feilar i bygget, er vanlegvis denne rada, ikkje tunnelen.
Tillitslaget: verktøyet les eit anna lager
Avlytting er den andre endringa, og ho produserer dei mest misvisande feila. Klienten presenterer sitt eige sertifikat for inspiserte samband, så ein nettlesar som stolar på bedriftsrota lukkast, medan eit verktøy med eit innebygd CA-lager feilar. Pythons requests via certifi er det klassiske tilfellet: lageret til operativsystemet kan vere riktig, og førespurnaden feilar likevel, fordi den køyretida aldri les det. Feilteksten nemner sjeldan avlytting, og difor blir denne rada feil diagnostisert som eit øydelagt endepunkt.
Samanlikn kva endepunktet faktisk presenterer med kva verktøyet validerte. openssl s_client viser kjeda serveren sende; verktøyet si eiga valideringsutdata viser kva det bestemte. Når dei ikkje stemmer, REQUESTS_CA_BUNDLE eller SSL_CERT_FILE er spaken for den køyretida, og bedriftsrota høyrer heime i lageret den køyretida les, ikkje på ein global stad som berre nokre verktøy respekterer.
Ei versjonsendring som rettar ein SSL-feil, er prov om tillits- og chifferpolicy, ikkje om VPN-en. Ein Python-nedgradering som får ein SOAP-klient til å verke, endra det innebygde CA-lageret og standard-TLS-innstillingane; nettverksstien flytta seg ikkje.
Filterlaget: det kan også droppe loopback
Den tredje endringa er eit pakkefilter, og nokre produkt installerar reglar som droppar trafikk som ikkje kjem inn i tunnelen. Lokale lyttarar kan vere inkluderte. Det gjer ein fungerande socket til ein avvist eller utløpt samband, og feilen som oppstår, ser ut som ein feil i applikasjonen snarare enn ein policy på maskinen.
Porteige er den andre halvdelen av dette laget. BindException betyr at socketen ikkje kunne opnast, noko som er ein annan feil enn eit avvist samband. Sjekk om ein annan prosess allereie held porten før du klandrar filteret, og sjå deretter etter ein regel som droppar lokal trafikk, og legg til den smalaste løyve produktet støttar. To verktøy som konkurrerer om same debug-port gir nøyaktig same melding som ei policyblokkering, og berre eitt av dei blir retta av ei brannmur-endring.
Chromedebugporten feilar i same familie. Nettlesaren startar, drivaren når ikkje DevTools-endepunktet, og meldinga nemner DevTools i staden for nettverket. Ekstra oppstartsflagg og ein overflødig drivarhandsamar endrar kva prosess som eig porten, og difor ser det nokre gonger ut som om fjerning av dei rettar VPN-en.
Reparer laget som feila
Reparer laget som feila, ikkje tunnelen. Ein uoppnåeleg loopback-lyttar treng at lyttaren eller porten blir retta. Eit ikkje-klarert sertifikat treng bedriftsrota installert der nettopp den køyretida ser, med unntaket halde smalt. Eit filter som droppar lokal trafikk, treng ein spesifikk løyveregel i staden for eit deaktivert filter, fordi deaktivering også opnar alt anna det verna.
Å kople til VPN-en på nytt testar ingen av desse laga. Det køyrer berre endringa som braut dei, på nytt, og difor kjem dei same tre feila tilbake etter kvar tilkopling og forsvinn etter kvar omstart som lèt klienten vere inaktiv.