VPN connessa ma l'indirizzo IP non è cambiato: perché

Ti connetti, il client dice connesso e il test dell'indirizzo mostra ancora lo stesso numero di prima. L'indicatore non ha nulla di guasto; qualcosa tra il profilo e l'applicazione ha tenuto quella richiesta fuori dal tunnel. Decidi quale di tre cose stai guardando prima di toccare qualsiasi configurazione: un test che non ha mai misurato l'indirizzo pubblico, un tunnel che copre solo una parte del traffico, o un secondo percorso che vince la decisione di routing. Ognuna ha un controllo che dura meno di un minuto.

Conferma cosa ha misurato davvero il test

L'indirizzo mostrato nella finestra Wi-Fi o Ethernet è quello dell'interfaccia nel tuo segmento, non quello che vede un sito web, quindi può restare identico mentre il tunnel funziona perfettamente. La posizione è di nuovo un segnale separato: una regione dell'account salvata o una lettura di geolocalizzazione consentita non si sposta quando cambi uscita, e nemmeno un accesso che ti riconosce già.

Usa un echo dell'indirizzo pubblico e interroga ogni famiglia separatamente, perché un risultato di test a doppio stack nasconde il caso interessante:

curl -4 -s https://ifconfig.me
curl -6 -s https://ifconfig.me

Esegui entrambi prima e dopo la connessione. Se la risposta IPv4 passa all'indirizzo di uscita e quella IPv6 no, non hai un tunnel rotto; hai una famiglia che viaggia fuori. Se entrambe le risposte restano uguali, la richiesta non ha mai raggiunto il tunnel e il resto di questo vale.

Il profilo può coprire solo una parte del traffico

Un profilo a tunnel diviso è la risposta comune e non è un difetto. OpenVPN fa passare tutto dal tunnel solo quando redirect-gateway è tra le opzioni inviate; senza di esso il client riceve una manciata di rotte specifiche e la tua rotta predefinita resta sul collegamento fisico. Su Windows lo stesso interruttore appare come «Usa gateway predefinito sulla rete remota» nelle proprietà IPv4 dell'adattatore, e deselezionarlo è una scelta deliberata che sopravvive a ogni riconnessione.

L'ambito per applicazione è il secondo strato. L'impostazione VPN per app di Android decide quali app sono incluse, quindi la chiave VPN nella barra di stato non dimostra che il browser sia dentro. Un'estensione del browser che fa da proxy al proprio traffico crea l'immagine speculare: il browser mostra l'indirizzo di uscita mentre un client di posta o un gioco sulla stessa macchina mostra ancora il tuo. Confronta la stessa richiesta in due applicazioni. Se una cambia e l'altra no, stai guardando l'ambito, non un tunnel che fallisce.

Una famiglia di indirizzi può ancora andare diretta

La maggior parte dei profili VPN è stata scritta per IPv4, e molti lo sono ancora. Su una rete a doppio stack il tunnel prende 10.8.0.x per IPv4 mentre il collegamento fisico conserva un indirizzo IPv6 globale e una rotta predefinita, quindi un sito compatibile IPv6 viene raggiunto direttamente e l'indirizzo che riporta è quello del tuo fornitore. È una fuga con un tunnel IPv4 funzionante, ed è invisibile a un test che parla solo IPv4.

ip -4 route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Leggi l'interfaccia in ogni risposta. Se la ricerca IPv6 nomina il tuo dispositivo Ethernet o Wi-Fi mentre la ricerca IPv4 nomina il tunnel, la politica per quella famiglia manca invece di essere rotta. Spegnere IPv6 su tutto il dispositivo fa sparire il sintomo e nasconde la decisione; preferisci correggere la copertura del profilo o disattivare la famiglia solo su quella connessione, e annota quale delle due hai scelto.

Un secondo percorso può vincere la ricerca

Un proxy concorrente, un secondo client VPN, un adattatore virtuale di un container o di uno strumento desktop remoto, o una rotta extra per il prefisso esatto che stai testando possono tutti avere la precedenza. Una rotta specifica batte sempre una predefinita, quindi un /24 residuo per il sito che misuri, puntato al tuo gateway LAN, continua a mandare quel traffico fuori dal tunnel per quanto sano sia il tunnel.

Fai un inventario prima di cambiare qualcosa, con comandi di sola lettura:

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
nmcli connection show --active

Cerca più di una rotta predefinita con una metrica plausibile, e una rotta specifica che copra la destinazione. Nel browser controlla anche se un'estensione proxy o l'impostazione proxy di sistema possiede la connessione; un'estensione può nominare il proprio upstream e lasciare intatta l'uscita del sistema operativo, il che produce un indirizzo diverso nel browser rispetto a un terminale sulla stessa macchina.

Misura di nuovo con una richiesta fresca

Riconnettiti, poi ripeti la misura dalla stessa applicazione con cui hai testato la prima volta, perché una pagina in cache o una connessione riutilizzata riporta lo stato vecchio. Osserva il log o la vista eventi del client durante la connessione: un errore nell'applicare le rotte dopo l'autenticazione è una prova più forte di qualsiasi indicatore, e di solito nomina la rotta o l'adattatore che ha fallito.

Tieni separati due esiti. Se l'indirizzo cambia ma un sito ti rifiuta ancora, il tunnel funziona e il sito rifiuta un indirizzo di datacenter; è un altro problema con un'altra risposta. Se l'indirizzo non cambia mai, affronta le quattro domande in ordine: quale indirizzo ha stampato il test, quale famiglia era, quale applicazione ha fatto la richiesta e quale rotta ha seguito quella richiesta. La documentazione Microsoft sulle decisioni di routing VPN spiega come un client Windows sceglie tra tunnel e adattatore fisico quando entrambi hanno una rotta.