IPv6 attraverso un server VPN IPv4 richiede comunque un’uscita IPv6

Il tunnel sale, il client riceve un indirizzo IPv6 dal pool e, ciononostante, ogni destinazione IPv6 va in timeout. Dentro il tunnel non c’è nulla di rotto: IPv6 viaggia benissimo nel trasporto IPv4, e questa non è mai stata la parte difficile. L’indirizzo che hai assegnato è una promessa che il server non può mantenere, perché l’uscita non ha alcun upstream IPv6 in cui inviarlo. La riparazione spetta all’uscita, non al profilo del client.

Il sintomo: un indirizzo e nessun percorso

Un controllo lato client mostra un indirizzo IPv6 dall’aspetto globale sul dispositivo di tunnel e una rotta che punta al suo interno, ed è per questo che viene letto erroneamente come un bug del client. Il traffico entra nel tunnel, il server lo decapsula, e poi il pacchetto atterra su un host la cui tabella di routing non ha alcuna rotta predefinita IPv6 verso un luogo reale. A seconda dello stack ottieni un irraggiungibile immediato o uno scarto silenzioso, e in entrambi i casi il client vede un timeout che sembra identico a un firewall.

Leggi la tabella di routing del server stesso prima di toccare il client, perché è lì che vive la metà mancante del percorso. Un server con una sola rotta predefinita IPv4 ti ha già dato la risposta.

Segui il pacchetto dopo la decapsulazione

Dentro il tunnel il pacchetto è IPv6 ordinario e la sua origine è l’indirizzo del client. Il server rimuove l’incapsulamento di trasporto e quindi tiene un pacchetto IPv6 nativo che deve essere inoltrato a un successivo hop IPv6. Una rotta predefinita IPv4 non può portarlo, e tradurlo in IPv4 è un’altra funzione che nessuno ha distribuito. È questa l’intera anomalia, e non ha nulla a che vedere con se il listener VPN ha risposto su IPv4.

La meccanica dell’incapsulamento IPv6 su IPv4 è descritta nella RFC 4213, e il dettaglio importante lì è che gli estremi hanno ancora bisogno di connettività IPv6 reale dall’altra parte del tunnel. Avvolgere un’intestazione non fa comparire un upstream.

Due livelli di tunnel, due controlli indipendenti

Verifica ogni livello separatamente, perché un tunnel esterno funzionante nasconde uno interno rotto. Controlla il percorso esterno con un ping IPv4 dal client al server e conferma la porta che usi. Poi controlla il percorso interno sul server, dove ip -6 route deve mostrare una rotta predefinita o una rotta specifica appresa da un upstream reale, e ip -6 addr deve mostrare un prefisso sorgente che l’upstream accetta. Qualsiasi cosa in meno è decorazione sull’interfaccia.

Un indirizzo unico-locale, o un prefisso dall’aspetto globale verso cui nulla instrada di ritorno, comparirà felicemente su un’interfaccia e non andrà da nessuna parte. La raggiungibilità pubblica è concessa dall’upstream, non dalla forma dell’indirizzo.

Lo stesso vale sul client: ip -6 route get 2001:4860:4860::8888 dovrebbe nominare il dispositivo di tunnel, e se nomina quello fisico, il client non sta affatto usando la VPN per IPv6.

Prefisso sorgente, dimensione e ICMPv6

Chiedi all’upstream quali prefissi sorgente accetterà per l’inoltro, e usane uno per il pool dei client. Un fornitore che ti dà un /64 per l’interfaccia del server stesso non necessariamente instrada verso di te un secondo /64 o un blocco più grande, e la differenza è un pomeriggio di debug che un ticket di supporto risolve con una domanda. Chiedilo per iscritto e conserva la risposta insieme alla configurazione.

Metti in budget l’incapsulamento extra che il tuo stack usa davvero, e mantieni ICMPv6 funzionante, incluso Packet Too Big. Una seconda intestazione riduce il carico utile, quindi un percorso che risponde a ping piccoli può comunque fallire su un trasferimento di file, e un firewall che scarta tutto ICMPv6 trasforma un problema di dimensione riparabile in un buco nero. Prova un trasferimento grande prima di annunciare il servizio.

Che cos’è un problema del tutto diverso

Raggiungere un’applicazione solo IPv4 da un client solo IPv6 è traduzione, non tunneling, e richiede qualcosa come una distribuzione deliberata di NAT64. La destinazione non capirà un’intestazione di tunnel in più solo perché ne hai aggiunta una. I servizi di transizione storici meritano la stessa cura: la RFC 7526 ha deprecato il modello di relay anycast 6to4, quindi una guida scritta attorno ad esso descrive qualcosa che non ha più un relay pubblico mantenuto.

Se il server non ha alcun upstream IPv6 utilizzabile, le scelte sono un upstream supportato, un’uscita diversa o una decisione documentata che IPv6 resti fuori dal tunnel. Ciò che non è accettabile è dire ai client che esiste un servizio IPv6 mentre la loro normale connessione IPv6 aggira silenziosamente la VPN.