mitmproxy, DevTools, Gradle: kolm kihti VPN-i taga
Loopback ei jõua kunagi tunnelisse. Sortige sümptom kuulaja, usaldushoidla või paketifiltri alla ja parandage kiht, mis tegelikult ebaõnnestus.
VPN ühendub ja kolm omavahel seostumatut tööriista ebaõnnestuvad kolmel erineval viisil samal pärastlõunal. mitmproxy lakkab päringuid nägemast, Chrome keeldub silurist ja Gradle viskab BindException kohalikku socketit sidudes. Ühine kahtlus on, et tunnel blokeerib localhosti. See ei saa: 127.0.0.1 käsitletakse tuuma sees ja ei jõua kunagi adapterini, rääkimata lüüsist.
Kolm kihti, kolm erinevat riket
Kliendiga muutus mitte loopbacki tee. Muutusid kohalik puhverserver, masina usaldushoidla ja paketifilter ning igaüks neist lõhub arendaja töövoo erinevat osa. Sümptomi õigesse ritta sorteerimine on suurem osa diagnoosist:
| 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? |
Peaaegu iga selline raport algab viimasest reast ja liigub ülespoole, mis on tagurpidi. Tunnel on ainus kiht, mis tõestatavalt ei näe loopbacki liiklust, seega väärib see kõige vähem kahtlust. Alustage sellest, mille protsess sidus, seejärel küsige, milliseid sertifikaate see usaldab, ja alles siis vaadake masina poliitikat.
Alustage kuulajast, mitte tunnelist
Kui puhverserver aadressil 127.0.0.1:8080 lakkab liiklust vastu võtmast, juhtus üks kolmest: see ei käivitunud kunagi, sidus teise pordi või filter viskas loopbacki ühenduse kõrvale. Kuulavate socketite loetlemine vastab sellele ühe käsuga ja näitab ka, milline protsess pordi omanik on, kui kaks tööriista ei nõustu, kes oli esimene.
Kohalik aadress marsruudiotsingus kinnitab sama teisest suunast. ip route get loopbacki sihtkoha suunas teatab loopbacki seadmest, mitte kunagi tunnelist, mis on kasulik lause valmis hoida, kui keegi pakub parandusena marsruudimuudatust.
Puhverserveri kiht: keskkond ei ole konfiguratsioon
Paljud ettevõttekliendid käitavad HTTP-puhverserverit ja eeldavad, et rakendused seda kasutavad. Selle seadistamine HTTPS_PROXY shellis parandab käsureatööriistu, mis seda austavad, ja ei tee midagi tööriista jaoks, mis loeb oma seadefaili. Gradle, Selenium ja gRPC konsulteerivad igaüks oma konfiguratsiooni ja ühes terminalis eksporditud puhverserver on IDE käivitatud deemonile nähtamatu.
Konteineritööriistad on tavaline koht, kus see nähtavaks saab. Konteineri loopback on tema oma, seega 127.0.0.1 konteineri sees ei tähenda kunagi hosti puhverserverit; vaja on hosti aadressi või hosti võrgu seadet. Parandus, mis töötab shellis ja ebaõnnestub buildis, on tavaliselt see rida, mitte tunnel.
Usalduskiht: tööriist loeb teist hoidlat
Vahendamine on teine muudatus ja tekitab kõige eksitavamaid vigu. Klient esitab kontrollitud ühenduste jaoks oma sertifikaadi, nii et ettevõtte juurt usaldav brauser õnnestub, samal ajal kui kaasatud CA-hoidlaga tööriist ebaõnnestub. Pythoni requests certifi kaudu on klassikaline juhtum: operatsioonisüsteemi hoidla võib olla õige ja päring siiski ebaõnnestub, sest see käituskeskkond ei loe seda kunagi. Veatekst mainib vahendamist harva, mistõttu diagnoositakse see rida ekslikult katkise lõpp-punktina.
Võrrelge, mida lõpp-punkt tegelikult esitab, sellega, mida tööriist valideeris. openssl s_client näitab ahelat, mille server saatis; tööriista enda valideerimisväljund näitab, mida see otsustas. Kui need ei ühti, REQUESTS_CA_BUNDLE või SSL_CERT_FILE on selle käituskeskkonna hoob, ja ettevõtte juur kuulub hoidlasse, mida see käituskeskkond loeb, mitte globaalsesse kohta, mida austavad ainult mõned tööriistad.
SSL-viga parandav versioonimuudatus on tõend usaldus- ja šifripoliitika kohta, mitte VPN-i kohta. Pythoni versiooni langetamine, mis pani SOAP-kliendi tööle, muutis kaasatud CA-hoidlat ja vaikimisi TLS-seadeid; võrgutee ei liikunud.
Filtrikiht: see võib samuti loopbacki kõrvale visata
Kolmas muudatus on paketifilter ja mõned tooted paigaldavad reegleid, mis viskavad kõrvale liikluse, mis ei sisene tunnelisse. Kohalikud kuulajad võivad olla hõlmatud. See muudab töötava socketi keeldutud või aegunud ühenduseks ja sellest tulenev viga näeb välja nagu viga rakenduses, mitte masina poliitika.
Pordi omand on selle kihi teine pool. BindException tähendab, et socketit ei saanud avada, mis on teistsugune tõrge kui keeldutud ühendus. Enne filtri süüdistamist kontrollige, kas mõni teine protsess juba hoiab porti, seejärel otsige reeglit, mis viskab kohaliku liikluse kõrvale, ja lisage kitsaim luba, mida toode toetab. Kaks sama silumisporti pärast võistlevat tööriista annavad täpselt sama sõnumi nagu poliitikablokeering ja ainult ühte neist parandab tulemüüri muudatus.
Chrome'i silumisport ebaõnnestub samas peres. Brauser käivitub, draiver ei jõua DevToolsi lõpp-punktini ja sõnum nimetab DevToolsi, mitte võrku. Lisakäivituslipud ja üleliigne draiverihaldur muudavad, milline protsess porti omab, mistõttu nende eemaldamine näib mõnikord VPN-i parandavat.
Parandage kiht, mis ebaõnnestus
Parandage kiht, mis ebaõnnestus, mitte tunnel. Kättesaamatu loopbacki kuulaja vajab oma kuulaja või pordi parandamist. Usaldamata sertifikaat vajab ettevõtte juure paigaldamist sinna, kuhu see konkreetne käituskeskkond vaatab, erandit kitsana hoides. Kohalikku liiklust kõrvale viskav filter vajab konkreetset lubamisreeglit, mitte väljalülitatud filtrit, sest väljalülitamine avab uuesti ka kõik muu, mida see kaitses.
VPN-i uuesti ühendamine ei testi ühtki neist kihtidest. See ainult käivitab uuesti muudatuse, mis need lõhkus, mistõttu samad kolm tõrget tulevad tagasi pärast igat taasühendust ja kaovad pärast igat taaskäivitust, mis jätab kliendi mitteaktiivseks.