Perché un proxy PAC in una VM ospite fallisce con l’URL dell’host

«L’host usa questo file PAC, quindi ho messo lo stesso URL nella VM» è una frase ragionevole e un piano incompleto. Un URL PAC punta a uno script di criterio, non a un proxy. Finché il guest non può scaricare quello script, valutarlo con gli indirizzi propri del guest e poi raggiungere qualunque proxy lo script nomini, l’URL è solo una stringa in un campo di impostazioni. Gran parte della confusione sulla politica proxy nelle macchine virtuali nasce dal trattare quella singola riga come l’intera configurazione.

Un URL PAC è uno script, non un proxy

Il file contiene una funzione che riceve un URL e un host e restituisce una descrizione di proxy o la parola DIRECT. Nulla nell’URL dice all’applicazione dove inviare il traffico; quella decisione avviene a runtime, dentro lo script, con dati che lo script chiede alla piattaforma. Una finestra di impostazioni che accetta un URL PAC accetta un puntatore a una procedura di decisione.

È questa distinzione a spiegare perché copiare l’URL può sembrare che abbia funzionato. Il campo è compilato, l’impostazione è salvata, e il guasto compare solo più tardi, quando lo script non si può scaricare o quando restituisce un proxy che il guest non raggiunge.

I quattro passaggi falliscono ciascuno a modo suo

Dentro il guest devono accadere quattro cose in ordine, e ciascuna ha la propria firma d’errore. Il guest scarica il file PAC. L’applicazione valuta lo script per l’URL richiesto con informazioni locali. Il proxy selezionato viene risolto e raggiunto. L’autenticazione avviene se il proxy la richiede.

Iniziate dimostrando lo scaricamento, perché tutto il resto è privo di senso senza. Un file PAC su un server privato richiede un percorso consentito verso quel server prima che qualsiasi regola possa aiutare, e una scelta di proxy dentro uno script irraggiungibile non può creare il percorso che lo scaricherebbe:

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

Se quella richiesta fallisce dal guest e funziona dall’host, il problema è il percorso del guest verso il server PAC, non il contenuto dello script. Se restituisce un file JavaScript, passate al secondo passaggio e scoprite cosa decide lo script per il contesto del guest.

Lo stesso script decide diversamente dentro una VM

Le funzioni PAC possono ispezionare l’host richiesto e informazioni sulla macchina che esegue la valutazione. Una regola costruita sull’indirizzo proprio del client, per esempio una che controlla un indirizzo di interfaccia o l’appartenenza a una sottorete, vedrà l’indirizzo del guest invece di quello dell’host fisico. Dietro il NAT lato host sono indirizzi diversi, e quindi lo stesso script può scegliere un altro proxy o tornare a DIRECT dentro la VM.

Non è un difetto dello script. È lo script che fa esattamente ciò per cui è stato scritto, con un input diverso, e questo spiega il resoconto confuso in cui l’host usa il proxy e il guest si connette direttamente. Riproducete la decisione invece di ragionarci sopra: un valutatore PAC che prende un indirizzo e un URL, se la vostra distribuzione ne include uno, risolve la questione con un solo comando. Altrimenti provate con l’applicazione che sarà realmente usata e leggete il suo registro proxy invece di indovinare.

Non concludete che il guest abbia ereditato le impostazioni proxy dell’host perché il suo traffico passa per una traduzione lato host. La traduzione di rete inoltra i pacchetti; non copia la configurazione delle applicazioni, e il proxy di sistema è configurazione dell’applicazione.

Strumenti che non leggono affatto PAC

Gli strumenti da riga di comando sono un confine a parte, ed è qui che si perde molto tempo. curl non esegue i file PAC, come la sua documentazione sul proxy dice chiaramente. Puntare una variabile proxy all’URL di download del PAC non trasforma lo script in un endpoint proxy; lo strumento tenterà di parlare HTTP con un file JavaScript e fallirà in un modo che sembra un problema di rete.

Lo stesso vale per molti gestori di pacchetti, runtime di linguaggi e strumenti di build, che rispettano solo variabili proxy esplicite o la propria configurazione. Se il test che vi interessa è uno strumento CLI, configuratelo con il proxy concreto che lo script PAC avrebbe scelto, e annotate come siete arrivati a quella scelta perché la persona successiva possa ripeterla.

Per le applicazioni desktop su Linux, l’impostazione di sistema deve essere messa in modalità automatica e deve anche ricevere un URL; un URL salvato mentre la modalità è ancora manuale non fa nulla. Controllate entrambe le cose, e controllatele dentro il guest:

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

Anche DIRECT è una decisione

Un risultato PAC di DIRECT significa che l’applicazione aggira il proxy HTTP, non che è uscita dalla rete. La connessione risultante può comunque seguire una rotta del sistema operativo attraverso un tunnel, o fallire per motivi che non hanno nulla a che fare con l’uso del proxy. Al contrario, un risultato di proxy descrive la richiesta di una sola applicazione, non ogni processo del guest.

Verificate quindi nella direzione in cui il requisito è stato scritto. Se il requisito è «questa applicazione raggiunge il sito interno», dimostrate che quella applicazione lo raggiunge, e annotate quale proxy o rotta l’ha portata. Se il requisito è «la VM è sulla rete aziendale», un browser che funziona attraverso un proxy selezionato è una prova per quel browser e nulla di più.

Riparate la catena dentro il guest invece di spegnere il tunnel dell’host o di allentare la politica di inoltro per far passare un test. La catena ha quattro anelli, e una modifica che ne salta uno resisterà fino alla prossima volta in cui lo script viene aggiornato o l’indirizzo del guest cambia.