Mac-VPN og PAC-proxy: to beslutninger, ikke én innstilling

Macen din henter et politikk-skript og spør deretter det skriptet hvilken mellommann en forespørsel skal bruke, mens tunnelen bare avgjør hvordan det valgte hoppet nås. Begge svarene ender på samme socket, så en forespørsel som feiler etter at begge lyktes, ser ut som én feil når den er to. Å skille hentingen fra valget, og valget fra ruten, er mesteparten av arbeidet i disse sakene. Rekkefølgen nedenfor følger det macOS faktisk gjør, med kontrollene som gjør hvert trinn synlig.

Hvor PAC-adressen og proxyen skiller lag

En adresse som https://config.corp.example/proxy.pac navngir et dokument som skal hentes, og det dokumentet navngir en server som trafikken skal sendes gjennom. Å lime inn URL-en i et proxy-vertsfelt ber klienten åpne en proxyforbindelse til en filserver som aldri lytter etter en. Inne i filen er en funksjon som klienten kaller per forespørsel, og returverdien er det neste hoppet for nettopp den destinasjonen. Denne indirektionen forklarer hvorfor to maskiner på samme nettverkstjeneste kan oppføre seg forskjellig selv om begge har riktig URL. Det forklarer også hvorfor en politikkendring trer i kraft uten at noen rører selve proxyen.

Les skriptet før du tolker noe nedstrøms, for reglene i det bærer organisasjonens unntak og rekkefølgen de gjelder i. Et tidlig bredt område kan skygge for et senere internt suffiks, og en vert som tydelig burde omgå proxyen fortsetter å bruke den. Når noen insisterer på at politikken er feil, er skriptet det eneste stedet der den påstanden avgjøres.

Skriptet må hentes før det avgjør noe

Å hente politikken krever et navn som løses opp og en rute til det som serverer filen, og en tilkoblet tunnel garanterer ingen av delene. Hvis verten bare løses opp via privat DNS, avgjør resolveren som brukes i det øyeblikket om hentingen kan begynne. Hvis verten ligger på et privat område, må ruten finnes fra denne maskinen og ikke fra en kollegas bærbare. En kopi som er bufret i en tidligere økt skjuler alt dette til bufferen utløper eller maskinen starter på nytt.

Kjør de tre kontrollene nedenfor i rekkefølge og stopp ved første feil, fordi trinnene ikke deler årsak. Sammen viser de om politikken er konfigurert, om den er tilgjengelig, og hva den 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 skriver ut proxy-ordboken for den aktive tjenesten, inkludert enhver autokonfigurasjons-URL systemet holder. Den andre rapporterer URL-en som er knyttet til én navngitt tjeneste, noe som betyr noe på en bærbar som beveger seg mellom Wi-Fi og Ethernet. Den tredje henter filen uten å gjengi den, slik at en 404, en tidsavbrudd og en resolverfeil forblir til å skille. Hvis den siste kommandoen returnerer skriptet mens applikasjoner fortsatt feiler, har problemet allerede passert hentingen.

Hva et DIRECT-svar egentlig hopper over

PAC-spesifikasjonen gir klienten et lite ordforråd, og DIRECT er ett av ordene. Ordet forteller klienten å hoppe over proxyen for den forespørselen og sier ingenting om hvilket grensesnitt socketen deretter bruker. En direkte socket på en full tunnel går fortsatt ut gjennom VPN-en og viser fortsatt tunnelens utgangsadresse til destinasjonen.

Å lese DIRECT som utenfor VPN-en er feilen som sender folk til feil innstillingspanel. Speilbildet er like vanlig, fordi en privat proxy kan nås over en delt rute mens resten av maskinen blir utenfor tunnelen. Det destinasjonen rapporterer da, tilhører proxyens egen utgang, som kan ligge i et annet land. Å skrive forventningen ned for én intern vert og én offentlig vert avslører dette raskt, fordi skriptet ofte svarer de to forskjellig. Når du vet hvilket hopp som produserte adressen, slutter rapporten å være mystisk.

Tre feil som viser seg som én feilside

Politikken kan feile med å bli hentet, den valgte proxyen kan være utilgjengelig, og en forespørsel som når tjenesten kan fortsatt bli avvist der. Alle tre kommer som en tidsavbrudd eller en generisk feilside, og ingen av dem navngir trinnet som brøt sammen. Å fange beslutningen ved siden av feilen er det som skiller dem. De to probene nedenfor tester hoppet skriptet valgte, én for hver gren det kan returnere.

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

En fullført forbindelse til proxyen flytter spørsmålet til autentisering eller til proxyens egen politikk, som har en annen eier. En fullført forbindelse til den interne verten uten proxy i banen utelukker ruten og peker på politikken. Begge kommandoene ignorerer macOS' proxy-ordbok med mindre skallet eksporterer proxyvariabler, så tøm dem først. Ingen av probene beviser den andre, og derfor villeder én feilside så lenge.

Hva du skal levere sammen med saken

Send den aktive nettverkstjenesten, PAC-URL-en, evalueringsresultatet for verten som feiler, og trinnet der feilen oppstod. De fire lar neste person gjenskape beslutningen i stedet for å gjette hvilket lag som var involvert. Legg til tunnelens tilstand på testtidspunktet, fordi et resultat fanget før en gjenoppkobling er utdatert. Ta også vare på skriptrevisjonen, siden politikkfilen endres uten varsel og gårsdagens svar kanskje ikke lenger er gyldig.

Registrer hvordan klienten oppfører seg når skriptet ikke kan hentes, fordi implementasjoner er forskjellige og proxybeslutningen ikke er en enhetsdekkende nødstopp. Noen faller tilbake til en direkte forbindelse og andre feiler lukket, og den forskjellen endrer om et utfall ser ut som en ødelagt proxy eller som en fungerende politikk. Bekreft oppførselen for den nøyaktige klienten og versjonen før du stoler på den under en hendelse.