Il traffico IPv6 fuori dalla VPN: trovare la rotta che perde

Due pagine di prova non concordano: una riporta l’indirizzo del fornitore attraverso il tunnel, la seconda riporta il tuo prefisso di casa, e la conclusione ovvia è che la VPN perde. Quella conclusione salta un passaggio, perché i due rapporti hanno esercitato due diverse decisioni di instradamento e solo una doveva entrare nel tunnel. Il buco di solito è reale, ed è un problema di copertura, non un tunnel rotto. Tre domande lo risolvono: quale flusso è davvero uscito, quale rotta il kernel ha scelto per esso, e quale comportamento il client intendeva.

Lavora in quell’ordine. Rispondere fuori ordine produce una lunga discussione se il client sia difettoso, quando la risposta vera è che non è mai stata installata una rotta IPv6.

Quale flusso è davvero uscito, e su quale scheda di rete

Inizia con una prova che nomini la famiglia usata, poi annota l’applicazione, la rete di accesso, il profilo in vigore e se la connessione offra IPv6. Quei quattro fatti rendono confrontabili due esecuzioni, e il quarto è quello che si dimentica: una rete senza prefisso v6 non può perdere v6, e una rete che ne aggiunge uno più tardi cambia la risposta.

Invia una richiesta per famiglia invece di caricare una pagina e leggerne il risultato. Una singola pagina può mescolare risorse v6 e v4, un processo in background può comportarsi diversamente dalla scheda davanti a te, e una risposta in cache può sopravvivere al cambio di rete che stai cercando di verificare. Fissa la destinazione che verifichi e annotala, così un’esecuzione ripetuta misura la stessa cosa.

Leggere la rotta scelta dal kernel

La tabella di instradamento risponde alla domanda che il browser non può. Chiedi al sistema dove andrebbe una destinazione precisa, e includi sia le regole di policy sia la rotta predefinita visibile, perché entrambe possono sovrascriverla:

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

Un prefisso più specifico è la ragione abituale per cui una destinazione resta fuori dal tunnel mentre tutto il resto resta dentro, e una regola di policy può fare lo stesso con priorità più alta di qualunque rotta. Leggi anche la metrica, perché due voci per lo stesso prefisso si risolvono per metrica e non per il loro ordine sullo schermo. Su Windows l’elenco equivalente è Get-NetRoute -AddressFamily IPv6, ordinato per metrica per corrispondere all’ordine di decisione. Una regola che nella tabella sembra corretta può comunque perdere contro una regola di policy con numero più basso, per questo l’elenco delle regole va nello stesso respiro dell’elenco delle rotte.

Da dove viene la policy IPv6 del client

Un client può essere costruito per portare il v6 attraverso il tunnel, per rifiutarlo o per consentire un’eccezione nominata, e queste tre intenzioni danno tre risultati corretti diversi. Leggi il profilo e la documentazione del client stesso prima di chiamare perdita un’osservazione, perché un client che blocca il v6 mentre il sistema operativo invia ancora la scoperta dei vicini sul collegamento fisico si comporta come previsto.

Un’applicazione deliberatamente esclusa dal tunnel è un caso diverso da una famiglia che il tunnel non ha mai trasportato. La prima è una decisione su un programma, la seconda è un buco di copertura, e la riparazione differisce di conseguenza. Leggi l’elenco dei programmi esclusi del client prima di cercare una rotta che non avrebbe mai dovuto esistere.

Osservazione mirata, quando la tabella non concorda

Quando la ricerca della rotta è ambigua, una sola osservazione dell’interfaccia sull’host può risolverla, ma solo se è puntata sulla domanda. Il traffico verso l’endpoint della VPN stessa attraverserà la scheda fisica per progetto; ciò che conta è se il flusso dell’applicazione, indirizzato altrove del tutto, compare anch’esso lì. Filtra la cattura sulla destinazione che verifichi invece di raccogliere tutto.

Una cattura ampia espone molto più traffico personale di quanto richieda l’unica domanda. Risponde anche con minore chiarezza, perché il flusso che ti interessa arriva sepolto in un torrente di connessioni non correlate. Filtra sulla destinazione verificata, fermati dopo una manciata di pacchetti ed elimina la cattura.

Tre modi per chiudere il buco

Porta la famiglia attraverso il tunnel, bloccala nel client quando il tunnel non può trasportarla, oppure registra un’eccezione deliberata con un responsabile e una data di revisione. Ognuna è difendibile, e l’unica cosa non difendibile è lasciare la scelta implicita, perché una scelta implicita è esattamente ciò che la perdita è. Se il tunnel non ha alcuna uscita v6, rifiutare il v6 nel client è sia onesto sia verificabile. Ciò che conta è che la scelta sia scritta dove la persona successiva la troverà, non dedotta dal comportamento sei mesi dopo.

Ripeti il controllo dopo una riconnessione e dopo esserti spostato tra reti, perché una rotta installata per il collegamento precedente può sopravvivere al cambiamento. Poi annota la destinazione, la rotta selezionata, la policy del client e la famiglia usata dalla prova, così la persona successiva legge una decisione invece di ricavarla di nuovo. RFC 7359 documenta la perdita dual-stack come problema di progettazione e non come bug, ed è il riferimento da citare quando qualcuno sostiene che un tunnel v4 funzionante copra tutto.