mitmproxy, DevTools, Gradle: tre lager bakom VPN:en
Loopback hamnar aldrig i tunneln. Sortera symptomet som lyssnare, förtroendelager eller paketfilter och reparera lagret som faktiskt misslyckades.
VPN:en ansluter, och tre oberoende verktyg misslyckas på tre olika sätt samma eftermiddag. mitmproxy slutar se förfrågningar, Chrome vägrar debugger, och Gradle kastar BindException när den binder en lokal socket. Den gemensamma misstanken är att tunneln blockerar localhost. Det kan den inte: 127.0.0.1 hanteras inuti kärnan och når aldrig en adapter, än mindre en gateway.
Tre lager, tre olika brott
Det som förändrades med klienten är inte vägen till loopback. Det är en lokal proxy, ett förtroendelager på maskinen och ett paketfilter, och var och en bryter en annan del av en utvecklares arbetsflöde. Att placera symptomet i rätt rad är det mesta 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? |
Nästan varje rapport av det här slaget börjar vid sista raden och arbetar uppåt, vilket är bakvänt. Tunneln är det enda lager som bevisligen inte kan se loopback-trafik, så den förtjänar minst misstanke. Börja med vad processen band, fråga sedan vilka certifikat den litar på, och titta först efteråt på policyn på maskinen.
Börja med lyssnaren, inte tunneln
När en proxy på 127.0.0.1:8080 slutar ta emot trafik har en av tre saker hänt: den startade aldrig, den band en annan port, eller filtret släppte loopback-anslutningen. Att lista de lyssnande socketarna svarar på det med ett enda kommando, och det visar också vilken process som äger porten när två verktyg inte är överens om vem som var först.
En lokal adress i en ruttuppslagning bekräftar samma sak från andra hållet. ip route get mot ett loopback-mål rapporterar loopback-enheten, aldrig tunneln, vilket är en användbar mening att ha redo när någon föreslår en ruttändring som lösning.
Proxy-lagret: miljö är inte konfiguration
Många företagsklienter kör en HTTP-proxy och förväntar sig att program använder den. Att sätta HTTPS_PROXY i ett skal reparerar kommandoradsverktyg som respekterar den, och gör ingenting för ett verktyg som läser sin egen inställningsfil. Gradle, Selenium och gRPC konsulterar var sin konfiguration, och en proxy exporterad i en terminal är osynlig för en daemon som startats av IDE:n.
Containerverktyg är den vanliga platsen där detta blir synligt. En containers loopback är dess egen, så 127.0.0.1 inuti containern betyder aldrig värdens proxy; värdens adress eller en värdnätverksinställning krävs. En rättelse som fungerar i skalet och misslyckas i bygget är oftast den här raden, inte tunneln.
Förtroendelagret: verktyget läser ett annat lager
Avlyssning är den andra ändringen, och den producerar de mest vilseledande felen. Klienten presenterar sitt eget certifikat för inspekterade anslutningar, så en webbläsare som litar på företagsroten lyckas medan ett verktyg med ett inbäddat CA-lager misslyckas. Pythons requests via certifi är det klassiska fallet: operativsystemets lager kan vara korrekt och begäran misslyckas ändå, eftersom den körmiljön aldrig läser det. Feltexten nämner sällan avlyssning, och därför diagnoseras den här raden felaktigt som en trasig slutpunkt.
Jämför vad slutpunkten faktiskt presenterar med vad verktyget validerade. openssl s_client visar kedjan som servern skickade; verktygets egen valideringsutdata visar vad det beslutade. När de inte stämmer, REQUESTS_CA_BUNDLE eller SSL_CERT_FILE är spaken för den körmiljön, och företagsroten hör hemma i det lager som den körmiljön läser, inte på en global plats som bara vissa verktyg respekterar.
En versionsändring som rättar ett SSL-fel är bevis om förtroende- och chifferpolicy, inte om VPN:en. En Python-nedgradering som får en SOAP-klient att fungera ändrade det inbäddade CA-lagret och standard-TLS-inställningarna; nätverksvägen flyttade sig inte.
Filterlagret: det kan också släppa loopback
Den tredje ändringen är ett paketfilter, och vissa produkter installerar regler som släpper trafik som inte kommer in i tunneln. Lokala lyssnare kan omfattas. Det gör en fungerande socket till en avvisad eller utgången anslutning, och felet som uppstår ser ut som en bugg i programmet snarare än en policy på maskinen.
Portägande är den andra halvan av detta lager. BindException betyder att socketen inte kunde öppnas, vilket är ett annat fel än en avvisad anslutning. Kontrollera om en annan process redan håller porten innan du skyller på filtret, leta sedan efter en regel som släpper lokal trafik och lägg till den snävaste tillåtelse som produkten stöder. Två verktyg som konkurrerar om samma debug-port ger exakt samma meddelande som en policyblockering, och bara ett av dem rättas av en brandväggsändring.
Chromedebugporten misslyckas i samma familj. Webbläsaren startar, drivrutinen når inte DevTools-slutpunkten, och meddelandet namnger DevTools i stället för nätverket. Extra startflaggor och en överflödig drivrutinshanterare ändrar vilken process som äger porten, och därför ser det ibland ut som att borttagning av dem reparerar VPN:en.
Reparera lagret som misslyckades
Reparera lagret som misslyckades, inte tunneln. En oåtkomlig loopback-lyssnare behöver att lyssnaren eller porten rättas. Ett icke betrott certifikat behöver företagsroten installerad där just den körmiljön tittar, med undantaget hållet snävt. Ett filter som släpper lokal trafik behöver en specifik tillåtelseregel i stället för ett inaktiverat filter, eftersom inaktivering också öppnar allt annat det skyddade.
Att återansluta VPN:en testar inget av dessa lager. Det kör bara om ändringen som bröt dem, och därför kommer samma tre fel tillbaka efter varje återanslutning och försvinner efter varje omstart som lämnar klienten inaktiv.