Mac-VPN und PAC-Proxy: zwei Entscheidungen, keine einzelne Einstellung

Ihr Mac lädt ein Richtlinienskript herunter und fragt dieses Skript dann, welchen Vermittler eine Anfrage verwenden soll, während der Tunnel nur entscheidet, wie der gewählte Hop erreicht wird. Beide Antworten landen auf derselben Socket, sodass eine Anfrage, die scheitert, nachdem beide erfolgreich waren, wie ein Fehler aussieht, obwohl es zwei sind. Den Download von der Auswahl und die Auswahl von der Route zu trennen, ist der größte Teil der Arbeit in diesen Tickets. Die Reihenfolge unten folgt dem, was macOS tatsächlich tut, mit den Prüfungen, die jede Stufe sichtbar machen.

Wo sich PAC-Adresse und Proxy trennen

Eine Adresse wie https://config.corp.example/proxy.pac benennt ein herunterzuladendes Dokument, und dieses Dokument benennt einen Server, durch den der Verkehr laufen soll. Das Einfügen der URL in ein Proxy-Hostfeld fordert den Client auf, eine Proxy-Verbindung zu einem Dateiserver zu öffnen, der nie auf eine solche wartet. In der Datei steht eine Funktion, die der Client pro Anfrage aufruft, und ihr Rückgabewert ist der nächste Hop für genau dieses Ziel. Diese Indirektion erklärt, warum sich zwei Rechner im selben Netzwerkdienst unterschiedlich verhalten können, obwohl beide die richtige URL haben. Sie erklärt auch, warum eine Richtlinienänderung wirksam wird, ohne dass jemand den Proxy selbst anfasst.

Lesen Sie das Skript, bevor Sie irgendetwas nachgelagert interpretieren, denn die Regeln darin tragen die Ausnahmen der Organisation und die Reihenfolge, in der sie gelten. Ein früher breiter Bereich kann einen späteren internen Suffix überschatten, und ein Host, der den Proxy offensichtlich umgehen sollte, verwendet ihn weiter. Wenn jemand behauptet, die Richtlinie sei falsch, ist das Skript der einzige Ort, an dem diese Behauptung geklärt wird.

Das Skript muss abgerufen werden, bevor es etwas entscheidet

Das Herunterladen der Richtlinie braucht einen aufgelösten Namen und eine Route zu dem, was die Datei bereitstellt, und ein verbundener Tunnel garantiert keins von beidem. Wenn der Host nur über privates DNS aufgelöst wird, entscheidet der zu diesem Zeitpunkt verwendete Resolver, ob der Download beginnen kann. Wenn der Host in einem privaten Bereich liegt, muss die Route von dieser Maschine aus bestehen und nicht vom Laptop eines Kollegen. Eine in einer früheren Sitzung zwischengespeicherte Kopie verbirgt all das, bis der Cache abläuft oder die Maschine neu startet.

Führen Sie die drei Prüfungen unten der Reihe nach aus und halten Sie beim ersten Fehler an, denn die Stufen teilen keine Ursache. Zusammen zeigen sie, ob die Richtlinie konfiguriert ist, ob sie erreichbar ist und was sie zurückgibt.

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

Der erste Befehl gibt das Proxy-Wörterbuch für den aktiven Dienst aus, einschließlich jeder Auto-Konfigurations-URL, die das System hält. Der zweite meldet die URL, die an einen benannten Dienst gebunden ist, was auf einem Laptop zählt, der zwischen Wi-Fi und Ethernet wechselt. Der dritte ruft die Datei ab, ohne sie zu rendern, sodass ein 404, eine Zeitüberschreitung und ein Resolverfehler unterscheidbar bleiben. Wenn der letzte Befehl das Skript zurückgibt, während Anwendungen weiterhin scheitern, hat das Problem den Abruf bereits hinter sich.

Was eine DIRECT-Antwort tatsächlich überspringt

Die PAC-Spezifikation gibt dem Client ein kleines Vokabular, und DIRECT ist eines seiner Wörter. Das Wort sagt dem Client, dass er den Proxy für diese Anfrage überspringen soll, und sagt nichts darüber, welche Schnittstelle die Socket danach verwendet. Eine direkte Socket auf einem Volltunnel verlässt trotzdem den Rechner über das VPN und zeigt dem Ziel trotzdem die Ausgangsadresse des Tunnels.

DIRECT als außerhalb des VPN zu lesen, ist der Fehler, der Leute zum falschen Einstellungsfenster schickt. Das Spiegelbild ist ebenso verbreitet, denn ein privater Proxy kann über eine geteilte Route erreicht werden, während der Rest der Maschine außerhalb des Tunnels bleibt. Was das Ziel dann meldet, gehört zum eigenen Ausgang des Proxys, der in einem anderen Land liegen kann. Die Erwartung für einen internen und einen öffentlichen Host aufzuschreiben, legt das schnell offen, da das Skript die beiden oft unterschiedlich beantwortet. Sobald Sie wissen, welcher Hop die Adresse erzeugt hat, hört der Bericht auf, rätselhaft zu sein.

Drei Fehler, die als eine Fehlerseite erscheinen

Die Richtlinie kann beim Herunterladen scheitern, der gewählte Proxy kann unerreichbar sein, und eine Anfrage, die beim Dienst ankommt, kann dort trotzdem abgelehnt werden. Alle drei kommen als Zeitüberschreitung oder generische Fehlerseite an, und keine nennt die Stufe, die brach. Die Entscheidung neben dem Fehler festzuhalten, ist das, was sie trennt. Die beiden Sonden unten testen den Hop, den das Skript gewählt hat, eine für jeden Zweig, den es zurückgeben kann.

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

Eine vollständige Verbindung zum Proxy verlagert die Frage auf die Authentifizierung oder auf die eigene Richtlinie des Proxys, die einen anderen Eigentümer hat. Eine vollständige Verbindung zum internen Host ohne Proxy im Pfad schließt die Route aus und deutet auf die Richtlinie. Beide Befehle ignorieren das macOS-Proxy-Wörterbuch, sofern die Shell keine Proxy-Variablen exportiert, also löschen Sie diese zuerst. Keine der beiden Sonden beweist die andere, weshalb eine Fehlerseite so lange in die Irre führt.

Was Sie mit dem Ticket übergeben sollten

Senden Sie den aktiven Netzwerkdienst, die PAC-URL, das Bewertungsergebnis für den fehlschlagenden Host und die Stufe, auf der der Fehler auftrat. Diese vier lassen die nächste Person die Entscheidung reproduzieren, statt zu raten, welche Schicht beteiligt war. Fügen Sie den Tunnelzustand zum Zeitpunkt des Tests hinzu, denn ein vor einer Wiederverbindung erfasstes Ergebnis ist veraltet. Behalten Sie auch die Skriptrevision, da sich die Richtliniendatei ohne Ankündigung ändert und die gestrige Antwort möglicherweise nicht mehr aktuell ist.

Halten Sie fest, wie sich der Client verhält, wenn das Skript nicht abgerufen werden kann, denn Implementierungen unterscheiden sich, und die Proxy-Entscheidung ist kein geräteweiter Notausschalter. Manche fallen auf eine direkte Verbindung zurück, andere scheitern geschlossen, und dieser Unterschied entscheidet, ob ein Ausfall wie ein defekter Proxy oder wie eine funktionierende Richtlinie aussieht. Bestätigen Sie das Verhalten für den genauen Client und die Version, bevor Sie sich während eines Vorfalls darauf verlassen.