VPN dual-stack: è il client a scegliere la famiglia di indirizzi, non voi

Il tunnel è attivo, i siti IPv4 si caricano e un nome host va in timeout. La conclusione immediata è che la VPN è rotta o che le credenziali sono sbagliate, e di solito nessuna delle due cose è vera. Il nome ha restituito sia un indirizzo IPv4 sia uno IPv6, l'applicazione ne ha scelto uno, e solo uno di quei candidati aveva un percorso funzionante. È stato il client a prendere la decisione di selezione; il tunnel semplicemente non copriva ciò che aveva selezionato.

Scegliere non è promettere copertura

La selezione dell'indirizzo predefinita, descritta nella RFC 6724, decide quale coppia di origine e destinazione un host preferisce quando ne sono disponibili diverse. Happy Eyeballs aggiunge sopra una strategia di connessione: avvia tentativi su entrambe le famiglie e mantiene quella che risponde per prima, così l'utente non aspetta che una famiglia rotta vada in timeout.

Nessuno dei due meccanismi crea una rotta. Se il tunnel trasporta solo IPv4, un candidato AAAA resta una destinazione legittima che il client può provare, e il guasto si presenta come un caricamento lento anziché come un errore, perché il browser è ripiegato. L'utente segnala un sito lento, non rotto, e il ticket di supporto eredita questa vaghezza. Riproducetelo con una famiglia fissa e il rapporto diventa specifico.

È quel ripiego a rendere il sintomo incoerente tra le applicazioni. Un browser nasconde il ritardo; un client a riga di comando con una famiglia fissa vi mostra subito il guasto reale.

Trovate la famiglia che la richiesta ha davvero usato

Cominciate dal nome, non dal tunnel. Interrogate entrambi i tipi di record e annotate cosa è tornato:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

Se la richiesta v4 riesce e la v6 fallisce, avete riprodotto il problema in una forma che potete debuggare. Se entrambe riescono dalla shell e il browser continua a fallire, guardate il resolver dell'applicazione o una risposta in cache prima di toccare il tunnel.

Tenete la famiglia e la destinazione nelle vostre note. Un ticket che dice che il sito non si carica via VPN non può essere verificato da nessuno, mentre un ticket che dice che AAAA fallisce e A funziona indica una rotta precisa.

Controllate la rotta per quella famiglia

Per la famiglia che fallisce, chiedete al kernel quale percorso userebbe e confrontatelo con gli indirizzi configurati del tunnel. Su Linux, ip -6 route get per la destinazione mostra l'interfaccia e la sorgente che verrebbero scelte.

Poi controllate il tunnel stesso. I peer WireGuard portano una lista di IP consentiti, e una voce per 0.0.0.0/0 non dice nulla sull'IPv6. Se la lista del peer non ha alcun prefisso IPv6, il client non ha motivo di inviare traffico AAAA nel tunnel, e il pacchetto esce per ciò che l'host farebbe altrimenti.

Le regole del firewall e la politica NAT meritano lo stesso controllo per famiglia. Una regola scritta per IPv4 non copre l'IPv6 su nessuna piattaforma, ed è la ragione più comune per cui una famiglia funziona e l'altra no.

Non disattivate l'IPv6 per semplificare lo screenshot

Disattivare l'IPv6 a livello di sistema farà sparire il sintomo e vi lascerà senza diagnosi. Rompe anche qualsiasi destinazione che sia solo IPv6, e nasconde lo stesso bug per l'applicazione successiva. Se una macchina davvero non dovesse usare l'IPv6, quella è una politica deliberata con un proprietario e un test. Disattivarlo durante un incidente non è né l'una né l'altra.

Decidete cosa deve fare il client con la famiglia e configuratelo esplicitamente: trasportatela attraverso il tunnel, oppure bloccatela in un modo supportato, così che la selezione non offra mai un candidato irraggiungibile. Entrambi sono progetti legittimi. Una disattivazione globale non è nessuno dei due, perché non è affatto un progetto.

Cosa mettere nel ticket

Annotate quattro cose: il nome host, la famiglia che ha fallito, la rotta scelta dal kernel e il risultato di una richiesta specifica per la famiglia. Quell'insieme basta a qualcun altro per riprodurre il guasto senza indovinare quale dei due percorsi intendevate.

Le regole di selezione degli indirizzi della RFC 6724 spiegano perché il client ha preferito il candidato che ha preferito, e la RFC 8305 spiega il comportamento di corsa che ha nascosto il ritardo. Nessuna delle due instraderà un pacchetto per voi, ed è la parte che il tunnel deve fare.