mitmproxy, DevTools, Gradle: tre lag bag VPN'en
Loopback kommer aldrig ind i tunnelen. Sorter symptomet som lytter, tillidslager eller pakkefilter, og reparer det lag, der faktisk fejlede.
VPN'en forbinder, og tre uafhængige værktøjer fejler på tre forskellige måder samme eftermiddag. mitmproxy holder op med at se anmodninger, Chrome afviser debuggeren, og Gradle kaster BindException mens den binder en lokal socket. Den fælles mistanke er, at tunnelen blokerer localhost. Det kan den ikke: 127.0.0.1 håndteres inde i kernen og når aldrig en adapter, endsige en gateway.
Tre lag, tre forskellige brud
Det, der ændrede sig med klienten, er ikke ruten til loopback. Det er en lokal proxy, et maskinligt tillidslager og et pakkefilter, og hver af dem ødelægger en forskellig del af en udviklers arbejdsgang. At sortere et symptom i den rigtige række er det meste af 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? |
Næsten enhver rapport af denne slags starter ved den sidste række og arbejder opad, hvilket er bagvendt. Tunnelen er det ene lag, der beviseligt ikke kan se loopback-trafik, så den fortjener den mindste mistanke. Begynd med det, processen bandt, spørg derefter, hvilke certifikater den stoler på, og se først derefter på politikken på maskinen.
Begynd med lytteren, ikke tunnelen
Når en proxy på 127.0.0.1:8080 holder op med at modtage trafik, er en af tre ting sket: den startede aldrig, den bandt en anden port, eller filteret droppede loopback-forbindelsen. At liste de lyttende sockets besvarer det med én kommando, og det viser også, hvilken proces der ejer porten, når to værktøjer er uenige om, hvem der var først.
En lokal adresse i et ruteopslag bekræfter det samme fra den anden side. ip route get mod en loopback-destination rapporterer loopback-enheden, aldrig tunnelen, hvilket er en nyttig sætning at have klar, når nogen foreslår en ruteændring som løsningen.
Proxy-laget: miljø er ikke konfiguration
Mange virksomhedsklienter kører en HTTP-proxy og forventer, at applikationer bruger den. At sætte HTTPS_PROXY i en shell retter kommandolinjeværktøjer, der respekterer den, og gør intet for et værktøj, der læser sin egen indstillingsfil. Gradle, Selenium og gRPC konsulterer hver deres egen konfiguration, og en proxy eksporteret i én terminal er usynlig for en daemon startet af IDE'en.
Container-værktøjer er det sædvanlige sted, hvor dette bliver synligt. En containers loopback er dens egen, så 127.0.0.1 inde i containeren betyder aldrig værtens proxy; værtens adresse eller en vært-netværksindstilling er påkrævet. En rettelse, der virker i shellen og fejler i buildet, er normalt denne række, ikke tunnelen.
Tillidslaget: værktøjet læser et andet lager
Aflytning er den anden ændring, og den producerer de mest vildledende fejl. Klienten præsenterer sit eget certifikat for inspicerede forbindelser, så en browser, der stoler på virksomhedsroden, lykkes, mens et værktøj med et medfølgende CA-lager fejler. Pythons requests via certifi er det klassiske tilfælde: operativsystemets lager kan være korrekt, og anmodningen fejler stadig, fordi den kørselsmotor aldrig læser det. Fejlteksten nævner sjældent aflytning, og derfor diagnosticeres denne række forkert som et brudt endepunkt.
Sammenlign, hvad endepunktet faktisk præsenterer, med hvad værktøjet validerede. openssl s_client viser kæden, som serveren sendte; værktøjets egen valideringsoutput viser, hvad det besluttede. Når de er uenige, REQUESTS_CA_BUNDLE eller SSL_CERT_FILE er håndtaget for den kørselsmotor, og virksomhedsroden hører til i det lager, den kørselsmotor læser, snarere end på et globalt sted, som kun nogle værktøjer respekterer.
En versionsændring, der retter en SSL-fejl, er bevis om tillids- og cipherpolitik, ikke om VPN'en. En Python-nedgradering, der får en SOAP-klient til at virke, ændrede det medfølgende CA-lager og standard-TLS-indstillingerne; netværksstien flyttede sig ikke.
Filterlaget: det kan også droppe loopback
Den tredje ændring er et pakkefilter, og nogle produkter installerer regler, der dropper trafik, som ikke kommer ind i tunnelen. Lokale lyttere kan være omfattet. Det gør en fungerende socket til en afvist eller udløbet forbindelse, og den resulterende fejl ligner en fejl i applikationen snarere end en politik på maskinen.
Portejerskab er den anden halvdel af dette lag. BindException betyder, at socketen ikke kunne åbnes, hvilket er en anden fejl end en afvist forbindelse. Tjek, om en anden proces allerede holder porten, før du bebrejder filteret, og led derefter efter en regel, der dropper lokal trafik, og tilføj den snævreste tilladelse, produktet understøtter. To værktøjer, der konkurrerer om den samme debug-port, giver præcis samme meddelelse som en politikblokering, og kun det ene af dem rettes af en firewallændring.
Debug-porten i Chrome fejler i samme familie. Browseren starter, driveren kan ikke nå DevTools-endepunktet, og meddelelsen nævner DevTools snarere end netværket. Ekstra startflag og en overflødig driver manager ændrer, hvilken proces der ejer porten, og derfor ser det nogle gange ud som om, at fjernelse af dem retter VPN'en.
Reparer det lag, der fejlede
Reparer det lag, der fejlede, ikke tunnelen. En uopnåelig loopback-lytter har brug for, at dens lytter eller port rettes. Et ikke-betroet certifikat har brug for virksomhedsroden installeret der, hvor netop den kørselsmotor kigger, med undtagelsen holdt snæver. Et filter, der dropper lokal trafik, har brug for en specifik tilladelsesregel i stedet for et deaktiveret filter, fordi deaktivering også genåbner alt andet, det beskyttede.
At genoprette forbindelsen til VPN'en tester ingen af disse lag. Det kører kun ændringen, der brød dem, igen, og derfor kommer de samme tre fejl tilbage efter hver genforbindelse og forsvinder efter hver genstart, der efterlader klienten inaktiv.