O ping ao teu par de túnel IPv6 falla? Comproba o enderezo ::

Un extremo do teu túnel IPv6 fai ping ao outro, e só unha dirección responde algunha vez. A interface está activa, a ruta parece correcta e nada no rexistro o explica. O enderezo que asignaches é o enderezo anycast do router de subrede, que non é en absoluto un enderezo de host, e nunha ligazón de dous extremos ten exactamente un destino de entrega: o emisor. Ningún valor de tempo de espera o arranxa, porque o enderezo non fai o que cres.

O síntoma que apunta ao enderezo

Todos os hosts da ligazón responden agás o que ten o identificador de interface todo a ceros. Un paquete dirixido a esa forma entrégase por definición a un router da subrede, así que nun túnel punto a punto volve á máquina que o enviou. Desde o extremo afastado lese como un par inalcanzable; desde o extremo próximo lese como silencio. Cambia outro identificador do mesmo prefixo e o síntoma desaparece sen ningún outro cambio, e esa é a confirmación que hai que obter antes de tocar rutas.

O identificador todo a ceros está reservado como anycast

RFC 4291 conserva o identificador de interface todo a ceros como o enderezo anycast do router de subrede, así que un /64 como 2001:db8:4a::/64 non contén ningún host utilizábel en 2001:db8:4a::. A reserva gaña o seu sitio: os anuncios de router e o descubrimento de veciños diríxense a esa forma, e un router responde polo prefixo que serve. Asignar ese valor a un extremo de túnel dálle un papel de router a unha folla, e por iso non volve nada. Calquera outro identificador do prefixo funciona como host, así que a reparación adoita ser un díxito.

Trata a reserva como un papel que non tes dereito a ocupar desde un extremo de túnel, non como unha rareza que rodear cunha ruta.

Asigna enderezos de host e encamiña o prefixo

Escolle ::1 e ::2 para os dous extremos, engade un con ip -6 addr add 2001:db8:4a::2/64 dev tun0, e despois encamiña o prefixo remoto en lugar de tentar endereitalo. Unha ruta para 2001:db8:4a::/64 polo túnel fai accesíbel o lado afastado; o enderezo só deixa configurada a interface local.

Para un túnel completo hai un terceiro paso, unha ruta por defecto para unicast global a través do dispositivo, que é o equivalente IPv6 de envialo todo ao túnel. Se o omites, IPv6 segue usando a ligazón física mentres IPv4 viaxa dentro do túnel, así que o host filtra precisamente o tráfico que crías cuberto. Confírmao con ip -6 route get 2001:4860:4860::8888 e le cal dispositivo nomea en lugar de supor a resposta.

O multicast rexéitase antes do encamiñamento

Android valida enderezos e rutas para VpnService.Builder mediante LinkAddress, e ese construtor rexeita multicast de plano. Dálle un prefixo multicast como ruta e o resultado é un fallo de parámetros LinkAddress incorrectos en lugar dunha ruta, que é unha resposta de validación e non de rede. O rexeitamento encaixa co medio: un dispositivo tun punto a punto non ten multicast de capa de ligazón, así que unha ruta de grupo sobre el non ten modelo de entrega que instalar. Os enderezos de grupo créaos e consúmeos a propia pila en lugar de configurarse a man.

Os enderezos IPv6 all-nodes e solicited-node caen baixo a mesma regra. A interface lévaos porque a pila os puxo alí, non porque unha política os pretendese.

Que pode levar un túnel no seu lugar

Mover o descubrimento multicast por un túnel necesita unha capa que entenda a pertenza a grupos: unha ponte TAP que presente un segmento Ethernet, un relé a nivel de aplicación ou un protocolo de encamiñamento ao que se lle diga explicitamente a que pares replicar. Nada diso existe no modelo VpnService, onde a aplicación le e escribe paquetes e non ten chamada que se una a un grupo para o túnel. Ou engades o compoñente que entende grupos ou quitas o requisito do deseño.

Unicast, en cambio, non necesita nada extra máis alá dos enderezos e rutas anteriores, e por iso adoita esperarse que os túneles o leven e logo se lles bota a culpa cando falla un protocolo de descubrimento.

Tres comprobacións antes de asignar calquera cousa

Confirma que o enderezo non é a forma anycast, confirma que non é multicast e confirma que o prefixo está encamiñado e non só asignado ao dispositivo. Despois envía a túa proba a un destino que sexa un host real, porque un ping dirixido ao enderezo anycast mide o emisor e non di nada do camiño. Garda esas tres comprobacións no rexistro de cambios para que o seguinte despregamento non as redescubra.

Unha ruta que a plataforma nunca instalou non se pode depurar esperando máis tempo, e un enderezo que nunca foi un host non se pode reparar cun ping mellor.