Hodeløs nettleserproxyautentisering er ikke en VPN-rute

En VPN kan føre nettleserens trafikk til en proxy-server og fortsatt la nettleseren være ute av stand til å bruke den proxyen, fordi en rute og en legitimasjon er forskjellige ting. Hodeløs automatisering gjør gapet vanskeligere å se, siden det ikke er noe vindu og ingen spørsmål om å legge merke til. Feilen vises vanligvis som en henging eller en generisk navigasjonsfeil, og det første instinktet er å skylde på tunnelen. Sjekklisten nedenfor skiller de fire tingene som må være sanne før en hodeløs forespørsel via en autentisert proxy kan lykkes.

To samtaler, to legitimasjon

To samtaler skjer, og de tilhører forskjellige parter. Nettleseren kobler seg først til proxy-lytteren, som kan utfordre den for legitimasjon; proxyen oppretter eller tillater deretter den videre forbindelsen til destinasjonen. En VPN kan bære den første etappen uten å være endepunktet som utfordrer nettleseren, og det har ingenting å si om det andre.

HTTP 407 er signalet som klienten må autentisere for proxy-forespørselen, båret i Proxy-Authenticate med svaret forventet i Proxy-Authorization. Det er ikke destinasjonsnettstedets pålogging, og å blande de to er den vanligste kilden til forvirring her.

Så de fire kontrollene er: hvilken proxy nettleseren faktisk valgte, hvem som svarer på 407, hvilket nettverk nettleserprosessen er på, og hvordan legitimasjonen leveres uten et menneske. Hver enkelt kan feile uavhengig, og hver feil ser lik ut utenfra. Arbeid dem i rekkefølge, fordi en senere sjekk ikke kan kompensere for en tidligere. En proxy som aldri ble valgt kan ikke autentiseres, og en legitimasjon som bare finnes på den bærbare datamaskinen din kan ikke nå en beholder.

Sjekk 1: hvilken proxy som faktisk er valgt

Start med valg, for en nettleser som ignorerer proxy-innstillingen din når aldri utfordringen i det hele tatt. I Chrome er flagget --proxy-server=proxy.example:3128 , med --proxy-bypass-list for ekskluderinger, og Selenium viser det samme gjennom nettleseralternativene. En PAC-fil er en annen mekanisme med sine egne feilmoduser.

Bekreft deretter fra innsiden av nettleserens miljø i stedet for fra skallet ditt. En uavhengig sonde med samme proxy er curl -x http://proxy.example:3128 -v https://example.com , og dens detaljerte utdata viser om CONNECT lyktes, hva Proxy-Authenticate kom tilbake og om en 407 ble returnert. Hvis curl får en 407 og nettleseren henger, er legitimasjonsbanen problemet snarere enn nettverket. Hvis curl lykkes og nettleseren ikke gjør det, bruker ikke nettleseren proxyen du tror den er.

Sjekk 2: hvem som svarer på 407

En 407 har en eier, og navngivningen avgjør hvor rettelsen går. Hvis utfordringen kommer fra bedriftens proxy, er løsningen en legitimasjon nettleseren kan presentere uten tilsyn. Hvis den kommer fra en oppstrøms proxy som den første sender videre til, tilhører legitimasjonen det andre hoppet, og den første proxyen kan videresende utfordringen uendret. Les autentiseringsomfanget og verten i Proxy-Authenticate-overskriften, fordi de navngir boksen som spør.

Bevar denne forskjellen i det du logger. En proxy-utfordring, en nektet viderekobling, en nettsidepålogging og et VPN-transporttidsavbrudd er fire forskjellige feil med fire forskjellige eiere, og én generisk feilmelding ødelegger informasjonen du trenger.

Sjekk 3: legitimasjonsbanen

Selve legitimasjonen er der de fleste ubetjente oppsett går i stykker. Selenium kan angi en proxy-vert og -port, men HTTP-proxy-autentisering er ikke en bærbar del av den konfigurasjonen, og legitimasjon i proxy-URLen er ikke en mekanisme du kan stole på på tvers av nettlesere og driverversjoner. De støttede alternativene er de faktiske stackdokumentene dine: en nettleserutvidelse som svarer på utfordringen, en lokal videresendingsproxy som legger til overskriften og som bare er tilgjengelig fra jobben, eller en proxy som autentiserer arbeidsbelastningen på andre måter. Velg en med vilje, og kontroller den mot nøyaktig nettleser-, driver- og Selenium-versjonen du vil kjøre.

Hold legitimasjonen unna stedene som lekker den. Kommandolinjer er synlige i prosessoppføringer, skjermbilder ender opp i testrapporter, nettlesersporinger og HAR-filer fanger opp overskrifter, og forpliktet testkonfigurasjon er for alltid. Bruk jobbens hemmelige leveringsmekanisme og redaksjonsreglene, og omfang proxy-kontoen til destinasjonene eller rollen den trenger.

Hvis organisasjonen tilbyr en tillatt direkte VPN-rute i stedet for en obligatorisk proxy, sammenligner du de to designene eksplisitt. Ikke deaktiver proxyen i det stille eller imiter en annen klients autentisering for å omgå policyen.

Sjekk 4: nettleserprosessens egen nettverkskontekst

Dette er sjekken folk hopper over. En nettleser lansert av en arbeider, en beholder eller en ekstern Selenium Grid-node bruker det miljøets nettverk, så den bærbare datamaskinens VPN-tilkobling og skallets proxy-variabler beskriver en bane nettleseren kanskje aldri berører.

Registrer fem fakta for den mislykkede jobben: nettleserverten, den konfigurerte proxyen, den første løsningsbanen, den valgte ruten og eieren av autentiseringen. Lag deretter en harmløs autorisert forespørsel fra den eksakte konteksten, med normal destinasjons-TLS-verifisering og applikasjonsautorisasjon på. En hodeløs nettleser som starter vellykket beviser verken proxy-adgang eller VPN-dekning, og et skjermbilde av en tom side beviser ingenting i det hele tatt. Forespørselen som returnerer 200 gjennom hele kjeden er det eneste beviset som teller.

Den ferdige arbeidsflyten har tre egenskaper som er verdt å sjekke som et sett. Det er en støttet rute fra nettleserverten til proxyen, en eksplisitt mellomleddspolicy som navngir proxyen og destinasjonene, og en påloggingslivssyklus som ikke er avhengig av at en operatør svarer på en usynlig forespørsel. Hvis noen av de tre avhenger av en person, er ikke jobben uovervåket ennå, uansett hva utgangskoden sier. Skriv ned de fem fakta før neste person arver rørledningen.