mitmproxy, DevTools, Gradle: tatlong antas sa likod ng VPN
Hindi kailanman pumapasok ang loopback sa tunnel. Uriin ang sintomas bilang tagapakinig, imbakan ng tiwala o filter ng packet, at ayusin ang antas na talagang nabigo.
Kumokonekta ang VPN, at tatlong walang kaugnayang tool ang nabibigo sa tatlong magkaibang paraan sa parehong hapon. Huminto ang mitmproxy sa pagtingin ng mga kahilingan, tinatanggihan ng Chrome ang debugger, at nagtatapon ang Gradle ng BindException habang nagbubuklod ng lokal na socket. Ang karaniwang hinala ay hinaharangan ng tunnel ang localhost. Hindi nito kaya: 127.0.0.1 hinahawakan ito sa loob ng kernel at hindi kailanman umaabot sa adapter, lalo pa sa gateway.
Tatlong antas, tatlong magkaibang pagkasira
Ang nagbago kasama ng client ay hindi ang ruta patungong loopback. Ito ay lokal na proxy, imbakan ng tiwala ng makina at filter ng packet, at bawat isa ay sinira ang ibang bahagi ng daloy ng trabaho ng developer. Ang paglalagay ng sintomas sa tamang hilera ang malaking bahagi ng diagnosis:
| 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? |
Halos lahat ng ulat na ganito ay nagsisimula sa huling hilera at umaakyat, na baliktad. Ang tunnel ang tanging antas na napatunayang hindi makakakita ng trapikong loopback, kaya ito ang pinakakaunti ang dapat paghinalaan. Magsimula sa kung ano ang ibinuklod ng proseso, itanong kung aling mga sertipiko ang pinagkakatiwalaan nito, at pagkatapos lamang tingnan ang patakaran sa makina.
Magsimula sa tagapakinig, hindi sa tunnel
Kapag ang isang proxy sa 127.0.0.1:8080 ay huminto sa pagtanggap ng trapiko, isa sa tatlong bagay ang nangyari: hindi ito kailanman nagsimula, nagbuklod ito ng ibang port, o itinapon ng filter ang koneksyong loopback. Ang paglilista ng mga socket na nakikinig ay sumasagot doon sa isang utos, at ipinapakita rin nito kung aling proseso ang may-ari ng port kapag hindi magkasundo ang dalawang tool kung sino ang nauna.
Ang lokal na address sa paghahanap ng ruta ay nagpapatunay ng parehong bagay mula sa kabilang panig. ip route get patungo sa destinasyong loopback ay nag-uulat ng loopback device, hindi kailanman ng tunnel, na isang kapaki-pakinabang na pangungusap na ihanda kapag may nagmungkahi ng pagbabago sa routing bilang solusyon.
Ang antas ng proxy: ang kapaligiran ay hindi configuration
Maraming corporate client ang nagpapatakbo ng HTTP proxy at umaasa na gagamitin ito ng mga application. Ang pagtatakda ng HTTPS_PROXY sa isang shell ay nag-aayos ng mga tool sa command line na gumagalang dito, at walang ginagawa para sa isang tool na nagbabasa ng sarili nitong settings file. Sinasangguni ng Gradle, Selenium at gRPC ang kani-kanilang configuration, at ang proxy na na-export sa isang terminal ay hindi nakikita ng daemon na inilunsad ng IDE.
Ang mga container tool ang karaniwang lugar kung saan ito nagiging nakikita. Ang loopback ng container ay sarili nito, kaya 127.0.0.1 sa loob ng container ay hindi kailanman nangangahulugan ng proxy ng host; kailangan ang address ng host o setting ng host network. Ang pag-aayos na gumagana sa shell at nabibigo sa build ay karaniwang ang hilerang ito, hindi ang tunnel.
Ang antas ng tiwala: nagbabasa ang tool ng ibang imbakan
Ang interception ang ikalawang pagbabago, at gumagawa ito ng pinakamanlilinlang na mga error. Ipinapakita ng client ang sarili nitong sertipiko para sa mga sinuring koneksyon, kaya ang browser na nagtitiwala sa corporate root ay nagtatagumpay habang ang tool na may bundled na CA store ay nabibigo. Ang requests ng Python sa pamamagitan ng certifi ang klasikong kaso: maaaring tama ang imbakan ng operating system at nabibigo pa rin ang kahilingan, dahil hindi ito binabasa ng runtime na iyon. Bihirang banggitin ng teksto ng error ang interception, kaya mali ang diagnosis ng hilerang ito bilang sirang endpoint.
Ihambing ang aktwal na ipinapakita ng endpoint sa kung ano ang pinatunayan ng tool. openssl s_client ipinapakita ang chain na ipinadala ng server; ang sariling output ng validation ng tool ay nagpapakita ng kung ano ang napagpasya nito. Kapag hindi sila magkatugma, REQUESTS_CA_BUNDLE o SSL_CERT_FILE ang pingga para sa runtime na iyon, at ang corporate root ay kabilang sa imbakan na binabasa ng runtime na iyon, hindi sa isang pandaigdigang lugar na iginagalang lamang ng ilang tool.
Ang pagbabago ng bersyon na nag-aayos ng error sa SSL ay ebidensya tungkol sa patakaran ng tiwala at cipher, hindi tungkol sa VPN. Ang pagbaba ng bersyon ng Python na nagpapagana sa isang SOAP client ay nagbago ng bundled na CA store at ng default na setting ng TLS; hindi gumalaw ang landas ng network.
Ang antas ng filter: maaari rin nitong itapon ang loopback
Ang ikatlong pagbabago ay isang filter ng packet, at ang ilang produkto ay nag-iinstall ng mga panuntunang nagtatapon ng trapikong hindi pumapasok sa tunnel. Maaaring kasama ang mga lokal na tagapakinig. Ginagawa nitong tinanggihan o nag-time out na koneksyon ang isang gumaganang socket, at ang resultang error ay mukhang bug sa application kaysa patakaran sa makina.
Ang pagmamay-ari ng port ang kabilang kalahati ng antas na ito. BindException nangangahulugan na hindi mabuksan ang socket, na ibang pagkabigo kaysa tinanggihang koneksyon. Tingnan kung may ibang prosesong may hawak na ng port bago sisihin ang filter, pagkatapos ay maghanap ng panuntunang nagtatapon ng lokal na trapiko at idagdag ang pinakamakipot na pahintulot na sinusuportahan ng produkto. Dalawang tool na nagpapaligsahan sa parehong debug port ay gumagawa ng eksaktong parehong mensahe ng pagharang ng patakaran, at isa lamang sa kanila ang naaayos ng pagbabago sa firewall.
Ang debug port ng Chrome ay nabibigo sa parehong pamilya. Nagsisimula ang browser, hindi maabot ng driver ang endpoint ng DevTools, at pinapangalanan ng mensahe ang DevTools kaysa network. Binabago ng dagdag na launch flag at kalabisan na driver manager kung aling proseso ang may-ari ng port, kaya minsan ay mukhang inaayos ng pag-alis sa mga ito ang VPN.
Ayusin ang antas na nabigo
Ayusin ang antas na nabigo, hindi ang tunnel. Ang hindi maabot na tagapakinig ng loopback ay kailangang ayusin ang tagapakinig o port nito. Ang hindi pinagkakatiwalaang sertipiko ay nangangailangan ng corporate root na naka-install kung saan tumitingin ang partikular na runtime na iyon, na panatilihing makipot ang eksepsyon. Ang filter na nagtatapon ng lokal na trapiko ay nangangailangan ng partikular na tuntunin ng pahintulot kaysa sa isang naka-disable na filter, dahil binubuksan muli ng pag-disable ang lahat ng iba pang pinoprotektahan nito.
Ang muling pagkonekta sa VPN ay hindi sumusubok sa alinman sa mga antas na ito. Inuulit lamang nito ang pagbabagong sumira sa kanila, kaya bumabalik ang parehong tatlong pagkabigo pagkatapos ng bawat muling pagkonekta at nawawala pagkatapos ng bawat reboot na nag-iiwan sa client na hindi aktibo.