curl non legge il tuo file PAC: passa il proxy

L’indirizzo del file PAC e l’endpoint del proxy sembrano intercambiabili in un file di configurazione, e non lo sono. Uno è un programma di politica che va valutato per ogni URL; l’altro è un host e una porta che accettano connessioni. curl capisce solo il secondo. Passare un indirizzo PAC a --proxy è un errore di categoria che fallisce in modo confuso, di solito dopo un lungo timeout CONNECT verso un server web.

Che cos’è davvero ciascuno

Lo dice chiaramente le FAQ di curl: curl non fornisce alcuna interpretazione di JavaScript né di PAC. Un wrapper attorno a curl che capisca PAC può farlo, ma curl stesso no, e nessuna opzione lo trasforma in un browser.

Perché il browser funziona e curl no

Un browser si integra con la configurazione proxy di sistema, scarica il file PAC ed esegue le sue regole contro l’URL che apri. Quella valutazione è il servizio che il file PAC fornisce, e avviene dentro il browser, non dentro il tuo terminale.

Scaricare il file PAC con curl ne ottiene solo il testo. Non fa eseguire la politica a curl, e leggerlo a mano per trovare un proxy è una versione manuale della stessa valutazione, con la stessa probabilità di scegliere il ramo sbagliato. Se lo leggi, leggi l’istruzione return che corrisponde al tuo host invece del primo nome di proxy nel file. La maggior parte dei file PAC ne contiene diversi, e solo un ramo riguarda te.

Per un proxy HTTP approvato e un servizio HTTPS approvato, una richiesta esemplificativa è:

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

Il primo indirizzo è il listener del proxy, il secondo è il servizio che vuoi. Questi sono endpoint di esempio e non un test che qualcuno ha eseguito, quindi sostituiscili con lo schema, la porta e il flusso di autenticazione della tua organizzazione.

Scegli il proxy per questa destinazione

Chiedi all’amministratore quale proxy seleziona la politica per l’URL che ti serve, non quale proxy possiede l’organizzazione. Le regole PAC possono restituire risultati diversi per servizi interni, siti pubblici e condizioni di commutazione per errore, e una regola che oggi corrisponde al tuo URL può corrispondere a un’altra dopo una modifica.

Se il flusso di lavoro richiede più di una richiesta nota, usa un’impostazione statica supportata dall’amministratore o un’integrazione approvata che capisca PAC. Codificare un solo indirizzo copiato funziona fino al giorno in cui la politica cambia e nessuno ricorda più perché fu scelto quell’indirizzo.

Poi guarda cosa eredita curl. Le variabili d’ambiente del proxy e NO_PROXY possono sovrascrivere o escludere il proxy che hai passato, e un’esclusione che corrisponde alla tua destinazione manda la richiesta direttamente senza dirlo. Conserva la politica prevista invece di eliminare ogni esclusione o forzare tutto attraverso un solo indirizzo. Esegui la richiesta una volta con -v e controlla a quale indirizzo si è effettivamente connessa.

Tieni separate le due identità TLS

Con un proxy HTTPS, sono in gioco due connessioni TLS: la tua verso il proxy e quella del proxy verso la destinazione. Ognuna ha la propria identità da verificare, e disattivare la verifica per una delle due non è una correzione PAC, è un secondo problema aggiunto al primo.

Lascia attiva la verifica e leggi l’errore che ottieni. Una richiesta di autenticazione del proxy, un proxy irraggiungibile e un rifiuto dal sito web sono tre esiti diversi, e solo il primo riguarda le credenziali. La VPN deve comunque fornire un percorso consentito verso un proxy privato, inclusa la risoluzione dei nomi per l’host del proxy stesso, prima che qualcosa di questo possa riuscire.

Annota l’endpoint, lo schema, la porta, il metodo di autenticazione, le esclusioni e il percorso VPN verso il proxy. È quella nota che rende riproducibile la richiesta successiva, ed è la differenza tra conoscere il proprio proxy e tirarlo a indovinare.