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

Din Mac henter et politikscript og spørger derefter det script, hvilken mellemmand en anmodning skal bruge, mens tunnelen kun afgør, hvordan det valgte hop nås. Begge svar ender på samme sokkel, så en anmodning, der fejler, efter at begge lykkedes, ligner én fejl, når den er to. At skille hentningen fra valget og valget fra ruten er størstedelen af arbejdet i disse sager. Rækkefølgen nedenfor følger, hvad macOS faktisk gør, med de kontroller, der gør hvert trin synligt.

Hvor PAC-adressen og proxyen skilles

En adresse som https://config.corp.example/proxy.pac navngiver et dokument, der skal hentes, og det dokument navngiver en server, som trafikken skal sendes igennem. At indsætte URL'en i et proxy-værtfelt beder klienten om at åbne en proxyforbindelse til en filserver, der aldrig lytter efter en. Inde i filen er en funktion, som klienten kalder for hver anmodning, og dens returværdi er det næste hop for netop den destination. Denne indirektion forklarer, hvorfor to maskiner på samme netværkstjeneste kan opføre sig forskelligt, selv om begge har den korrekte URL. Det forklarer også, hvorfor en politikændring træder i kraft, uden at nogen rører proxyen selv.

Læs scriptet, før du fortolker noget nedstrøms, for reglerne i det bærer organisationens undtagelser og den rækkefølge, de gælder i. Et tidligt bredt interval kan skygge for et senere internt suffix, og en vært, der tydeligt burde omgå proxyen, bliver ved med at bruge den. Når nogen insisterer på, at politikken er forkert, er scriptet det eneste sted, hvor den påstand afgøres.

Scriptet skal hentes, før det afgør noget

At hente politikken kræver et navn, der opløses, og en rute til det, der serverer filen, og en tilsluttet tunnel garanterer ingen af delene. Hvis værten kun opløses via privat DNS, afgør den resolver, der bruges i det øjeblik, om hentningen kan begynde. Hvis værten ligger på et privat interval, skal ruten findes fra denne maskine og ikke fra en kollegas bærbare. En kopi, der er cachet i en tidligere session, skjuler alt dette, indtil cachen udløber, eller maskinen genstarter.

Kør de tre kontroller nedenfor i rækkefølge, og stop ved den første fejl, fordi trinnene ikke deler årsag. Tilsammen viser de, om politikken er konfigureret, om den kan nås, og hvad 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 kommando udskriver proxy-ordbogen for den aktive tjeneste, inklusive enhver auto-konfigurations-URL, som systemet holder. Den anden rapporterer den URL, der er knyttet til én navngivet tjeneste, hvilket betyder noget på en bærbar, der skifter mellem Wi-Fi og Ethernet. Den tredje henter filen uden at gengive den, så en 404, en timeout og en resolverfejl forbliver til at skelne. Hvis den sidste kommando returnerer scriptet, mens programmer stadig fejler, har problemet allerede passeret hentningen.

Hvad et DIRECT-svar egentlig springer over

PAC-specifikationen giver klienten et lille ordforråd, og DIRECT er et af dets ord. Ordet fortæller klienten, at den skal springe proxyen over for den anmodning, og siger intet om, hvilket interface soklen derefter bruger. En direkte sokkel på en fuld tunnel forlader stadig gennem VPN'en og viser stadig tunnelens udgangsadresse til destinationen.

At læse DIRECT som uden for VPN'en er den fejl, der sender folk til det forkerte indstillingspanel. Det spejlede billede er lige så almindeligt, fordi en privat proxy kan nås over en delt rute, mens resten af maskinen bliver uden for tunnelen. Det, destinationen rapporterer, tilhører proxyens egen udgang, som kan ligge i et andet land. At skrive forventningen ned for én intern vært og én offentlig vært afslører det hurtigt, fordi scriptet ofte svarer de to forskelligt. Når du ved, hvilket hop der frembragte adressen, holder rapporten op med at være mystisk.

Tre fejl, der viser sig som én fejlside

Politikken kan fejle med at blive hentet, den valgte proxy kan være utilgængelig, og en anmodning, der når tjenesten, kan stadig blive afvist der. Alle tre ankommer som en timeout eller en generisk fejlside, og ingen af dem nævner det trin, der brød sammen. At fange beslutningen ved siden af fejlen er det, der skiller dem. De to prober nedenfor tester det hop, scriptet valgte, en 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 fuldført forbindelse til proxyen flytter spørgsmålet til godkendelse eller til proxyens egen politik, som har en anden ejer. En fuldført forbindelse til den interne vært uden proxy i stien udelukker ruten og peger på politikken. Begge kommandoer ignorerer macOS' proxy-ordbog, medmindre shellen eksporterer proxyvariabler, så ryd dem først. Ingen af proberne beviser den anden, og derfor vildleder én fejlside så længe.

Hvad du skal aflevere sammen med sagen

Send den aktive netværkstjeneste, PAC-URL'en, evalueringsresultatet for den fejlende vært og det trin, hvor fejlen opstod. De fire lader den næste person genskabe beslutningen i stedet for at gætte, hvilket lag der var involveret. Tilføj tunnelens tilstand på testtidspunktet, fordi et resultat fanget før en genopkobling er forældet. Behold også scriptrevisionen, da politikfilen ændres uden varsel, og gårsdagens svar måske ikke længere er aktuelt.

Registrér, hvordan klienten opfører sig, når scriptet ikke kan hentes, fordi implementeringer er forskellige, og proxybeslutningen er ikke en enhedsdækkende nødstop. Nogle falder tilbage til en direkte forbindelse, og andre fejler lukket, og den forskel ændrer, om et udfald ligner en brudt proxy eller en fungerende politik. Bekræft adfærden for den præcise klient og version, før du stoler på den under en hændelse.