Mac-VPN och PAC-proxy: två beslut, inte en enda inställning

Din Mac hämtar ett policyskript och frågar sedan det skriptet vilken förmedlare en begäran ska använda, medan tunneln bara avgör hur det valda hoppet nås. Båda svaren landar på samma socket, så en begäran som misslyckas efter att båda lyckats ser ut som ett fel när det är två. Att skilja hämtningen från valet, och valet från rutten, är största delen av arbetet i dessa ärenden. Ordningen nedan följer vad macOS faktiskt gör, med de kontroller som gör varje steg synligt.

Där PAC-adressen och proxyn skiljer sig

En adress som https://config.corp.example/proxy.pac namnger ett dokument att hämta, och det dokumentet namnger en server som trafiken ska skickas genom. Att klistra in URL:en i ett proxy-värd-fält ber klienten öppna en proxyanslutning till en filserver som aldrig lyssnar efter en. Inne i filen finns en funktion som klienten anropar per begäran, och dess returvärde är nästa hopp för just den destinationen. Den indirektionen förklarar varför två maskiner på samma nätverkstjänst kan bete sig olika trots att båda har rätt URL. Den förklarar också varför en policyändring träder i kraft utan att någon rör själva proxyn.

Läs skriptet innan du tolkar något nedströms, eftersom reglerna i det bär organisationens undantag och den ordning de gäller i. Ett tidigt brett intervall kan skugga ett senare internt suffix, och en värd som uppenbart borde kringgå proxyn fortsätter att använda den. När någon hävdar att policyn är fel är skriptet den enda platsen där det påståendet avgörs.

Skriptet måste hämtas innan det avgör något

Att hämta policyn kräver ett upplöst namn och en rutt till det som serverar filen, och en ansluten tunnel garanterar ingendera. Om värden bara löses via privat DNS avgör resolvern som används i det ögonblicket om hämtningen kan börja. Om värden ligger på ett privat intervall måste rutten finnas från den här maskinen och inte från en kollegas bärbara dator. En kopia som cachats i en tidigare session döljer allt detta tills cachen går ut eller maskinen startar om.

Kör de tre kontrollerna nedan i ordning och stanna vid första felet, eftersom stegen inte delar orsak. Tillsammans visar de om policyn är konfigurerad, om den är nåbar och vad den returnerar.

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

Det första kommandot skriver ut proxyordboken för den aktiva tjänsten, inklusive varje autokonfigurations-URL som systemet håller. Det andra rapporterar URL:en som är kopplad till en namngiven tjänst, vilket spelar roll på en bärbar dator som växlar mellan Wi-Fi och Ethernet. Det tredje hämtar filen utan att rendera den, så en 404, en timeout och ett resolverfel förblir åtskiljbara. Om det sista kommandot returnerar skriptet medan program fortfarande misslyckas har problemet redan passerat hämtningen.

Vad ett DIRECT-svar egentligen hoppar över

PAC-specifikationen ger klienten ett litet ordförråd, och DIRECT är ett av dess ord. Ordet säger till klienten att hoppa över proxyn för den begäran och säger ingenting om vilket gränssnitt socketen sedan använder. En direkt socket på en full tunnel går fortfarande ut genom VPN:en och visar fortfarande tunnelns utgångsadress för destinationen.

Att läsa DIRECT som utanför VPN:en är felet som skickar folk till fel inställningspanel. Spegelbilden är lika vanlig, eftersom en privat proxy kan nås över en delad rutt medan resten av maskinen stannar utanför tunneln. Det destinationen rapporterar då tillhör proxyns egen utgång, som kan ligga i ett annat land. Att skriva ner förväntningen för en intern värd och en offentlig värd avslöjar detta snabbt, eftersom skriptet ofta svarar de två olika. När du vet vilket hopp som skapade adressen slutar rapporten att vara mystisk.

Tre fel som visar sig som en enda felsida

Policyn kan misslyckas att hämtas, den valda proxyn kan vara onåbar, och en begäran som når tjänsten kan fortfarande avvisas där. Alla tre kommer som en timeout eller en generisk felsida, och ingen av dem namnger steget som brast. Att fånga beslutet intill felet är det som skiljer dem. De två sonderna nedan testar hoppet som skriptet valde, en för varje gren det kan returnera.

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

En slutförd anslutning till proxyn flyttar frågan till autentisering eller till proxyns egen policy, som har en annan ägare. En slutförd anslutning till den interna värden utan proxy i vägen utesluter rutten och pekar på policyn. Båda kommandona ignorerar macOS proxyordbok om inte skalet exporterar proxyvariabler, så rensa dem först. Ingen av sonderna bevisar den andra, och därför vilseleder en felsida så länge.

Vad du ska lämna över med ärendet

Skicka den aktiva nätverkstjänsten, PAC-URL:en, utvärderingsresultatet för värden som misslyckas och steget där felet uppstod. De fyra låter nästa person återskapa beslutet i stället för att gissa vilket lager som var inblandat. Lägg till tunnelns tillstånd vid testtillfället, eftersom ett resultat som fångats före en återanslutning är inaktuellt. Spara också skriptrevisionen, eftersom policyfilen ändras utan varsel och gårdagens svar kanske inte längre är aktuellt.

Registrera hur klienten beter sig när skriptet inte kan hämtas, eftersom implementeringar skiljer sig och proxybeslutet inte är en enhetsövergripande nödstopp. Vissa faller tillbaka på en direkt anslutning och andra misslyckas stängt, och den skillnaden ändrar om ett avbrott ser ut som en trasig proxy eller som en fungerande policy. Bekräfta beteendet för den exakta klienten och versionen innan du förlitar dig på det under en incident.