Il ping al peer del tunnel IPv6 fallisce? Controlla l’indirizzo ::

Un’estremità del tuo tunnel IPv6 fa ping all’altra, e risponde sempre e solo una direzione. L’interfaccia è attiva, la rotta sembra corretta e nulla nel registro lo spiega. L’indirizzo che hai assegnato è l’indirizzo anycast del router di sottorete, che non è affatto un indirizzo di host, e su un collegamento a due estremità ha esattamente un obiettivo di consegna: il mittente. Nessun valore di timeout lo ripara, perché l’indirizzo non fa quello che credi.

Il sintomo che punta all’indirizzo

Tutti gli host del collegamento rispondono tranne quello il cui identificatore di interfaccia è tutto a zero. Un pacchetto indirizzato a quella forma viene consegnato per definizione a un router della sottorete, quindi su un tunnel punto a punto torna alla macchina che l’ha inviato. Dall’estremità lontana si legge come un peer irraggiungibile; dall’estremità vicina come silenzio. Sostituisci con un altro identificatore dello stesso prefisso e il sintomo sparisce senza altre modifiche, e questa è la conferma da ottenere prima di toccare le rotte.

L’identificatore tutto a zero è riservato come anycast

La RFC 4291 conserva l’identificatore di interfaccia tutto a zero come indirizzo anycast del router di sottorete, quindi un /64 come 2001:db8:4a::/64 non contiene alcun host utilizzabile a 2001:db8:4a::. La riserva merita il suo posto: gli annunci dei router e la scoperta dei vicini indirizzano quella forma, e un router risponde per il prefisso che serve. Assegnare quel valore a un’estremità di tunnel dà un ruolo di router a una foglia, ed è per questo che non torna nulla. Qualsiasi altro identificatore nel prefisso funziona come host, quindi la riparazione è di solito una cifra.

Tratta la riserva come un ruolo che non hai il diritto di occupare da un’estremità di tunnel, non come una stranezza da aggirare con una rotta.

Assegna indirizzi di host e instrada il prefisso

Scegli ::1 e ::2 per le due estremità, aggiungine uno con ip -6 addr add 2001:db8:4a::2/64 dev tun0, poi instrada il prefisso remoto invece di provare a indirizzarlo. Una rotta per 2001:db8:4a::/64 attraverso il tunnel rende raggiungibile il lato lontano; l’indirizzo da solo configura solo l’interfaccia locale.

Per un tunnel completo c’è un terzo passo, una rotta predefinita per l’unicast globale attraverso il dispositivo, che è l’equivalente IPv6 di mandare tutto nel tunnel. Se lo ometti, IPv6 continua a usare il collegamento fisico mentre IPv4 viaggia dentro il tunnel, quindi l’host perde proprio il traffico che credevi coperto. Conferma con ip -6 route get 2001:4860:4860::8888 e leggi quale dispositivo nomina invece di dare per scontata la risposta.

Il multicast viene rifiutato prima dell’instradamento

Android convalida indirizzi e rotte per VpnService.Builder tramite LinkAddress, e quel costruttore rifiuta il multicast di netto. Dagli un prefisso multicast come rotta e il risultato è un errore di parametri LinkAddress errati invece di una rotta, che è una risposta di convalida e non di rete. Il rifiuto corrisponde al mezzo: un dispositivo tun punto a punto non ha multicast a livello di collegamento, quindi una rotta di gruppo su di esso non ha alcun modello di consegna da installare. Gli indirizzi di gruppo sono creati e consumati dallo stack stesso invece di essere configurati a mano.

Gli indirizzi IPv6 all-nodes e solicited-node rientrano nella stessa regola. L’interfaccia li porta perché lo stack li ha messi lì, non perché una policy li intendesse.

Che cosa può portare un tunnel al posto loro

Spostare la scoperta multicast attraverso un tunnel richiede uno strato che comprenda l’appartenenza ai gruppi: un bridge TAP che presenti un segmento Ethernet, un relè a livello applicativo o un protocollo di instradamento a cui venga detto esplicitamente a quali peer replicare. Nulla di tutto ciò esiste nel modello VpnService, dove l’applicazione legge e scrive pacchetti e non ha alcuna chiamata che si unisca a un gruppo per il tunnel. O aggiungi il componente che comprende i gruppi o togli il requisito dal progetto.

L’unicast, al contrario, non richiede nulla in più rispetto agli indirizzi e alle rotte qui sopra, ed è per questo che di solito ci si aspetta che i tunnel lo portino e poi li si incolpa quando un protocollo di scoperta fallisce.

Tre controlli prima di assegnare qualsiasi cosa

Conferma che l’indirizzo non sia la forma anycast, conferma che non sia multicast e conferma che il prefisso sia instradato e non solo assegnato al dispositivo. Poi invia il tuo test a una destinazione che sia un host reale, perché un ping rivolto all’indirizzo anycast misura il mittente e non dice nulla sul percorso. Conserva questi tre controlli nel registro delle modifiche perché la prossima distribuzione non li riscopra.

Una rotta che la piattaforma non ha mai installato non si può fare debug aspettando più a lungo, e un indirizzo che non è mai stato un host non si può riparare con un ping migliore.