Mac-VPN og PAC-proxy: to avgjerder, ikkje éi innstilling

Macen din hentar eit politikk-skript og spør deretter det skriptet kva mellommann ein førespurnad skal bruke, medan tunnelen berre avgjer korleis det valde hoppet blir nådd. Begge svara endar på same socket, så ein førespurnad som feilar etter at begge lukkast, ser ut som éin feil når det er to. Å skilje hentinga frå valet, og valet frå ruta, er mesteparten av arbeidet i desse sakene. Rekkjefølgja nedanfor følgjer det macOS faktisk gjer, med kontrollane som gjer kvart trinn synleg.

Kvar PAC-adressa og proxyen skil lag

Eit skript som https://config.corp.example/proxy.pac nemner eit dokument som skal hentast, og det dokumentet nemner ein tenar som trafikken skal sendast gjennom. Å lime inn URL-en i eit proxy-vertsfelt ber klienten opne ein proxyforbindelse til ein filtenar som aldri lyttar etter ein. Inne i fila er ein funksjon som klienten kallar per førespurnad, og returverdien er det neste hoppet for nettopp den destinasjonen. Denne indireksjonen forklarar kvifor to maskinar på same nettverksteneste kan oppføre seg ulikt sjølv om begge har rett URL. Det forklarar òg kvifor ei politikkendring trer i kraft utan at nokon rører sjølve proxyen.

Les skriptet før du tolkar noko nedstraums, for reglane i det ber unntaka til organisasjonen og rekkjefølgja dei gjeld i. Eit tidleg breitt område kan skugge for eit seinare internt suffiks, og ein vert som tydeleg burde omgå proxyen held fram med å bruke han. Når nokon insisterer på at politikken er feil, er skriptet den einaste staden der den påstanden blir avgjort.

Skriptet må hentast før det avgjer noko

Å hente politikken krev eit namn som blir løyst opp og ei rute til det som tener fila, og ein tilkopla tunnel garanterer ingen av delane. Viss verten berre blir løyst opp via privat DNS, avgjer resolvaren som blir brukt i det augneblinken om hentinga kan byrje. Viss verten ligg på eit privat område, må ruta finnast frå denne maskinen og ikkje frå den berbare til ein kollega. Ein kopi som er mellomlagra i ei tidlegare økt, skjuler alt dette til mellomlageret går ut eller maskinen startar på nytt.

Køyr dei tre kontrollane nedanfor i rekkjefølgje og stopp ved første feil, fordi trinna ikkje deler årsak. Saman viser dei om politikken er konfigurert, om han er tilgjengeleg, og kva han returnerer.

scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac

Den første kommandoen skriv ut proxy-ordboka for den aktive tenesta, inkludert kvar einaste autokonfigurasjons-URL systemet held. Den andre rapporterer URL-en som er knytt til éi namngjeven teneste, noko som betyr noko på ein berbar som flyttar seg mellom Wi-Fi og Ethernet. Den tredje hentar fila utan å gjengi henne, slik at ein 404, ein tidsavbrot og ein resolverfeil blir haldne frå kvarandre. Viss den siste kommandoen returnerer skriptet medan applikasjonar framleis feilar, har problemet alt passert hentinga.

Kva eit DIRECT-svar eigentleg hoppar over

PAC-spesifikasjonen gir klienten eit lite ordforråd, og DIRECT er eitt av orda. Ordet fortel klienten å hoppe over proxyen for den førespurnaden og seier ingenting om kva grensesnitt socketen deretter brukar. Ein direkte socket på ein full tunnel går framleis ut gjennom VPN-en og viser framleis utgangsadressa til tunnelen til destinasjonen.

Å lese DIRECT som utanfor VPN-en er feilen som sender folk til feil innstillingspanel. Spegelbiletet er like vanleg, fordi ein privat proxy kan nåast over ei delt rute medan resten av maskinen blir utanfor tunnelen. Det destinasjonen rapporterer då, høyrer til eigen utgang hos proxyen, som kan liggje i eit anna land. Å skrive forventninga ned for éin intern vert og éin offentleg vert avdekkjer dette raskt, fordi skriptet ofte svarar dei to ulikt. Når du veit kva hopp som produserte adressa, sluttar rapporten å vere mystisk.

Tre feil som viser seg som éi feilside

Politikken kan feile med å bli henta, den valde proxyen kan vere utilgjengeleg, og ein førespurnad som når tenesta kan framleis bli avvist der. Alle tre kjem som eit tidsavbrot eller ei generisk feilside, og ingen av dei nemner trinnet som braut saman. Å fange avgjerda ved sida av feilen er det som skil dei. Dei to probane nedanfor testar hoppet skriptet valde, éin for kvar grein det kan returnere.

curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/

Ein fullført forbindelse til proxyen flyttar spørsmålet til autentisering eller til eigen politikk hos proxyen, som har ein annan eigar. Ein fullført forbindelse til den interne verten utan proxy i banen utelukkar ruta og peikar på politikken. Begge kommandoane ignorerer proxy-ordboka i macOS med mindre skalet eksporterer proxyvariablar, så tøm dei først. Ingen av probane bevisar den andre, og difor villeder éi feilside så lenge.

Kva du skal levere saman med saka

Send den aktive nettverkstenesta, PAC-URL-en, evalueringsresultatet for verten som feilar, og trinnet der feilen oppstod. Dei fire lèt neste person gjenskape avgjerda i staden for å gjete kva lag som var involvert. Legg til tilstanden til tunnelen på testtidspunktet, fordi eit resultat fanga før ei gjenoppkopling er utdatert. Ta òg vare på skriptrevisjonen, sidan politikkfila blir endra utan varsel og svaret frå i går kanskje ikkje lenger er gyldig.

Registrer korleis klienten oppfører seg når skriptet ikkje kan hentast, fordi implementasjonar er ulike og proxyavgjerda ikkje er ein einingsdekkjande naudstopp. Nokre fell tilbake til ein direkte forbindelse og andre feilar lukka, og den skilnaden endrar om eit utfall ser ut som ein øydelagd proxy eller som ein fungerande politikk. Stadfest åtferda for den nøyaktige klienten og versjonen før du stolar på henne under ei hending.