mitmproxy, DevTools, Gradle: trei straturi în spatele VPN-ului

VPN-ul se conectează, și trei instrumente fără legătură eșuează în trei moduri diferite în aceeași după-amiază. mitmproxy nu mai vede cereri, Chrome refuză debugger-ul, iar Gradle aruncă BindException în timp ce leagă un socket local. Suspiciunea comună este că tunelul blochează localhost. Nu poate: 127.0.0.1 este tratat în interiorul nucleului și nu ajunge niciodată la un adaptor, darămite la o poartă.

Trei straturi, trei defecțiuni diferite

Ce s-a schimbat odată cu clientul nu este ruta către loopback. Sunt un proxy local, un depozit de încredere al mașinii și un filtru de pachete, iar fiecare strică o altă parte a fluxului de lucru al unui dezvoltator. Încadrarea simptomului în rândul corect este cea mai mare parte a diagnosticului:

Aproape fiecare raport de acest fel începe de la ultimul rând și urcă, ceea ce este invers. Tunelul este singurul strat care, în mod demonstrabil, nu poate vedea traficul loopback, așa că merită cea mai mică suspiciune. Începeți cu ce a legat procesul, apoi întrebați în ce certificate are încredere, și abia apoi uitați-vă la politica de pe mașină.

Începeți cu ascultătorul, nu cu tunelul

Când un proxy pe 127.0.0.1:8080 încetează să primească trafic, s-a întâmplat unul din trei lucruri: nu a pornit niciodată, a legat alt port, sau filtrul a renunțat la conexiunea loopback. Listarea socketurilor care ascultă răspunde la asta cu o singură comandă și arată și ce proces deține portul când două instrumente nu sunt de acord cine a fost primul.

O adresă locală într-o căutare de rută confirmă același lucru din cealaltă direcție. ip route get către o destinație loopback raportează dispozitivul loopback, niciodată tunelul, ceea ce este o propoziție utilă de pregătit când cineva propune o schimbare de rutare ca soluție.

Stratul proxy: mediul nu este configurație

Mulți clienți corporate rulează un proxy HTTP și se așteaptă ca aplicațiile să îl folosească. Setarea HTTPS_PROXY într-un shell repară instrumentele din linia de comandă care îl respectă și nu face nimic pentru un instrument care își citește propriul fișier de setări. Gradle, Selenium și gRPC consultă fiecare propria configurație, iar un proxy exportat într-un terminal este invizibil pentru un demon pornit de IDE.

Instrumentele pentru containere sunt locul obișnuit unde acest lucru devine vizibil. Loopback-ul unui container este al lui, așa că 127.0.0.1 în interiorul containerului nu înseamnă niciodată proxy-ul gazdei; este nevoie de adresa gazdei sau de o setare de rețea a gazdei. O corecție care funcționează în shell și eșuează la build este de obicei acest rând, nu tunelul.

Stratul de încredere: instrumentul citește alt depozit

Interceptarea este a doua schimbare și produce cele mai înșelătoare erori. Clientul prezintă propriul certificat pentru conexiunile inspectate, așa că un browser care are încredere în rădăcina corporate reușește, în timp ce un instrument cu un depozit CA inclus eșuează. Cererile Python prin certifi sunt cazul clasic: depozitul sistemului de operare poate fi corect și cererea tot eșuează, pentru că acel runtime nu îl citește niciodată. Textul erorii menționează rar interceptarea, motiv pentru care acest rând este diagnosticat greșit ca punct final rupt.

Comparați ce prezintă de fapt punctul final cu ce a validat instrumentul. openssl s_client arată lanțul trimis de server; ieșirea de validare a instrumentului arată ce a decis. Când nu coincid, REQUESTS_CA_BUNDLE sau SSL_CERT_FILE este pârghia pentru acel runtime, iar rădăcina corporate aparține depozitului pe care îl citește acel runtime, nu unei locații globale pe care o respectă doar unele instrumente.

O schimbare de versiune care repară o eroare SSL este o dovadă despre politica de încredere și cifrare, nu despre VPN. O retrogradare a Python care face un client SOAP să funcționeze a schimbat depozitul CA inclus și setările TLS implicite; calea de rețea nu s-a mișcat.

Stratul de filtru: poate elimina și loopback

A treia schimbare este un filtru de pachete, iar unele produse instalează reguli care elimină traficul ce nu intră în tunel. Ascultătorii locali pot fi incluși. Asta transformă un socket funcțional într-o conexiune refuzată sau expirată, iar eroarea rezultată arată ca un defect al aplicației, nu ca o politică a mașinii.

Proprietatea portului este cealaltă jumătate a acestui strat. BindException înseamnă că socketul nu a putut fi deschis, ceea ce este o altă eșuare decât o conexiune refuzată. Verificați dacă un alt proces deține deja portul înainte de a învinui filtrul, apoi căutați o regulă care elimină traficul local și adăugați cea mai îngustă permisiune pe care o acceptă produsul. Două instrumente care concurează pentru același port de depanare produc exact același mesaj ca un blocaj de politică, și doar unul dintre ele se corectează printr-o schimbare de firewall.

Portul de depanare al Chrome eșuează în aceeași familie. Browserul pornește, driverul nu ajunge la punctul final DevTools, iar mesajul numește DevTools în locul rețelei. Indicatoare suplimentare de lansare și un manager de drivere redundant schimbă ce proces deține portul, motiv pentru care eliminarea lor pare uneori să repare VPN-ul.

Reparați stratul care a eșuat

Reparați stratul care a eșuat, nu tunelul. Un ascultător loopback inaccesibil are nevoie de corectarea ascultătorului sau a portului. Un certificat neîncrezut are nevoie de rădăcina corporate instalată acolo unde se uită acel runtime specific, cu excepția ținută îngustă. Un filtru care elimină traficul local are nevoie de o regulă de permisiune concretă în locul unui filtru dezactivat, pentru că dezactivarea redeschide și tot restul pe care îl proteja.

Reconectarea VPN-ului nu testează niciunul dintre aceste straturi. Doar rulează din nou schimbarea care le-a stricat, motiv pentru care aceleași trei eșecuri revin după fiecare reconectare și dispar după fiecare repornire care lasă clientul inactiv.