Disattivare IPv6 per correggere una fuga VPN? Meglio decidere la politica

Un indirizzo dell'intervallo IPv6 compare in una pagina di test, il tunnel chiaramente non lo trasporta, e il consiglio più popolare su internet è disattivare IPv6 ovunque. Quel comando fa davvero tacere il pannello. Rimuove però anche un protocollo da cui la rete di accesso può dipendere, e vi lascia senza idea se l'indirizzo fosse una fuga reale, un indirizzo di interfaccia link-local o un resolver che fa il suo lavoro. Tre condizioni decidono il controllo giusto, e solo una porta al blocco.

Identificate che cosa ha misurato davvero lo strumento

Il falso allarme più comune è un indirizzo link-local, che inizia con fe80: ed esiste su ogni interfaccia compatibile IPv6, che la macchina raggiunga internet via IPv6 o no. Compare negli elenchi delle interfacce e in alcune diagnostiche applicative, e non dice nulla sul percorso del vostro traffico.

Il secondo falso allarme è un indirizzo locale unico in fc00::/7, che è un intervallo privato usato all'interno di una rete. Uno strumento che stampa ogni indirizzo dell'host lo elencherà volentieri accanto a quello pubblico. Chi legge in fretta lo chiama fuga e poi passa un'ora su un problema che non esiste.

Il terzo non è affatto un falso allarme. Un indirizzo globale che raggiunge internet fuori dal tunnel è la fuga reale, e vale la pena misurarla prima di decidere qualsiasi cosa:

ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co

Se il primo comando stampa un indirizzo globale e il terzo restituisce un indirizzo IPv6 pubblico che non è quello del tunnel, avete un percorso reale fuori dal tunnel. Se il primo non stampa altro che voci link-local, non c'è mai stata una fuga da correggere.

Tre condizioni decidono il controllo

La decisione non è "IPv6 buono" o "IPv6 cattivo". È in quale di tre situazioni vi trovate, e ciascuna ha una risposta corretta diversa con un costo diverso se sbagliate.

La prima riga è quello che la gente intende di solito, ed è legittima. Un client la cui uscita non supporta IPv6 non dovrebbe lasciar uscire in silenzio il traffico IPv6 nativo dell'host, perché quella è la fuga documentata a doppio stack. Il punto è bloccarla come politica dichiarata, non disattivare un protocollo nel kernel. Il risultato visibile è identico e solo uno dei due può essere riesaminato dopo.

La terza riga è dove il consiglio generale diventa attivamente dannoso. Gli operatori mobili e alcune connessioni domestiche gestiscono reti IPv6-only con traduzione per destinazioni IPv4. Togliete IPv6 lì e togliete l'unico trasporto che la rete offre, il che produce un'interruzione molto peggiore di quella che stavate depurando.

Se l'uscita non ha IPv6, bloccatelo di proposito

Preferite il meccanismo del client stesso, perché si applica esattamente finché il tunnel è attivo e si annulla quando cade. OpenVPN ha un'opzione per questo, e iptables ha una regola equivalente per gli altri client:

block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachable

La direttiva appartiene al profilo; la regola appartiene a un firewall che potete riesaminare e rimuovere. Entrambe falliscono chiuse, che è ciò che volete, ed entrambe sono visibili in un diff di configurazione, cosa che un sysctl del kernel sepolto in uno script di avvio non è.

Annotate perché c'è. Una regola di blocco senza commento viene rimossa dalla persona successiva che ha bisogno di IPv6 per qualcos'altro, e poi la fuga torna in silenzio.

Se l'uscita trasporta IPv6, instradatelo e provate entrambe le famiglie

Trasportare IPv6 è la risposta migliore quando il server lo supporta, e non è molto più difficile. Il requisito è che l'interfaccia del tunnel abbia un indirizzo in quella famiglia e che la rotta predefinita vi punti dentro il tunnel e non fuori dall'interfaccia fisica:

ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.co

La ricerca della rotta è il test decisivo: se nomina l'interfaccia del tunnel, il traffico IPv6 viene trasportato. Le due chiamate curl confermano poi cosa vede ciascuna famiglia, e confrontarle è il modo per dimostrare che entrambi i percorsi ora escono dalla stessa uscita.

Non fermatevi a una connessione riuscita. Riconnettete il tunnel e controllate di nuovo, perché una rotta IPv6 spinta può andare persa al ristabilimento se il server la invia solo nella configurazione iniziale. Poi controllate una destinazione esclusa, perché le regole di tunnel diviso sono dove le due famiglie più spesso divergono.

Se la rete di accesso è solo IPv6, lasciatela stare

Alcune reti offrono solo IPv6 e si aspettano che il dispositivo raggiunga i servizi IPv4 tramite un meccanismo di traduzione lato operatore. Disattivare IPv6 su una macchina così non è un miglioramento della sicurezza; elimina l'unica rotta verso qualunque cosa. È un'interruzione autoinflitta al servizio di un risultato di test di cui nessuno aveva bisogno.

Il sintomo di sbagliare qui è inconfondibile e sgradevole: il tunnel sembra stabilirsi, la risoluzione dei nomi funziona e non si carica nulla. Se lo vedete dopo un cambio IPv6, ripristinate l'impostazione subito e proseguite la diagnosi altrove.

Qualunque cosa scegliate, tenete la decisione esplicita nel profilo o nel firewall, legatela a ciò che l'uscita supporta davvero, e annotate il comportamento a doppio stack che descrive la discussione sul doppio stack del RFC 7359 . Un blocco dichiarato è una politica. Un protocollo disattivato è una scorciatoia che nessuno può verificare, e dalla pagina di test sembrano identici.