mitmproxy, DevTools, Gradle: drie lae agter die VPN
Loopback bereik nooit die tonnel nie. Sorteer die simptoom in luisteraar, truststore of pakketfilter, en herstel die laag wat werklik gefaal het.
Die VPN maak verbinding, en drie onverwante instrumente misluk op drie verskillende maniere op dieselfde namiddag. mitmproxy hou op om versoeke te sien, Chrome weier die ontfouter, en Gradle gooi BindException terwyl dit 'n plaaslike sokkel bind. Die gedeelde vermoede is dat die tonnel localhost blokkeer. Dit kan nie: 127.0.0.1 word binne die kern hanteer en bereik nooit 'n adapter nie, laat staan 'n poort.
Drie lae, drie verskillende onderbrekings
Wat met die kliënt verander het, is nie die roete na loopback nie. Dit is 'n plaaslike instaanbediener, 'n masjientruststore en 'n pakketfilter, en elkeen breek 'n ander deel van 'n ontwikkelaar se werkvloei. Om 'n simptoom in die regte ry te sorteer, is die grootste deel van die diagnose:
| 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? |
Byna elke verslag van hierdie soort begin by die laaste ry en werk opwaarts, wat verkeerd is. Die tonnel is die een laag wat bewysbaar nie loopback-verkeer kan sien nie, so dit verdien die minste vermoede. Begin met wat die proses gebind het, vra dan watter sertifikate dit vertrou, en kyk eers daarna na beleid op die masjien.
Begin met die luisteraar, nie die tonnel nie
Wanneer 'n proxy op 127.0.0.1:8080 ophou om verkeer te ontvang, het een van drie dinge gebeur: dit het nooit begin nie, dit het 'n ander poort gebind, of die filter het die loopback-verbinding laat val. Om die luisterende sokkels te lys, antwoord dit in een opdrag, en dit wys ook watter proses die poort besit wanneer twee instrumente verskil oor wie eerste was.
'n Plaaslike adres in 'n roetesoek bevestig dieselfde ding uit die ander rigting. ip route get teen 'n loopback-bestemming rapporteer die loopback-toestel, nooit die tonnel nie, wat 'n nuttige sin is om gereed te hê wanneer iemand 'n roeteverandering as die oplossing voorstel.
Die proxy-laag: omgewing is nie konfigurasie nie
Baie korporatiewe kliënte het 'n HTTP-proxy en verwag dat toepassings dit gebruik. Om HTTPS_PROXY in 'n dop te stel, maak opdragreël-instrumente reg wat dit eerbiedig, en doen niks vir 'n instrument wat sy eie instellingsleer lees nie. Gradle, Selenium en gRPC raadpleeg elkeen hul eie konfigurasie, en 'n proxy wat in een terminal uitgevoer is, is onsigbaar vir 'n daemon wat deur die IDE begin is.
Houer-gereedskap is die gewone plek waar dit sigbaar word. 'n Houer se loopback is sy eie, so 127.0.0.1 binne die houer beteken nooit die gasheer se proxy nie; die gasheeradres of 'n gasheer-netwerk-instelling is nodig. 'n Oplossing wat in die dop werk en in die bou misluk, is gewoonlik hierdie ry, nie die tonnel nie.
Die trustlaag: die instrument lees 'n ander stoor
Onderskepping is die tweede verandering, en dit lewer die mees misleidende foute. Die kliënt bied sy eie sertifikaat vir ondersoekte verbindings aan, so 'n blaaier wat die korporatiewe wortel vertrou, slaag terwyl 'n instrument met 'n ingeslote CA-stoor misluk. Python se requests via certifi is die klassieke geval: die bedryfstelsel se stoor kan korrek wees en die versoek misluk steeds, want daardie looptyd lees dit nooit nie. Die foutteks noem selde onderskepping, wat is waarom hierdie ry verkeerd gediagnoseer word as 'n gebroke eindpunt.
Vergelyk wat die eindpunt werklik aanbied met wat die instrument gevalideer het. openssl s_client wys die ketting wat die bediener gestuur het; die instrument se eie valideringsuitset wys wat dit besluit het. Wanneer hulle verskil, REQUESTS_CA_BUNDLE of SSL_CERT_FILE is die hefboom vir daardie looptyd, en die korporatiewe wortel hoort in die stoor wat daardie looptyd lees, eerder as op 'n globale plek wat net sommige instrumente eerbiedig.
'n Weergaweverandering wat 'n SSL-fout regmaak, is bewyse oor trust- en syferbeleid, nie oor die VPN nie. 'n Python-afgradering wat 'n SOAP-kliënt laat werk, het die ingeslote CA-stoor en die verstek-TLS-instellings verander; die netwerkroete het nie beweeg nie.
Die filterlaag: dit kan ook loopback laat val
Die derde verandering is 'n pakketfilter, en sommige produkte installeer reëls wat verkeer laat val wat nie die tonnel binnegaan nie. Plaaslike luisteraars kan ingesluit wees. Dit verander 'n werkende sokkel in 'n geweierde of tydverstreke verbinding, en die resulterende fout lyk na 'n fout in die toepassing eerder as 'n beleid op die masjien.
Poortbesit is die ander helfte van hierdie laag. 'n BindException beteken die sokkel kon nie oopgemaak word nie, wat 'n ander mislukking is as 'n verbinding wat geweier word. Kyk of 'n ander proses die poort reeds hou voordat jy die filter blameer, soek dan na 'n reël wat plaaslike verkeer laat val en voeg die smalste toelating by wat die produk ondersteun. Twee instrumente wat om dieselfde ontfouterpoort meeding, lewer presies dieselfde boodskap as 'n beleidsblok, en net een van hulle word deur 'n vuurmuurverandering reggemaak.
Chrome se ontfouterpoort faal in dieselfde familie. Die blaaier begin, die drywer kan nie die DevTools-eindpunt bereik nie, en die boodskap noem DevTools eerder as die netwerk. Ekstra lanseringsvlae en 'n oorbodige drywerbestuurder verander watter proses die poort besit, wat is waarom die verwydering daarvan soms lyk of dit die VPN regmaak.
Herstel die laag wat gefaal het
Herstel die laag wat gefaal het, nie die tonnel nie. 'n Onbereikbare loopback-luisteraar het sy luisteraar of sy poort nodig om reggestel te word. 'n Onvertroude sertifikaat het die korporatiewe wortel nodig wat geïnstalleer is waar daardie spesifieke looptyd kyk, met die uitsondering smal gehou. 'n Filter wat plaaslike verkeer laat val, het 'n spesifieke toelatingsreël nodig eerder as 'n gedeaktiveerde filter, want deaktivering heropen ook alles anders wat dit beskerm het.
Om die VPN weer te verbind, toets nie een van hierdie lae nie. Dit hardloop net weer die verandering wat hulle gebreek het, wat is waarom dieselfde drie mislukkings ná elke herverbinding terugkom en ná elke herlaai verdwyn wat die kliënt onaktief laat.