curl kan je PAC-bestand niet lezen: geef het proxy door

Het adres van het PAC-bestand en het eindpunt van de proxy lijken in een configuratiebestand uitwisselbaar, en dat zijn ze niet. Het ene is een beleidsprogramma dat voor elke URL moet worden geëvalueerd; het andere is een host en poort die verbindingen accepteert. curl begrijpt alleen het tweede. Een PAC-adres doorgeven aan --proxy is een categoriefout die op een verwarrende manier mislukt, meestal na een lange CONNECT-time-out naar een webserver.

Wat elk ervan werkelijk is

Dat zegt de FAQ van curl duidelijk: curl biedt geen JavaScript- of PAC-interpretatie. Een PAC-bewuste wrapper rond curl kan dat wel, curl zelf niet, en geen enkele optie maakt er een browser van.

Waarom de browser werkt en curl niet

Een browser integreert met de proxyconfiguratie van het systeem, haalt het PAC-bestand op en voert de regels ervan uit tegen de URL die je opent. Die evaluatie is de dienst die het PAC-bestand levert, en die gebeurt in de browser, niet in je terminal.

Het PAC-bestand met curl downloaden levert alleen de tekst op. Het zorgt er niet voor dat curl het beleid uitvoert, en het met de hand lezen om een proxy te vinden is een handmatige versie van dezelfde evaluatie, met dezelfde kans om de verkeerde tak te kiezen. Als je het leest, lees dan de return-instructie die bij je host past in plaats van de eerste proxynaam in het bestand. De meeste PAC-bestanden bevatten er meerdere, en slechts één tak is op jou van toepassing.

Voor een goedgekeurde HTTP-proxy en een goedgekeurde HTTPS-dienst is een verzoek ter illustratie:

curl --proxy http://proxy.corp.example:8080 https://service.example.net/status

Het eerste adres is de proxylistener, het tweede is de dienst die je wilt. Dit zijn voorbeeldeindpunten en geen test die iemand heeft uitgevoerd, dus vervang ze door het schema, de poort en de authenticatiestroom van je organisatie.

Kies het proxy voor deze bestemming

Vraag de beheerder welk proxy het beleid kiest voor de URL die je nodig hebt, niet welk proxy de organisatie bezit. PAC-regels kunnen verschillende resultaten geven voor interne diensten, openbare sites en failover-situaties, en een regel die vandaag bij je URL past, kan na een wijziging bij een andere passen.

Als de werkstroom meer dan één bekend verzoek nodig heeft, gebruik dan een door de beheerder ondersteunde statische instelling of een goedgekeurde PAC-bewuste integratie. Eén gekopieerd adres hardcoderen werkt tot de dag dat het beleid verandert en niemand meer weet waarom dat adres is gekozen.

Kijk dan naar wat curl erft. Proxy-omgevingsvariabelen en NO_PROXY kunnen het proxy dat je hebt doorgegeven overschrijven of uitsluiten, en een uitsluiting die bij je doel past, stuurt het verzoek stilletjes rechtstreeks. Behoud het bedoelde beleid in plaats van elke uitsluiting te verwijderen of alles door één adres te dwingen. Voer het verzoek één keer uit met -v en controleer met welk adres het werkelijk verbinding maakte.

Houd de twee TLS-identiteiten gescheiden

Bij een HTTPS-proxy zijn er twee TLS-verbindingen in het spel: die van jou naar het proxy en die van het proxy naar de bestemming. Elk heeft een eigen identiteit om te verifiëren, en verificatie uitschakelen voor een van beide is geen PAC-oplossing, het is een tweede probleem bovenop het eerste.

Laat de verificatie aan en lees de fout die je krijgt. Een proxy-authenticatie-uitdaging, een onbereikbaar proxy en een weigering van de website zijn drie verschillende uitkomsten, en alleen de eerste gaat over inloggegevens. De VPN moet nog steeds een toegestane route naar een privéproxy bieden, inclusief naamresolutie voor de proxyhost zelf, voordat iets hiervan kan slagen.

Schrijf het eindpunt, het schema, de poort, de authenticatiemethode, de uitsluitingen en de VPN-route naar het proxy op. Die registratie is wat het volgende verzoek reproduceerbaar maakt, en het is het verschil tussen je proxy kennen en ernaar gissen.