Warum ein PAC-Proxy in einer Gast-VM mit der URL des Hosts scheitert

„Der Host benutzt diese PAC-Datei, also habe ich dieselbe URL in die VM eingetragen“ ist ein vernünftiger Satz und ein unvollständiger Plan. Eine PAC-URL zeigt auf ein Richtlinienskript, nicht auf einen Proxy. Solange der Gast dieses Skript nicht abrufen, es mit den eigenen Adressen des Gastes auswerten und dann den vom Skript benannten Proxy erreichen kann, ist die URL nur eine Zeichenkette in einem Einstellungsfeld. Der größte Teil der Verwirrung um Proxy-Richtlinien in virtuellen Maschinen entsteht daraus, dass diese eine Zeile als die gesamte Konfiguration behandelt wird.

Eine PAC-URL ist ein Skript, kein Proxy

Die Datei enthält eine Funktion, die eine URL und einen Host entgegennimmt und eine Proxybeschreibung oder das Wort DIRECT zurückgibt. Nichts in der URL sagt der Anwendung, wohin der Datenverkehr gehen soll; diese Entscheidung fällt zur Laufzeit, im Skript, mit Daten, die das Skript bei der Plattform anfragt. Ein Einstellungsdialog, der eine PAC-URL akzeptiert, akzeptiert einen Zeiger auf ein Entscheidungsverfahren.

Dieser Unterschied ist der Grund, warum das Kopieren der URL so aussehen kann, als hätte es funktioniert. Das Feld ist gefüllt, die Einstellung ist gespeichert, und der Fehler zeigt sich erst später, wenn das Skript nicht abgerufen werden kann oder wenn es einen Proxy zurückgibt, den der Gast nicht erreicht.

Die vier Schritte scheitern jeweils anders

Im Gast müssen vier Dinge der Reihe nach geschehen, und jedes hat seine eigene Fehlersignatur. Der Gast ruft die PAC-Datei ab. Die Anwendung wertet das Skript für die angeforderte URL mit lokalen Informationen aus. Der ausgewählte Proxy wird aufgelöst und erreicht. Eine Authentifizierung erfolgt, wenn der Proxy sie verlangt.

Beweisen Sie zuerst den Abruf, denn alles Weitere ist ohne ihn bedeutungslos. Eine PAC-Datei auf einem privaten Server erfordert einen erlaubten Weg zu diesem Server, bevor irgendeine Regel helfen kann, und eine Proxy-Wahl in einem unerreichbaren Skript kann den Weg nicht schaffen, der sie abrufen würde:

curl -sS -o /dev/null -w '%{http_code}\n' http://pac.corp.example/proxy.pac
getent hosts pac.corp.example

Wenn diese Anfrage aus dem Gast scheitert und vom Host aus funktioniert, liegt das Problem im Weg des Gastes zum PAC-Server, nicht im Inhalt des Skripts. Wenn sie eine JavaScript-Datei zurückgibt, gehen Sie zum zweiten Schritt und finden Sie heraus, was das Skript für den Kontext des Gastes entscheidet.

Dasselbe Skript entscheidet in einer VM anders

PAC-Funktionen können den angeforderten Host und Informationen über die Maschine prüfen, die die Auswertung ausführt. Eine Regel, die auf der eigenen Adresse des Clients aufbaut, etwa eine, die eine Schnittstellenadresse oder eine Subnetz-Zugehörigkeit prüft, sieht die Adresse des Gastes statt die des physischen Hosts. Hinter NAT auf der Hostseite sind das unterschiedliche Adressen, und deshalb kann dasselbe Skript einen anderen Proxy wählen oder innerhalb der VM auf DIRECT zurückfallen.

Das ist kein Fehler im Skript. Das Skript tut genau das, wofür es geschrieben wurde, mit einer anderen Eingabe, und das erklärt den verwirrenden Bericht, in dem der Host den Proxy nutzt und der Gast direkt verbindet. Reproduzieren Sie die Entscheidung, statt über sie zu räsonieren: Ein PAC-Auswerter, der eine Adresse und eine URL entgegennimmt, klärt die Frage mit einem Befehl, falls Ihre Distribution einen mitbringt. Andernfalls testen Sie mit der Anwendung, die wirklich verwendet wird, und lesen deren Proxy-Protokoll, statt zu raten.

Ziehen Sie nicht den Schluss, dass der Gast die Proxy-Einstellungen des Hosts geerbt hat weil sein Verkehr durch eine Übersetzung auf der Hostseite läuft. Netzwerkübersetzung leitet Pakete weiter; sie kopiert keine Anwendungskonfiguration, und der System-Proxy ist Anwendungskonfiguration.

Werkzeuge, die PAC überhaupt nicht lesen

Kommandozeilenwerkzeuge sind eine eigene Grenze, und hier geht viel Zeit verloren. curl führt keine PAC-Dateien aus, wie seine Proxy-Dokumentation klar sagt. Eine Proxy-Variable auf die PAC-Download-URL zu richten, macht das Skript nicht zu einem Proxy-Endpunkt; das Werkzeug wird versuchen, mit einer JavaScript-Datei HTTP zu sprechen, und auf eine Weise scheitern, die wie ein Netzwerkproblem aussieht.

Dasselbe gilt für viele Paketmanager, Sprachlaufzeitumgebungen und Build-Werkzeuge, die nur ausdrückliche Proxy-Variablen oder ihre eigene Konfiguration beachten. Wenn der Test, der Sie interessiert, ein CLI-Werkzeug ist, konfigurieren Sie es mit dem konkreten Proxy, den das PAC-Skript gewählt hätte, und halten Sie fest, wie Sie zu dieser Wahl gekommen sind, damit die nächste Person sie wiederholen kann.

Für Desktop-Anwendungen unter Linux muss die Systemeinstellung auf den automatischen Modus gesetzt und ihr außerdem eine URL gegeben werden; eine URL, die gespeichert wird, während der Modus noch manuell ist, bewirkt nichts. Prüfen Sie beides, und prüfen Sie es im Gast:

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy autoconfig-url

DIRECT ist auch eine Entscheidung

Ein PAC-Ergebnis von DIRECT bedeutet, dass die Anwendung den HTTP-Proxy umgeht, nicht dass sie dem Netz entkommen ist. Die resultierende Verbindung kann weiterhin einer Betriebssystemroute durch einen Tunnel folgen oder aus Gründen scheitern, die nichts mit Proxy-Nutzung zu tun haben. Umgekehrt beschreibt ein Proxy-Ergebnis die Anfrage einer Anwendung, nicht jeden Prozess im Gast.

Prüfen Sie also in der Richtung, in der die Anforderung formuliert wurde. Wenn die Anforderung lautet „diese Anwendung erreicht die interne Seite“, belegen Sie, dass diese Anwendung es tut, und notieren Sie, welcher Proxy oder welche Route sie getragen hat. Wenn die Anforderung lautet „die VM ist im Unternehmensnetz“, ist ein funktionierender Browser über einen gewählten Proxy ein Beleg für diesen Browser und nicht mehr.

Reparieren Sie die Kette im Gast, statt den Tunnel des Hosts abzuschalten oder die Weiterleitungsrichtlinie zu lockern, damit ein Test besteht. Die Kette hat vier Glieder, und eine Änderung, die eines davon überspringt, hält bis zum nächsten Mal, an dem das Skript aktualisiert wird oder sich die Adresse des Gastes ändert.