Il proxy di debug diventa cieco quando si connette la VPN aziendale

Lo strumento di cattura funziona tutta la mattina, il tunnel si connette e lui tace. Disconnetti e riparte. L’istinto dice che la VPN ha rotto il proxy, ma nella configurazione del proxy non è cambiato nulla. Quello che è cambiato è quale configurazione leggono ora le applicazioni: una voce del tunnel può portare le proprie impostazioni proxy, un profilo gestito può riattivare la configurazione automatica e alcuni runtime leggono solo una parte di ciò che il sistema operativo offre. Leggi il valore per connessione prima di toccare quello globale.

Windows tiene un proxy per connessione

Nelle opzioni Internet ci sono due livelli che nella finestra sembrano identici. Le impostazioni della rete locale valgono per la normale connessione locale, mentre una voce di connessione remota o VPN tiene la propria copia sotto HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections, salvata come valore binario. Scrivere i noti valori globali del registro non aggiorna quella copia.

È esattamente così che uno strumento si comporta correttamente prima della connessione e scorrettamente dopo, senza alcun cambiamento visibile nelle sue impostazioni. La finestra che fissavi era il pannello della rete locale. Era corretta, ed era irrilevante. La voce che Windows usava davvero era quella creata per il tunnel.

Il modo supportato per cambiare una voce è l’API delle opzioni di connessione WinINET: compila un INTERNET_PER_CONN_OPTION_LIST con il nome della connessione, i flag, il server proxy e una lista di esclusione, applicalo e poi aggiorna. Per un controllo rapido, apri la finestra di impostazioni della voce del tunnel e confronta il suo pannello proxy con quello della rete locale; la differenza di solito è evidente appena sai dove guardare.

Un PAC gestito può riaccendersi da solo

In macOS lo script di configurazione automatica del proxy e il rilevamento automatico del proxy sono proprietà di un servizio di rete, non della macchina. Un profilo di configurazione può imporli, quindi ricompaiono dopo che li deselezioni, e ogni richiesta viene allora inviata al proxy scelto dallo script.

Ispeziona e, se sei autorizzato, disattiva quei due interruttori per il servizio che porta il traffico:

networksetup -setautoproxystate "Wi-Fi" off
networksetup -setproxyautodiscovery "Wi-Fi" off
scutil --proxy

Usa il vero nome del servizio invece di un’ipotesi. Un portatile con Wi-Fi e adattatore Ethernet USB ne ha due, e solo uno porta il tuo traffico. scutil --proxy stampa i valori per il servizio principale attuale. Confronta quell’output con quello che hai modificato prima di concludere che il profilo ha vinto.

Punta lo strumento al vero upstream

Se lo script contiene il proxy aziendale, leggilo e inserisci lo stesso indirizzo come proxy esterno dentro lo strumento di cattura. Allora lo strumento inoltra al vero upstream, che è ciò che il proxy aziendale si aspetta, e resta nel percorso della richiesta invece di combattere la policy.

È la mossa che ti tiene a fare debug invece di riconfigurare.

Spingi il proxy dentro il tunnel

Un client basato su OpenVPN può accettare opzioni proxy che valgono una volta che il tunnel è attivo, cosa comoda quando il client possiede le rotte:

dhcp-option HTTPPROXY 127.0.0.1:8888
dhcp-option HTTPSPROXY 127.0.0.1:8888

Solo i client che rispettano l’opzione la useranno, e questa fissa la tua porta di ascolto dentro un profilo. Trattala come una comodità da laboratorio e non come uno standard di distribuzione, perché il prossimo invio di profilo la rimuoverà.

Alcuni client non leggono mai il proxy di sistema

Firefox tiene le proprie impostazioni proxy, per questo a volte continua a catturare quando un browser con proxy di sistema non lo fa. Un vecchio client .NET che non capisce la configurazione automatica si connette direttamente ovunque venga eseguito, quindi una pagina caricata tramite la voce del tunnel può comunque fallire dentro l’applicazione.

Anche gli strumenti di rete hanno le loro cause. Una sessione FTP che si blocca attraverso un tunnel o un tethering del telefono è spesso un problema di modalità attiva contro passiva negoziato dal client, e nessuna impostazione proxy lo cambierà.

Leggi la configurazione, non l’interruttore

Lavora in questo ordine: il valore proxy proprio della voce del tunnel, lo stato PAC e di rilevamento automatico per servizio, poi la gestione del proxy da parte dell’applicazione stessa. Fermati al primo che differisce da ciò che supponevi.

Ogni caso qui è un problema di precedenza della configurazione. Nessuno è il tunnel che rompe il tuo strumento.