curl kann Ihre PAC-Datei nicht lesen: übergeben Sie stattdessen den Proxy
PAC ist eine JavaScript-Richtlinie; curl möchte einen Endpunkt. Fragen Sie, welchen Proxy die Richtlinie für Ihre URL wählt, übergeben Sie ihn und achten Sie auf NO_PROXY und TLS.
Die Adresse der PAC-Datei und der Proxy-Endpunkt sehen in einer Konfigurationsdatei austauschbar aus, und das sind sie nicht. Das eine ist ein Richtlinienprogramm, das für jede URL ausgewertet werden muss; das andere ist ein Host und Port, der Verbindungen annimmt. curl versteht nur das zweite. Eine PAC-Adresse an --proxy zu übergeben, ist ein Kategoriefehler, der auf verwirrende Weise scheitert, meist nach einem langen CONNECT-Timeout zu einem Webserver.
Was jedes davon tatsächlich ist
| Sie haben | Was es ist | Was curl damit macht |
|---|---|---|
http://wpad.corp.example/proxy.pac | JavaScript, das für eine bestimmte URL einen Proxy oder eine direkte Verbindung zurückgibt | Lädt es als Datei herunter und hört dort auf |
http://proxy.corp.example:8080 | Ein Listener, der proxied Anfragen annimmt | Verwendet ihn, einschließlich CONNECT für HTTPS-Ziele |
Die curl-FAQ sagt es deutlich: curl bietet keine JavaScript- oder PAC-Interpretation. Ein PAC-fähiger Wrapper um curl mag das tun, curl selbst aber nicht, und kein Flag macht daraus einen Browser.
Warum der Browser funktioniert und curl nicht
Ein Browser integriert sich in die Systemproxykonfiguration, lädt die PAC-Datei herunter und führt ihre Regeln für die URL aus, die Sie öffnen. Diese Auswertung ist die Leistung, die die PAC-Datei erbringt, und sie findet im Browser statt, nicht in Ihrem Terminal.
Die PAC-Datei mit curl herunterzuladen, liefert nur ihren Text. Das bringt curl nicht dazu, die Richtlinie auszuführen, und sie von Hand zu lesen, um einen Proxy zu finden, ist eine manuelle Version derselben Auswertung mit derselben Chance, den falschen Zweig zu wählen. Wenn Sie sie lesen, lesen Sie die return-Anweisung, die zu Ihrem Host passt, statt des ersten Proxynamens in der Datei. Die meisten PAC-Dateien enthalten mehrere, und nur ein Zweig trifft auf Sie zu.
Für einen freigegebenen HTTP-Proxy und einen freigegebenen HTTPS-Dienst lautet eine beispielhafte Anfrage:
curl --proxy http://proxy.corp.example:8080 https://service.example.net/statusDie erste Adresse ist der Proxy-Listener, die zweite der Dienst, den Sie möchten. Das sind Beispielendpunkte und kein Test, den jemand durchgeführt hat, ersetzen Sie sie daher durch Schema, Port und Authentifizierungsablauf Ihrer Organisation.
Wählen Sie den Proxy für dieses Ziel
Fragen Sie den Administrator, welchen Proxy die Richtlinie für die benötigte URL auswählt, nicht welchen Proxy die Organisation besitzt. PAC-Regeln können für interne Dienste, öffentliche Websites und Failover-Bedingungen unterschiedliche Ergebnisse liefern, und eine Regel, die heute zu Ihrer URL passt, kann nach einer Änderung zu einer anderen passen.
Wenn der Ablauf mehr als eine bekannte Anfrage benötigt, verwenden Sie eine vom Administrator unterstützte statische Einstellung oder eine freigegebene PAC-fähige Integration. Eine kopierte Adresse fest zu verdrahten funktioniert bis zu dem Tag, an dem sich die Richtlinie ändert und niemand mehr weiß, warum diese Adresse gewählt wurde.
Sehen Sie dann, was curl erbt. Proxy-Umgebungsvariablen und NO_PROXY können den übergebenen Proxy überschreiben oder ausschließen, und ein Ausschluss, der auf Ihr Ziel passt, sendet die Anfrage stillschweigend direkt. Behalten Sie die beabsichtigte Richtlinie bei, statt jeden Ausschluss zu löschen oder alles durch eine Adresse zu zwingen. Führen Sie die Anfrage einmal mit -v aus und prüfen Sie, mit welcher Adresse sie sich tatsächlich verbunden hat.
Halten Sie die beiden TLS-Identitäten auseinander
Bei einem HTTPS-Proxy sind zwei TLS-Verbindungen im Spiel: Ihre zum Proxy und die des Proxys zum Ziel. Jede hat ihre eigene Identität zu prüfen, und die Prüfung für eine von beiden abzuschalten ist keine PAC-Lösung, sondern ein zweites Problem zusätzlich zum ersten.
Lassen Sie die Prüfung aktiv und lesen Sie den Fehler, den Sie bekommen. Eine Proxy-Authentifizierungsaufforderung, ein nicht erreichbarer Proxy und eine Ablehnung durch die Website sind drei verschiedene Ergebnisse, und nur das erste betrifft Anmeldedaten. Das VPN muss weiterhin einen erlaubten Weg zu einem privaten Proxy bereitstellen, einschließlich Namensauflösung für den Proxy-Host selbst, bevor irgendetwas davon gelingen kann.
Notieren Sie Endpunkt, Schema, Port, Authentifizierungsmethode, Ausschlüsse und den VPN-Weg zum Proxy. Dieser Eintrag macht die nächste Anfrage reproduzierbar, und er ist der Unterschied zwischen dem Wissen um Ihren Proxy und dem Raten darüber.