El ping al teu parell de túnel IPv6 falla? Comprova l'adreça ::

Un extrem del vostre túnel IPv6 fa ping a l'altre, i només una direcció respon mai. La interfície està activa, la ruta sembla correcta i res del registre ho explica. L'adreça que heu assignat és l'adreça anycast del router de subxarxa, que no és cap adreça de host, i en un enllaç de dos extrems té exactament un objectiu de lliurament: el remitent. Cap valor de temps d'espera ho arregla, perquè l'adreça no fa el que penseu.

El símptoma que assenyala l'adreça

Tots els host de l'enllaç responen excepte el que té l'identificador d'interfície tot a zero. Un paquet adreçat a aquesta forma es lliura per definició a un router de la subxarxa, així que en un túnel punt a punt torna a la màquina que l'ha enviat. Des de l'extrem llunyà es llegeix com un parell inabastable; des de l'extrem proper es llegeix com a silenci. Canvieu un altre identificador del mateix prefix i el símptoma desapareix sense cap altre canvi, i aquesta és la confirmació que cal obtenir abans de tocar rutes.

L'identificador tot a zero està reservat com a anycast

RFC 4291 conserva l'identificador d'interfície tot a zero com a adreça anycast del router de subxarxa, així que un /64 com ara 2001:db8:4a::/64 no conté cap host utilitzable a 2001:db8:4a::. La reserva es guanya el lloc: els anuncis de router i el descobriment de veïns adrecen aquesta forma, i un router respon pel prefix que serveix. Assignar aquest valor a un extrem de túnel dóna un paper de router a una fulla, i per això no torna res. Qualsevol altre identificador del prefix funciona com a host, així que la reparació sol ser un dígit.

Tracteu la reserva com un paper que no teniu dret a ocupar des d'un extrem de túnel, no com una raresa per rodejar amb una ruta.

Assigneu adreces de host i encamineu el prefix

Trieu ::1 i ::2 per als dos extrems, afegiu-ne una amb ip -6 addr add 2001:db8:4a::2/64 dev tun0, i després encamineu el prefix remot en lloc de provar d'adreçar-lo. Una ruta per a 2001:db8:4a::/64 pel túnel fa accessible l'altre costat; l'adreça sola només deixa la interfície local configurada.

Per a un túnel complet hi ha un tercer pas, una ruta per defecte per a unicast global a través del dispositiu, que és l'equivalent IPv6 d'enviar-ho tot al túnel. Si l'ometeu, IPv6 continua usant l'enllaç físic mentre IPv4 viatja dins del túnel, així que el host filtra precisament el trànsit que creíeu cobert. Confirmeu-ho amb ip -6 route get 2001:4860:4860::8888 i llegiu quin dispositiu indica en lloc de suposar la resposta.

El multicast es rebutja abans de l'encaminament

Android valida adreces i rutes per a VpnService.Builder mitjançant LinkAddress, i aquest constructor rebutja multicast de pla. Si li doneu un prefix multicast com a ruta, el resultat és un error de paràmetres LinkAddress dolents en lloc d'una ruta, que és una resposta de validació i no de xarxa. El rebuig coincideix amb el medi: un dispositiu tun punt a punt no té multicast de capa d'enllaç, així que una ruta de grup no té cap model de lliurament per instal·lar. Les adreces de grup les crea i les consumeix la mateixa pila, no es configuren a mà.

Les adreces IPv6 all-nodes i solicited-node cauen sota la mateixa regla. La interfície les porta perquè la pila les hi ha posat, no perquè una política les volgués.

Què pot portar un túnel en lloc d'això

Moure el descobriment multicast per un túnel necessita una capa que entengui la pertinença a grups: un pont TAP que presenti un segment Ethernet, un relé a nivell d'aplicació o un protocol d'encaminament al qual es digui explícitament a quins parells replicar. Res d'això no existeix al model VpnService, on l'aplicació llegeix i escriu paquets i no té cap crida que uneixi un grup per al túnel. O afegiu el component que entén els grups o traieu el requisit del disseny.

Unicast, en canvi, no necessita res més enllà de les adreces i rutes anteriors, i per això normalment s'espera que els túnels el portin i després se'ls culpa quan falla un protocol de descobriment.

Tres comprovacions abans d'assignar qualsevol cosa

Confirmeu que l'adreça no és la forma anycast, confirmeu que no és multicast i confirmeu que el prefix està encaminat i no només assignat al dispositiu. Aleshores envieu la prova a una destinació que sigui un host real, perquè un ping dirigit a l'adreça anycast mesura el remitent i no diu res del camí. Guardeu aquestes tres comprovacions al registre de canvis perquè el proper desplegament no les torni a descobrir.

Una ruta que la plataforma no ha instal·lat mai no es pot depurar esperant més estona, i una adreça que mai no ha estat host no es pot reparar amb un ping millor.