Una rete solo IPv6 rompe la VPN prima ancora che il tunnel parta

Il portatile si collega a un Wi-Fi di convegno che distribuisce solo IPv6, il client VPN gira e fallisce, e lo stesso profilo aveva funzionato in un hotel un’ora prima. Nelle credenziali non è cambiato nulla. Quello che è cambiato è che ora il client deve raggiungere una destinazione IPv4 attraverso una rete che trasporta solo IPv6, e non tutti i client sanno come farlo.

Percorrete gli stessi cinque passaggi che percorrono i pacchetti.

Passo 1: osservate la risoluzione del nome

Se il profilo usa un nome host, la prima domanda è cosa restituisce il resolver. dig AAAA vpn.example.com sulla rete solo IPv6 restituisce un vero record AAAA, uno sintetizzato da DNS64 oppure nulla. Una risposta sintetizzata codifica la destinazione IPv4 dentro un prefisso di traduzione, e solo allora un client senza destinazione IPv6 può raggiungerla. Un profilo con un indirizzo IPv4 codificato a mano non arriva mai fin qui, perché non c’è alcun nome da sintetizzare.

Questa sola differenza spiega la maggior parte dei rapporti «funziona là, fallisce qui», e basta un solo comando per vederla.

Passo 2: guardate quale famiglia ha chiamato il client

Guardate il socket invece della barra di avanzamento. Un client che apre un socket IPv4 verso un indirizzo IPv4 su un collegamento solo IPv6 non ha dove inviarlo, e il guasto si manifesta come timeout anziché come errore di nome. ss -tanp mentre il client si connette mostra l’indirizzo remoto e la famiglia tentata. Confrontatelo con ip -6 route per confermare che la rotta predefinita è un vero next hop IPv6.

La famiglia di indirizzi nella tabella dei socket è il fatto. La barra di avanzamento è un riassunto scritto da qualcun altro.

Passo 3: separate la traduzione dal tunnel

NAT64 e DNS64 sono il modo in cui la rete di accesso raggiunge le destinazioni IPv4, e non fanno nulla per il tunnel una volta che è su. Un tunnel instaurato su un percorso tradotto negozia comunque il proprio indirizzamento interno, e la copertura interna IPv4 o IPv6 è una questione di politica separata. Se il client si connette e poi non raggiunge nulla, siete oltre la traduzione e dentro l’instradamento, che è un’altra indagine con altre prove.

Il guasto della traduzione sembra non connettersi mai. Il guasto della copertura interna sembra connettersi e non raggiungere nulla.

Passo 4: provate lo stesso profilo su un’altra rete

Portate lo stesso profilo, la stessa versione del client e le stesse credenziali su una rete dual-stack e ripetete. Se là funziona e fallisce sul percorso solo IPv6, la variabile è la rete di accesso e non il profilo. Annotate la versione del client e lo stato della rete nel ticket, perché la soluzione finale è un aggiornamento del client o un’altra destinazione.

Un rapporto che dice che la VPN è rotta non è utilizzabile. Un rapporto che dice che fallisce solo in accesso solo IPv6 è un rapporto di bug.

Passo 5: correggete il percorso, non le impostazioni di sicurezza

Tutte le riparazioni tentatrici peggiorano le cose. Disattivare IPv6 elimina l’unico percorso offerto dalla rete. Puntare il client a un resolver pubblico rompe la sintesi DNS64, perché quella sintesi deve arrivare dal resolver dietro il traduttore. Disattivare la verifica dei certificati vi dà una connessione verso qualcosa che non potete identificare. Nessuna di queste è una riparazione, e due sono regressioni di sicurezza che sopravvivranno all’incidente.

Le opzioni reali sono un client che supporti il modello di traduzione di rete, oppure una destinazione con un indirizzo IPv6 raggiungibile. Chiedete una delle due.