Mac-VPN en PAC-proxy: twee beslissingen, niet één instelling
Een PAC-bestand kiest een proxy per verzoek, terwijl de VPN een route kiest. Volg het ophalen, de selectie en de socket, en lees DIRECT niet meer als offline.
Je Mac downloadt een beleidsscript en vraagt dat script vervolgens welke tussenpersoon een verzoek moet gebruiken, terwijl de tunnel alleen bepaalt hoe de gekozen hop wordt bereikt. Beide antwoorden komen op dezelfde socket terecht, dus een verzoek dat mislukt nadat beide zijn geslaagd, ziet eruit als één fout terwijl het er twee zijn. Het scheiden van de download van de selectie, en de selectie van de route, is het grootste deel van het werk in deze tickets. De volgorde hieronder volgt wat macOS werkelijk doet, met de controles die elke fase zichtbaar maken.
Waar het PAC-adres en de proxy uiteengaan
Een adres zoals https://config.corp.example/proxy.pac noemt een document om te downloaden, en dat document noemt een server waar het verkeer doorheen moet. De URL in een proxy-hostveld plakken vraagt de client een proxyverbinding te openen naar een bestandsserver die nooit op zo'n verbinding luistert. In het bestand staat een functie die de client per verzoek aanroept, en de retourwaarde daarvan is de volgende hop voor precies die ene bestemming. Die indirectie verklaart waarom twee machines op dezelfde netwerkdienst zich anders kunnen gedragen terwijl beide de juiste URL hebben. Ze verklaart ook waarom een beleidswijziging van kracht wordt zonder dat iemand de proxy zelf aanraakt.
Lees het script voordat je iets stroomafwaarts interpreteert, want de regels erin dragen de uitzonderingen van de organisatie en de volgorde waarin ze gelden. Een vroeg breed bereik kan een later intern achtervoegsel overschaduwen, en een host die de proxy duidelijk zou moeten omzeilen, blijft hem gebruiken. Wanneer iemand volhoudt dat het beleid verkeerd is, is het script de enige plek waar die bewering wordt beslecht.
Het script moet worden opgehaald voordat het iets beslist
Het beleid downloaden vereist een opgeloste naam en een route naar wat het bestand ook serveert, en een verbonden tunnel garandeert geen van beide. Als de host alleen via privé-DNS wordt opgelost, beslist de resolver die op dat moment wordt gebruikt of de download kan beginnen. Als de host in een privébereik ligt, moet de route vanaf deze machine bestaan en niet vanaf de laptop van een collega. Een kopie die in een eerdere sessie is gecachet, verbergt dit alles tot de cache verloopt of de machine opnieuw opstart.
Voer de drie controles hieronder in volgorde uit en stop bij de eerste fout, want de fasen delen geen oorzaak. Samen laten ze zien of het beleid is geconfigureerd, of het bereikbaar is en wat het teruggeeft.
scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac
De eerste opdracht drukt het proxywoordenboek voor de actieve dienst af, inclusief elke automatische configuratie-URL die het systeem vasthoudt. De tweede meldt de URL die aan één genoemde dienst is gekoppeld, wat uitmaakt op een laptop die tussen Wi-Fi en Ethernet wisselt. De derde haalt het bestand op zonder het weer te geven, zodat een 404, een time-out en een resolverfout onderscheidbaar blijven. Als die laatste opdracht het script teruggeeft terwijl toepassingen nog steeds falen, is het probleem al voorbij het ophalen.
Wat een DIRECT-antwoord werkelijk overslaat
De PAC-specificatie geeft de client een kleine woordenschat, en DIRECT is een van die woorden. Het woord zegt de client dat hij de proxy voor dat verzoek moet overslaan en zegt niets over welke interface de socket daarna gebruikt. Een directe socket op een volledige tunnel verlaat nog steeds via de VPN en toont de bestemming nog steeds het uitgangsadres van de tunnel.
Het DIRECT als buiten de VPN lezen is de fout die mensen naar het verkeerde instellingenpaneel stuurt. Het spiegelbeeld is even gewoon, want een privéproxy is bereikbaar via een gesplitste route terwijl de rest van de machine buiten de tunnel blijft. Wat de bestemming dan meldt, hoort bij de eigen uitgang van de proxy, die in een ander land kan liggen. De verwachting voor één interne host en één openbare host opschrijven legt dit snel bloot, omdat het script de twee vaak verschillend beantwoordt. Zodra je weet welke hop het adres heeft geproduceerd, houdt het rapport op mysterieus te zijn.
Drie fouten die als één foutpagina verschijnen
Het beleid kan niet worden gedownload, de gekozen proxy kan onbereikbaar zijn, en een verzoek dat bij de dienst aankomt kan daar alsnog worden geweigerd. Alle drie komen als een time-out of een generieke foutpagina, en geen van hen noemt de fase die stukging. De beslissing naast de fout vastleggen is wat ze scheidt. De twee probes hieronder testen de hop die het script koos, één voor elke tak die het kan teruggeven.
curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/
Een voltooide verbinding met de proxy verplaatst de vraag naar authenticatie of naar het eigen beleid van de proxy, dat een andere eigenaar heeft. Een voltooide verbinding met de interne host zonder proxy in het pad sluit de route uit en wijst naar het beleid. Beide opdrachten negeren het proxywoordenboek van macOS tenzij de shell proxyvariabelen exporteert, dus wis die eerst. Geen van de probes bewijst de andere, en daarom misleidt één foutpagina zo lang.
Wat je met het ticket overdraagt
Stuur de actieve netwerkdienst, de PAC-URL, het evaluatieresultaat voor de falende host en de fase waarin de fout verscheen. Die vier laten de volgende persoon de beslissing reproduceren in plaats van te raden welke laag betrokken was. Voeg de tunnelstatus toe op het moment van de test, want een resultaat dat vóór een herverbinding is vastgelegd, is verouderd. Bewaar ook de scriptrevisie, omdat het beleidsbestand zonder kennisgeving verandert en het antwoord van gisteren misschien niet meer actueel is.
Registreer hoe de client zich gedraagt wanneer het script niet kan worden opgehaald, want implementaties verschillen en de proxybeslissing is geen apparaatbrede noodstop. Sommige vallen terug op een directe verbinding en andere falen gesloten, en dat verschil verandert of een storing op een kapotte proxy of op werkend beleid lijkt. Bevestig het gedrag voor de exacte client en versie voordat je er tijdens een incident op vertrouwt.