mitmproxy, DevTools, Gradle: trīs slāņi aiz VPN
Loopback nekad nenokļūst tunelī. Klasificējiet simptomu kā klausītāju, uzticības krātuvi vai paketes filtru un salabojiet slāni, kas patiešām sabojājās.
VPN pieslēdzas, un trīs nesaistīti rīki cieš neveiksmi trīs dažādos veidos tajā pašā pēcpusdienā. mitmproxy pārstāj redzēt pieprasījumus, Chrome atsakās no atkļūdotāja, un Gradle met BindException saistot lokālu ligzdu. Kopīgās aizdomas ir, ka tunelis bloķē localhost. Tas nevar: 127.0.0.1 tiek apstrādāts kodola iekšienē un nekad nesasniedz adapteri, nemaz nerunājot par vārteju.
Trīs slāņi, trīs dažādi bojājumi
Tas, kas mainījās ar klientu, nav ceļš uz loopback. Tie ir lokāls starpnieks, mašīnas uzticības krātuve un paketes filtrs, un katrs no tiem salauž citu izstrādātāja darbplūsmas daļu. Simptoma ievietošana pareizajā rindā ir lielākā diagnostikas daļa:
| 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? |
Gandrīz katrs šāda veida ziņojums sākas no pēdējās rindas un iet uz augšu, kas ir otrādi. Tunelis ir vienīgais slānis, kas pierādāmi nevar redzēt loopback trafiku, tāpēc tam pienākas vismazākās aizdomas. Sāciet ar to, ko process piesaistīja, pēc tam jautājiet, kuriem sertifikātiem tas uzticas, un tikai tad skatieties uz mašīnas politiku.
Sāciet ar klausītāju, nevis tuneli
Kad starpnieks 127.0.0.1:8080 pārstāj saņemt trafiku, ir noticis viens no trim: tas nekad nav startējis, tas ir piesaistījis citu portu, vai filtrs ir nometis loopback savienojumu. Klausītāju ligzdu uzskaitīšana uz to atbild ar vienu komandu, un tā arī parāda, kurš process pieder portu, kad divi rīki nevar vienoties, kurš bija pirmais.
Lokāla adrese maršruta meklēšanā apstiprina to pašu no otras puses. ip route get pret loopback galamērķi ziņo par loopback ierīci, nekad par tuneli, kas ir noderīgs teikums, ko turēt gatavu, kad kāds ierosina maršruta maiņu kā risinājumu.
Starpnieka slānis: vide nav konfigurācija
Daudzi uzņēmumu klienti darbina HTTP starpnieku un sagaida, ka lietojumprogrammas to izmantos. Iestatīšana HTTPS_PROXY čaulgā salabo komandrindas rīkus, kas to ievēro, un neko nedara rīkam, kas lasa savu iestatījumu failu. Gradle, Selenium un gRPC katrs konsultējas ar savu konfigurāciju, un vienā terminālī eksportēts starpnieks ir neredzams IDE palaistam dēmonam.
Konteineru rīki ir ierastā vieta, kur tas kļūst redzams. Konteinera loopback ir tā paša, tāpēc 127.0.0.1 konteinera iekšienē nekad nenozīmē resursdatora starpnieku; ir nepieciešama resursdatora adrese vai resursdatora tīkla iestatījums. Labojums, kas strādā čaulgā un neizdodas būvē, parasti ir šī rinda, nevis tunelis.
Uzticības slānis: rīks lasa citu krātuvi
Pārtveršana ir otrā izmaiņa, un tā rada maldinošākās kļūdas. Klients uzrāda savu sertifikātu pārbaudītajiem savienojumiem, tāpēc pārlūks, kas uzticas uzņēmuma saknei, gūst panākumus, bet rīks ar iekļautu CA krātuvi cieš neveiksmi. Python requests ar certifi ir klasiskais gadījums: operētājsistēmas krātuve var būt pareiza, un pieprasījums tomēr neizdodas, jo tā izpildvide to nekad nelasa. Kļūdas teksts reti piemin pārtveršanu, tāpēc šī rinda tiek nepareizi diagnosticēta kā salauzts galapunkts.
Salīdziniet, ko galapunkts faktiski uzrāda, ar to, ko rīks validēja. openssl s_client parāda servera nosūtīto ķēdi; paša rīka validācijas izvade parāda, ko tas nolēma. Kad tie nesakrīt, REQUESTS_CA_BUNDLE vai SSL_CERT_FILE ir tās izpildvides svira, un uzņēmuma sakne pieder krātuvei, ko šī izpildvide lasa, nevis globālai vietai, ko ievēro tikai daži rīki.
Versijas maiņa, kas salabo SSL kļūdu, ir pierādījums par uzticības un šifrēšanas politiku, nevis par VPN. Python versijas pazemināšana, kas lika SOAP klientam strādāt, mainīja iekļauto CA krātuvi un noklusējuma TLS iestatījumus; tīkla ceļš nepārvietojās.
Filtra slānis: tas var nomest arī loopback
Trešā izmaiņa ir paketes filtrs, un daži produkti instalē noteikumus, kas nomet trafiku, kas neieplūst tunelī. Var būt iekļauti arī lokālie klausītāji. Tas pārvērš strādājošu ligzdu noraidītā vai noilgušā savienojumā, un radušās kļūdas izskatās pēc lietojumprogrammas kļūdas, nevis mašīnas politikas.
Porta piederība ir šī slāņa otra puse. BindException nozīmē, ka ligzdu nevarēja atvērt, kas ir cita neveiksme nekā noraidīts savienojums. Pārbaudiet, vai ports jau nav citam procesam, pirms vainot filtru, pēc tam meklējiet noteikumu, kas nomet lokālo trafiku, un pievienojiet šaurāko atļauju, ko produkts atbalsta. Divi rīki, kas sacenšas par vienu un to pašu atkļūdošanas portu, rada tieši tādu pašu ziņojumu kā politikas bloķēšana, un tikai vienu no tiem izlabo ugunsmūra maiņa.
Chrome atkļūdošanas ports cieš neveiksmi tajā pašā ģimenē. Pārlūks startē, draiveris nevar sasniegt DevTools galapunktu, un ziņojums nosauc DevTools, nevis tīklu. Papildu palaišanas karodziņi un lieks draiveru pārvaldnieks maina, kurš process pieder portu, tāpēc to noņemšana dažkārt izskatās kā VPN salabošana.
Salabojiet slāni, kas sabojājās
Salabojiet slāni, kas sabojājās, nevis tuneli. Nesasniedzamam loopback klausītājam ir jālabo tā klausītājs vai ports. Neuzticamam sertifikātam ir vajadzīga uzņēmuma sakne, kas instalēta tur, kur skatās tieši šī izpildvide, izņēmumu turot šauru. Filtram, kas nomet lokālo trafiku, ir vajadzīgs konkrēts atļaujas noteikums, nevis izslēgts filtrs, jo izslēgšana atkal atver arī visu pārējo, ko tas aizsargāja.
VPN atkārtota pievienošana nepārbauda nevienu no šiem slāņiem. Tā tikai atkārto izmaiņu, kas tos salauza, tāpēc tie paši trīs bojājumi atgriežas pēc katras atkārtotas pievienošanas un pazūd pēc katras pārstartēšanas, kas atstāj klientu neaktīvu.