mitmproxy, DevTools, Gradle: þrjú lög bak við VPN
Loopback fer aldrei inn í göngin. Flokkaðu einkennið sem hlustara, traustgeymslu eða pakkasíu og lagaðu það lag sem raunverulega klikkaði.
VPN tengist, og þrjú ótengd verkfæri klikka á þrjá mismunandi vegu sama síðdegis. mitmproxy hættir að sjá beiðnir, Chrome neitar villuleitaranum og Gradle kastar BindException við að binda staðbundið socket. Sameiginlegur grunur er að göngin loka localhost. Það geta ekki: 127.0.0.1 er meðhöndlað inni í kjarnanum og nær aldrei að millistykki, hvað þá gátt.
Þrjú lög, þrjú mismunandi bilun
Það sem breyttist með biðlarannum er ekki leiðin að loopback. Það eru staðbundin proxy, traustgeymsla vélarinnar og pakkasía, og hvert þeirra brýtur annan hluta vinnuferlis forritara. Að raða einkenninu í rétta röðina er stærsti hluti greiningarinnar:
| 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æstum hver skýrsla af þessu tagi byrjar á síðustu röð og vinnur upp, sem er öfugt. Göngin eru eina lagið sem sannanlega geta ekki séð loopback-umferð, svo þau eiga sér minnstu grunsemdirnar. Byrjaðu á því sem ferlið bindi, spurðu svo hvaða skírteinum það treystir og skoðaðu síðan stefnuna á vélinni.
Byrjaðu á hlustaranum, ekki göngunum
Þegar proxy á 127.0.0.1:8080 hættir að taka við umferð, eitt af þrennu hefur gerst: það byrjaði aldrei, það bindi annan port eða síurnar féllu frá loopback-tengingunni. Upptalning hlustandi socketa svarar þessu með einni skipun og sýnir líka hvaða ferli á portið þegar tvö verkfæri eru ósammála um hver var fyrstur.
Staðbundið vistfang í leiðarleit staðfestir sama frá hinni áttinni. ip route get að loopback-áfangastað tilkynnir loopback-tækið, aldrei göngin, sem er gagnleg setning að hafa tilbúna þegar einhver stingur upp á leiðarbreytingu sem lausn.
Proxy-lagið: umhverfi er ekki stillingar
Margir fyrirtækjabiðlarar keyra HTTP-proxy og gera ráð fyrir að forrit noti hann. Að stilla HTTPS_PROXY í skel lagar skipanalínutæki sem virða hann og gerir ekkert fyrir tæki sem les sína eigin stillingaskrá. Gradle, Selenium og gRPC ráðfæra sig hvert við sína stillingar, og proxy sem flutt er út í einni stöð er ósýnilegt fyrir púka sem IDE ræsir.
Gámatæki eru venjulegur staður þar sem þetta verður sýnilegt. Loopback gáms er hans eigin, svo 127.0.0.1 inni í gámnum þýðir aldrei proxy hýsilsins; þörf er á vistfangi hýsilsins eða stillingu hýsilnetkerfis. Lausn sem virkar í skelinni og bregst í byggingunni er yfirleitt þessi röð, ekki göngin.
Traustlagið: tækið les aðra geymslu
Afhlop er önnur breytingin og framleiðir villandi villurnar. Biðlarinn kynnir sitt eigið skírteini fyrir skoðuðum tengingum, svo vafri sem treystir fyrirtækisrótinni tekst en tæki með innbyggða CA-geymslu bregst. requests Python í gegnum certifi er hið klassíska tilfelli: geymsla stýrikerfisins getur verið rétt og beiðnin samt brugðist, því sá keyrsluumhverfi les hana aldrei. Villutextinn nefnir afhlop sjaldan, sem er ástæðan fyrir því að þessi röð er greind ranglega sem brotinn endapunktur.
Berðu saman það sem endapunkturinn kynnir í raun og það sem tækið staðfesti. openssl s_client sýnir keðjuna sem þjónninn sendi; eigin staðfestingarúttak tækisins sýnir hvað það ákvað. Þegar þau stemma ekki, REQUESTS_CA_BUNDLE eða SSL_CERT_FILE er lyftistöngin fyrir það keyrsluumhverfi, og fyrirtækisrótin á heima í geymslunni sem það umhverfi les, ekki á alþjóðlegum stað sem aðeins sum tæki virða.
Útgáfubreyting sem lagar SSL-villu er sönnun um traust- og dulritunarstefnu, ekki um VPN. Lækkun Python-útgáfu sem lét SOAP-biðlara virka breytti innbyggðu CA-geymslunni og sjálfgefnum TLS-stillingum; netleiðin hreyfðist ekki.
Síulagið: það getur líka fellt loopback
Þriðja breytingin er pakkasía, og sumar vörur setja upp reglur sem fella umferð sem fer ekki inn í göngin. Staðbundnir hlustarar geta verið með. Það gerir virkt socket að synjaðri eða útrunninni tengingu, og villan sem af því hlýst lítur út eins og galli í forritinu frekar en stefna á vélinni.
Eignarhald á porti er hinn helmingurinn af þessu lagi. BindException þýðir að ekki var hægt að opna socketið, sem er önnur bilun en synjuð tenging. Athugaðu hvort annað ferli heldur þegar portinu áður en þú kennir síunni um, leitaðu svo að reglu sem fellir staðbundna umferð og bættu við þrengstu heimild sem varan styður. Tvö verkfæri sem keppa um sama villuleitarport framleiða nákvæmlega sömu skilaboð og stefnublokkun, og aðeins annað þeirra lagast með eldveggjarbreytingu.
Villuleitarport Chrome bregst í sömu fjölskyldu. Vafrinn ræsist, rekillinn nær ekki DevTools-endapunktinum og skilaboðin nefna DevTools frekar en netið. Auka ræsifánar og óþarfi rekilsstjóri breyta því hvaða ferli á portið, sem er ástæðan fyrir því að fjarlægja þau virðist stundum laga VPN.
Lagaðu lagið sem klikkaði
Lagaðu lagið sem klikkaði, ekki göngin. Óaðgengilegur loopback-hlustari þarf að laga hlustarann eða portið. Ótraust skírteini þarf að setja fyrirtækisrótina þar sem það keyrsluumhverfi horfir, með undantekninguna þrönga. Sía sem fellir staðbundna umferð þarf sérstaka heimildarreglu í stað óvirkrar síu, því óvirkjun opnar líka allt annað sem hún verndaði.
Endurtenging VPN prófar ekkert þessara laga. Hún keyrir bara aftur breytinguna sem braut þau, sem er ástæðan fyrir því að sömu þrjár bilanir koma aftur eftir hverja endurtengingu og hverfa eftir hverja endurræsingu sem skilur biðlarann óvirkan.