O tráfico IPv6 fóra da VPN: atopar a ruta que gotea

Dúas páxinas de proba non coinciden: unha informa do enderezo do provedor a través do túnel, a segunda informa do teu prefixo doméstico, e a conclusión obvia é que a VPN gotea. Esa conclusión salta un paso, porque os dous informes exerceron dúas decisións de encamiñamento distintas e só unha delas debía entrar no túnel. O oco adoita ser real, e é un problema de cobertura e non un túnel roto. Tres preguntas o resolven: que fluxo saíu realmente, que ruta escolleu o núcleo para el e que comportamento pretendía o cliente.

Traballa nesa orde. Respondelas fóra de orde produce unha longa discusión sobre se o cliente é defectuoso cando a resposta real é que nunca se instalou unha ruta IPv6.

Que fluxo saíu realmente e por que adaptador

Comeza cunha proba que nomee a familia que usou, e logo anota a aplicación, a rede de acceso, o perfil vixente e se a conexión ofrece IPv6 sequera. Eses catro feitos son o que fai comparables dúas execucións, e o cuarto é o que a xente esquece: unha rede sen prefixo v6 non pode gotear v6, e unha rede que engade un despois cambia a resposta.

Envía unha petición por familia en lugar de cargar unha páxina e ler o seu resultado. Unha soa páxina pode mesturar recursos v6 e v4, un proceso en segundo plano pode comportarse distinto da pestana que tes diante, e unha resposta na caché pode sobrevivir ao cambio de rede que intentas probar. Fixa o destino que probas e anótao, para que unha repetición mida o mesmo.

Ler a ruta que escolleu o núcleo

A táboa de rutas responde a pregunta que o navegador non pode. Pregunta ao sistema a onde iría un destino concreto, e inclúe tanto as regras de política como a ruta por defecto visible, porque calquera das dúas pode anulala:

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

Un prefixo máis específico é a razón habitual de que un destino quede fóra do túnel mentres todo o demais permanece dentro, e unha regra de política pode facer o mesmo cunha prioridade maior ca calquera ruta. Le tamén a métrica, xa que dúas entradas para o mesmo prefixo resólvense pola métrica e non pola súa orde na pantalla. En Windows a listaxe equivalente é Get-NetRoute -AddressFamily IPv6, ordenada por métrica para coincidir coa orde de decisión. Unha regra que parece correcta na táboa pode perder aínda contra unha regra de política cun número máis baixo, e por iso a listaxe de regras pertence á mesma ollada ca a listaxe de rutas.

De onde vén a política IPv6 do cliente

Un cliente pode estar construído para levar v6 polo túnel, para rexeitalo ou para permitir unha excepción con nome, e esas tres intencións producen tres resultados correctos distintos. Le o perfil e a documentación do propio cliente antes de chamarlle fuga a unha observación, porque un cliente que bloquea v6 mentres o sistema operativo aínda envía descuberta de veciños pola ligazón física compórtase como se deseñou.

Unha aplicación excluída deliberadamente do túnel é un caso distinto dunha familia que o túnel nunca transportou. O primeiro é unha decisión sobre un programa, o segundo é un oco na cobertura, e a reparación difire en consecuencia. Le a listaxe de programas excluídos do cliente antes de buscar unha ruta que nunca debería existir.

Observación estreita, cando a táboa non concorda

Cando a consulta de ruta é ambigua, unha observación de interface no equipo pode resolvelo, pero só se apunta á pregunta. O tráfico cara ao propio extremo da VPN cruzará o adaptador físico por deseño; o que importa é se o fluxo da aplicación, dirixido a outro lugar por completo, aparece tamén alí. Filtra a captura ao destino que probas en lugar de recollelo todo.

Unha captura ampla expón moito máis tráfico persoal do que require a única pregunta. Tamén responde a pregunta con menos claridade, porque o fluxo que che importa chega enterrado nun torrente de conexións non relacionadas. Filtra ao destino probado, detente tras un puñado de paquetes e borra a captura.

Tres formas de pechar o oco

Leva a familia polo túnel, bloquéaa no cliente cando o túnel non poida transportala, ou rexistra unha excepción deliberada cun responsable e unha data de revisión. Cada unha é defendible, e o único indefendible é deixar a elección implícita, porque unha elección implícita é exactamente o que é a fuga. Se o túnel non ten saída v6 algunha, rexeitar v6 no cliente é á vez honesto e comprobable. O que importa é que a elección quede escrita onde a seguinte persoa a atope, non inferida do comportamento seis meses despois.

Repite a comprobación tras unha reconexión e tras cambiar de rede, xa que unha ruta instalada para a ligazón anterior pode sobrevivir ao cambio. Despois anota o destino, a ruta seleccionada, a política do cliente e a familia que usou a proba, para que a seguinte persoa lea unha decisión en vez de volver deducila. RFC 7359 documenta a fuga de dobre pila como un problema de deseño e non como un erro, e é a referencia que citar cando alguén afirma que un túnel v4 que funciona o cobre todo.