mitmproxy, DevTools, Gradle: VPNaren atzean hiru geruza

VPNa konektatzen da, eta erlaziorik gabeko hiru tresnak hiru modu desberdinetan huts egiten dute arratsalde berean. mitmproxy-k eskaerak ikusteari uzten dio, Chrome-k depuratzailea ukatzen du, eta Gradle-k BindException socket lokal bat lotzean jaurtitzen du. Susmo partekatua da tunelak localhost blokeatzen duela. Ezin du: 127.0.0.1 kernelaren barruan kudeatzen da eta ez da sekula adapter batera iristen, are gutxiago ate batera.

Hiru geruza, hiru hauste desberdin

Bezeroarekin aldatu dena ez da loopbackerako bidea. Proxy lokal bat, makinaren konfiantza-biltegi bat eta pakete-iragazki bat dira, eta bakoitzak garatzaile baten lan-fluxuaren zati desberdin bat hausten du. Sintoma errenkada egokian sailkatzea da diagnostikoaren zati handiena:

Mota honetako ia txosten guztiak azken errenkadatik hasi eta gora egiten dute, eta hori alderantzizkoa da. Tunela da loopback trafikoa ikusi ezin duela frogatzen den geruza bakarra, beraz susmo gutxien merezi du. Hasi prozesuak lotu duenarekin, gero galdetu zein ziurtagiritan fidatzen den, eta soilik gero begiratu makinaren politika.

Hasi entzulearekin, ez tunelarekin

Proxy bat 127.0.0.1:8080 trafikoa jasotzeari uzten dionean, hiru gauzetako bat gertatu da: ez da inoiz abiarazi, beste portu bat lotu du, edo iragazkiak loopback konexioa baztertu du. Entzuten ari diren socketak zerrendatzeak komando bakarrean erantzuten du, eta portuaren jabe den prozesua ere erakusten du bi tresnak lehena nor izan zen ados jartzen ez direnean.

Bide-bilaketa bateko helbide lokal batek gauza bera baieztatzen du beste norabidetik. ip route get loopback helmugarantz loopback gailua jakinarazten du, inoiz ez tunela, eta esaldi erabilgarria da norbaitek bideratze-aldaketa konponbide gisa proposatzen duenean.

Proxy geruza: ingurunea ez da konfigurazioa

Enpresa-bezero askok HTTP proxy bat exekutatzen dute eta aplikazioek hura erabiliko dutela espero dute. Hau ezartzeak HTTPS_PROXY shell batean errespetatzen duten komando-lerroko tresnak konpontzen ditu, eta bere konfigurazio-fitxategia irakurtzen duen tresnarentzat ezer ez du egiten. Gradle-k, Selenium-ek eta gRPC-k bakoitzak bere konfigurazioa kontsultatzen du, eta terminal batean esportatutako proxy bat ikusezina da IDEak abiarazitako daemon batentzat.

Kontagailuen tresnak dira hau ikusgai egiten den ohiko lekua. Kontagailu baten loopback berea da, beraz 127.0.0.1 kontagailuaren barruan ez du inoiz ostalariaren proxya esan nahi; ostalariaren helbidea edo ostalari-sarearen ezarpena behar da. Shell-ean funtzionatzen duen eta build-ean huts egiten duen konponbidea errenkada hau izaten da normalean, ez tunela.

Konfiantza geruza: tresnak beste biltegi bat irakurtzen du

Atzematea bigarren aldaketa da, eta errorerik engainagarrienak sortzen ditu. Bezeroak bere ziurtagiria aurkezten du ikuskatutako konexioetarako, beraz enpresa-erroan fidatzen den nabigatzaileak arrakasta du, barneko CA biltegia duen tresnak huts egiten duen bitartean. Python-en requests certifi bidez kasu klasikoa da: sistema eragilearen biltegia zuzena izan daiteke eta eskaerak oraindik huts egiten du, exekuzio-ingurune horrek sekula irakurtzen ez duelako. Errorearen testuak gutxitan aipatzen du atzematea, eta horregatik diagnostikatzen da errenkada hau oker amaiera-puntu hautsi gisa.

Konparatu amaiera-puntuak benetan aurkezten duena tresnak baliozkotu duenarekin. openssl s_client zerbitzariak bidalitako katea erakusten du; tresnaren beraren baliozkotze-irteerak zer erabaki zuen erakusten du. Bat ez datozenean, REQUESTS_CA_BUNDLE edo SSL_CERT_FILE da exekuzio-ingurune horren palanka, eta enpresa-erroa ingurune horrek irakurtzen duen biltegian dagokio, tresna batzuek soilik errespetatzen duten kokapen global batean beharrean.

SSL errore bat konpontzen duen bertsio-aldaketa konfiantza eta zifratze politikaren froga da, ez VPNarena. SOAP bezero bat funtzionarazten duen Python bertsio-jaitsierak barneko CA biltegia eta TLS ezarpen lehenetsiak aldatu zituen; sare-bidea ez zen mugitu.

Iragazki geruza: loopback ere bazter dezake

Hirugarren aldaketa pakete-iragazki bat da, eta produktu batzuek tunelera sartzen ez den trafikoa baztertzen duten arauak instalatzen dituzte. Entzule lokalak sartuta egon daitezke. Horrek funtzionatzen zuen socket bat ukatutako edo denboraz kanpoko konexio bihurtzen du, eta ondoriozko errorea aplikazioko akats dirudi, ez makinako politika.

Portuaren jabetza geruza honen beste erdia da. BindException socket-a ezin izan zela ireki esan nahi du, eta hori ukatutako konexio bat ez den beste hutsegite bat da. Egiaztatu beste prozesu batek portua jada baduen iragazkiari errua bota aurretik, gero bilatu trafiko lokala baztertzen duen arau bat eta gehitu produktuak onartzen duen baimen estuena. Portu beragatik lehiatzen diren bi tresnek politikaren blokeoaren mezu bera ematen dute, eta horietako bakarra konpontzen da suebaki-aldaketarekin.

Chrome-ren depurazio-portuak huts egiten du familia berean. Nabigatzailea abiarazten da, kontrolatzaileak ez du DevTools amaiera-puntura iristen, eta mezuak DevTools aipatzen du, ez sarea. Abiarazte-bandera gehigarriek eta kontrolatzaile-kudeatzaile soberakinek portuaren jabe den prozesua aldatzen dute, eta horregatik haiek kentzea batzuetan VPNa konpontzen ari dela ematen du.

Konpondu huts egin duen geruza

Konpondu huts egin duen geruza, ez tunela. Eskuraezin den loopback entzule batek bere entzulea edo portua zuzentzea behar du. Konfiantzarik gabeko ziurtagiri batek enpresa-erroa exekuzio-ingurune zehatz horrek begiratzen duen tokian instalatuta behar du, salbuespena estu edukita. Trafiko lokala baztertzen duen iragazki batek baimen-arau zehatz bat behar du, iragazki desgaituta beharrean, desgaitzeak babesten zuen beste guztia ere berriro irekitzen duelako.

VPNa berriro konektatzeak ez du geruza hauetako bat ere probatzen. Hauek hautsi zituen aldaketa soilik exekutatzen du berriro, eta horregatik hiru hutsegite berak itzultzen dira berriz konektatzen den bakoitzean eta desagertzen dira bezeroa inaktibo uzten duen berrabiarazte bakoitzaren ondoren.