Proxy-autentisering i hovudlaus nettlesar er ikkje ei VPN-rute

En VPN kan føre nettleserens trafikk til en proxy-server og fortsatt la nettleseren vere ute av stand til å bruke den proxyen, fordi en rute og en legitimasjon er forskjellige ting. Hodeløs automatisering gjer gapet vanskeligere å se, siden det ikkje er noko 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å vere 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 utan å vere 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 ikkje 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 korleis legitimasjonen leveres utan et menneske. Hver enkelt kan feile uavhengig, og hver feil ser lik ut utenfra. Arbeid dei i rekkefølge, fordi en senere sjekk ikkje kan kompensere for en tidligere. En proxy som aldri vart valgt kan ikkje autentiseres, og en legitimasjon som berre finnes på den bærbare datamaskinen din kan ikkje 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 frå innsiden av nettleserens miljø i stedet for frå 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, kva Proxy-Authenticate kom tilbake og om en 407 vart returnert. Hvis curl får en 407 og nettleseren henger, er legitimasjonsbanen problemet snarere enn nettverket. Hvis curl lykkes og nettleseren ikkje gjer det, brukar ikkje nettleseren proxyen du tror den er.

Sjekk 2: hvem som svarer på 407

En 407 har en eier, og navngivningen avgjør kvar rettelsen går. Hvis utfordringen kommer frå bedriftens proxy, er løsningen en legitimasjon nettleseren kan presentere utan tilsyn. Hvis den kommer frå 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 ikkje en bærbar del av den konfigurasjonen, og legitimasjon i proxy-URLen er ikkje 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 berre er tilgjengelig frå 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 brukar 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 frå 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 frå nettleserverten til proxyen, en eksplisitt mellomleddspolicy som navngir proxyen og destinasjonene, og en påloggingslivssyklus som ikkje er avhengig av at en operatør svarer på en usynlig forespørsel. Hvis nokon av de tre avhenger av en person, er ikkje jobben uovervåket ennå, uansett kva utgangskoden seier. Skriv ned de fem fakta før neste person arver rørledningen.