mitmproxy, DevTools, Gradle: tre shtresa pas VPN-së

VPN-ja lidhet, dhe tre mjete të palidhura dështojnë në tre mënyra të ndryshme në të njëjtën pasdite. mitmproxy ndalon së parë kërkesat, Chrome refuzon korrigjuesin, dhe Gradle hedh BindException ndërsa lidh një socket lokal. Dyshimi i përbashkët është se tuneli bllokon localhost. Nuk mundet: 127.0.0.1 trajtohet brenda kernelit dhe nuk arrin kurrë një përshtatës, e jo më një portë.

Tre shtresa, tre prishje të ndryshme

Ajo që ndryshoi me klientin nuk është rruga drejt loopback. Janë një proxy lokal, një depo besimi e makinës dhe një filtër paketash, dhe secila prish një pjesë tjetër të rrjedhës së punës së një zhvilluesi. Vendosja e simptomës në rreshtin e duhur është pjesa më e madhe e diagnozës:

Pothuajse çdo raport i këtij lloji fillon nga rreshti i fundit dhe shkon lart, gjë që është e kundërt. Tuneli është shtresa e vetme që provueshëm nuk mund të shohë trafikun loopback, prandaj meriton dyshimin më të vogël. Filloni me atë që lidhi procesi, pastaj pyesni cilat certifikata i beson, dhe vetëm pastaj shikoni politikën në makinë.

Filloni me dëgjuesin, jo me tunelin

Kur një proxy në 127.0.0.1:8080 ndalon marrjen e trafikut, ka ndodhur një nga tre gjërat: nuk u nis kurrë, lidhi një port tjetër, ose filtri e hodhi lidhjen loopback. Listimi i socket-eve që dëgjojnë përgjigjet me një komandë, dhe tregon gjithashtu cili proces zotëron portin kur dy mjete nuk bien dakord se kush ishte i pari.

Një adresë lokale në një kërkim rruge konfirmon të njëjtën gjë nga ana tjetër. ip route get drejt një destinacioni loopback raporton pajisjen loopback, kurrë tunelin, e cila është një fjali e dobishme për ta mbajtur gati kur dikush propozon një ndryshim rrugëtimi si zgjidhje.

Shtresa e proxy-t: mjedisi nuk është konfigurim

Shumë klientë korporativë ekzekutojnë një proxy HTTP dhe presin që aplikacionet ta përdorin. Vendosja e HTTPS_PROXY në një shell rregullon mjetet e rreshtit të komandës që e respektojnë, dhe nuk bën asgjë për një mjet që lexon skedarin e vet të cilësimeve. Gradle, Selenium dhe gRPC konsultojnë secili konfigurimin e vet, dhe një proxy i eksportuar në një terminal është i padukshëm për një daemon të nisur nga IDE.

Mjetet e kontejnerëve janë vendi i zakonshëm ku kjo bëhet e dukshme. Loopback i një kontejneri është i veti, prandaj 127.0.0.1 brenda kontejnerit nuk nënkupton kurrë proxy-n e hostit; nevojitet adresa e hostit ose një cilësim i rrjetit të hostit. Një rregullim që funksionon në shell dhe dështon në ndërtim është zakonisht ky rresht, jo tuneli.

Shtresa e besimit: mjeti lexon një depo tjetër

Ndërprerja është ndryshimi i dytë, dhe prodhon gabimet më mashtruese. Klienti paraqet certifikatën e vet për lidhjet e inspektuara, ndaj një shfletues që beson rrënjën korporative ka sukses, ndërsa një mjet me një depo CA të integruar dështon. requests e Python përmes certifi është rasti klasik: depoja e sistemit operativ mund të jetë e saktë dhe kërkesa prapë dështon, sepse ai mjedis ekzekutimi nuk e lexon kurrë. Teksti i gabimit rrallë përmend ndërprerjen, dhe për këtë arsye ky rresht diagnostohet gabimisht si një pikë fundore e prishur.

Krahasoni çfarë paraqet në të vërtetë pika fundore me atë që mjeti vërtetoi. openssl s_client tregon zinxhirin që dërgoi serveri; dalja e vërtetimit të vetë mjetit tregon çfarë vendosi. Kur nuk përputhen, REQUESTS_CA_BUNDLE ose SSL_CERT_FILE është levë për atë mjedis ekzekutimi, dhe rrënja korporative i përket depos që lexon ai mjedis, jo një vendi global që respektojnë vetëm disa mjete.

Një ndryshim versioni që rregullon një gabim SSL është provë për politikën e besimit dhe të shifrimit, jo për VPN-në. Një zbritje e versionit të Python që bën të punojë një klient SOAP ndryshoi depon CA të integruar dhe cilësimet e paracaktuara TLS; rruga e rrjetit nuk u zhvendos.

Shtresa e filtrit: edhe ajo mund të hedhë loopback

Ndryshimi i tretë është një filtër paketash, dhe disa produkte instalojnë rregulla që hedhin trafikun që nuk hyn në tunel. Dëgjuesit lokalë mund të përfshihen. Kjo e kthen një socket funksional në një lidhje të refuzuar ose të skaduar, dhe gabimi që rezulton duket si një defekt në aplikacion, jo si politikë në makinë.

Pronësia e portit është gjysma tjetër e kësaj shtrese. BindException do të thotë që socket-i nuk mund të hapej, gjë që është një dështim tjetër nga një lidhje e refuzuar. Kontrolloni nëse një proces tjetër e mban tashmë portin përpara se të fajësoni filtrin, pastaj kërkoni një rregull që hedh trafikun lokal dhe shtoni lejen më të ngushtë që mbështet produkti. Dy mjete që konkurrojnë për të njëjtin port korrigjimi prodhojnë saktësisht të njëjtin mesazh si një bllokim politike, dhe vetëm njëri prej tyre rregullohet nga një ndryshim i firewall-it.

Porti i korrigjimit i Chrome dështon në të njëjtën familje. Shfletuesi niset, drejtuesi nuk arrin pikën fundore të DevTools, dhe mesazhi emërton DevTools në vend të rrjetit. Flamuj shtesë nisjeje dhe një menaxher drejtuesish i tepërt ndryshojnë cili proces zotëron portin, prandaj heqja e tyre ndonjëherë duket sikur rregullon VPN-në.

Riparoni shtresën që dështoi

Riparoni shtresën që dështoi, jo tunelin. Një dëgjues loopback i paarritshëm ka nevojë që dëgjuesi ose porti i tij të korrigjohet. Një certifikatë e pabesuar ka nevojë për rrënjën korporative të instaluar atje ku shikon ai mjedis ekzekutimi specifik, me përjashtimin të mbajtur ngushtë. Një filtër që hedh trafikun lokal ka nevojë për një rregull lejeje të veçantë në vend të një filtri të çaktivizuar, sepse çaktivizimi rihap edhe gjithçka tjetër që mbronte.

Rilidhja e VPN-së nuk teston asnjë nga këto shtresa. Ajo vetëm riekzekuton ndryshimin që i prishi, prandaj të njëjtat tre dështime kthehen pas çdo rilidhjeje dhe zhduken pas çdo rindezjeje që e lë klientin joaktiv.