IPv6 por un túnel OpenVPN: percorrido polo router da casa

O portátil ten un enderezo IPv6, o túnel está levantado sobre IPv4 e, aínda así, todas as probas IPv6 fallan. Ou peor: a proba sae ben e o tráfico saíu pola ruta do provedor sen entrar nunca no túnel. Ambos os resultados remiten a unha decisión que falta: ninguén deu ao router un prefixo que puidese encamiñar cara aos clientes. Percorrer o camiño desde o cliente cara a fóra descobre que peza falta.

Comeza onde está o cliente

Mira o cliente antes de tocar o servidor. ip -6 addr debería mostrar un enderezo de túnel do pool, e ip -6 route debería mostrar o prefixo empurrado que apunta ao dispositivo de túnel. Cando o enderezo está pero a ruta non, falta o push ou o cliente ignorouno. Cando non está ningunha das dúas, o servidor non asignou absolutamente nada.

Despois comproba que cre o cliente sobre o mundo exterior. Unha ruta por defecto polo túnel reclama todo o tráfico IPv6, mentres que unha ruta para 2000::/3 só reclama unicast global. Ambas poden ser correctas e responden preguntas distintas sobre as fugas.

Un cliente sen ningunha ruta por defecto IPv6 falla todas as probas públicas mentres o túnel está perfectamente san. Iso é un oco de política, non un túnel roto.

Comproba o pool que o servidor pode encamiñar de verdade

Un servidor só pode asignar dun prefixo que controla de verdade. Se o provedor delega un /56, reserva un /64 para o túnel e deixa o resto para a LAN. Cando o provedor entrega un só /64 na WAN e non encamiña nada máis, deixa o prefixo da LAN tranquilo e dálle ao túnel un rango local único, aceptando que os clientes non terán saída global.

O pool e o push van xuntos. server-ipv6 2001:db8:80:10::/64 asigna enderezos e push "route-ipv6 2000::/3" di aos clientes que enviar ao túnel. Empurrar 2000::/3 cobre o unicast global e deixa os rangos link-local e multicast fóra do túnel.

Escribe o prefixo elixido no rexistro de despregamento. Quen cambie a entrega do provedor a próxima vez necesita saber que /64 ocupa xa o túnel.

Activa o reenvío para a segunda familia

O reenvío IPv4 non implica o reenvío IPv6. Define net.ipv6.conf.all.forwarding=1 e replica todo o que a política FORWARD de IPv4 xa permite. Nun router cuxa cadea FORWARD descarta por defecto, un conxunto de regras ausente parece exactamente un túnel morto.

O apretón de mans ten éxito, o cliente recibe un enderezo e non volve nada. Engade regras para ambas as direccións e para o tramo WAN, porque un túnel que chega á LAN pero non a internet falla a terceira proba. Revisa os contadores da cadea tras un intento fallido, porque unha regra que nunca coincidiu é un problema distinto dunha que coincidiu e descartou.

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

Un efecto secundario atrapa a quen acaba culpando o túnel. Ao activar o reenvío, o núcleo salta a configuración de enderezo por Router Advertisement se non se lle di o contrario, e unha ruta por defecto aprendida así desaparece con ela. Ou fixa unha ruta por defecto explícita na interface WAN, ou pon accept_ra a 2 alí a propósito. Tras calquera dos dous cambios, confirma que o router segue tendo un camiño IPv6 válido cara a fóra antes de volver probar os clientes.

Responde ao descubrimento de veciños cando o extremo superior non encamiña

O equipo do extremo superior ás veces trata o /64 delegado como propio da súa ligazón e négase a encamiñar calquera subprefixo cara á caixa VPN. Cando iso pasa, algo ten que responder as solicitudes de veciños de cada enderezo de cliente por separado.

OpenVPN expón o enderezo asignado a un hook client-connect, así as entradas poden seguir o pool real en lugar dunha lista mantida a man. O hook engade ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, e un hook client-disconnect correspondente retírao. Sen esa retirada, a táboa de proxy queda desfasada e un cliente posterior pode herdar unha entrada dun enderezo que nunca recibiu. Confirma o estado con ip -6 neigh show proxy.

Trata o proxying como un parche. Unha ruta estática para o /64 do túnel apuntada ao router sobrevive aos cambios de clientes e non necesita ningún hook de shell con privilexios.

Segue o camiño cara a fóra, salto a salto

Proba cara a fóra en tres pasos: primeiro o enderezo de túnel do router, despois un host da LAN e terceiro un destino público con traceroute6. O pool demóstrao o primeiro paso, o reenvío e a devasa da LAN o segundo, e o camiño de volta polo extremo superior o terceiro. Cada fallo estreita a busca a un só dispositivo en lugar de reabrir todo o deseño.

Vixía a MTU do túnel, porque os routers IPv6 do camiño non fragmentarán por ti. Unha MTU demasiado grande maniféstase como un erro packet-too-big e un TLS atascado en lugar dun fallo limpo. Fíxaa explicitamente e proba cunha carga preto do límite.