Debería o tráfico IPv6 pasar pola VPN ou directamente?
Decida se ::/0 pertence dentro do túnel, con tres condicións: soporte da saída, alcance do extremo e redes só locais.
O mes pasado dúas persoas pedíronme resultados opostos: unha quería que a VPN cubrise IPv6 e a outra quería que a impresora da oficina seguise funcionando. Unha soa ruta ::/0 non pode entregar as dúas cousas por si mesma. Que esa ruta pertenza dentro do túnel depende de tres condicións, e a primeira descártaa para a maioría das saídas comerciais. Se a saída non transporta IPv6, encamiñar a ruta por defecto cara a ela agocha o teu tráfico nun túnel que non ten onde envialo.
Tres condicións deciden a resposta
A ruta por defecto é unha liña, ::/0, e coincide con calquera destino IPv6 sen unha ruta máis específica (RFC 4291). Instalala é doado. Decidir se deberías facelo redúcese a tres condicións.
Condición un: a saída á que te conectas ten IPv6 funcionando e está disposta a reenvialo. Condición dous: o teu cliente pode manter un camiño cara ao extremo do túnel, que normalmente está dentro do rango que vas encamiñar. Condición tres: podes nomear os destinos IPv6 locais que deben quedar fóra do túnel.
Cada condición falla á súa maneira, e por iso adiviñar custa unha noite enteira. Unha condición un fallada dache silencio e unha táboa de rutas que parece correcta. Unha condición dous fallada mata o aperto de mans uns segundos despois de comezar. Unha condición tres fallada deixa un túnel funcionando e un compañeiro descontento na impresora.
| What you see | Decision |
|---|---|
| Exit answers IPv6 probes, no local IPv6 devices to protect | Route ::/0 into the tunnel |
| Exit answers IPv6 probes, printer or NAS reachable by a global address | Route ::/0, then give those prefixes a route of their own |
| Exit is IPv4-only inside the tunnel | Do not route ::/0; block IPv6 on the client |
Endpoint is reached over IPv6 and sits inside ::/0 | Install a host route for the endpoint first |
A saída transporta realmente IPv6?
Unha interface de túnel cun enderezo IPv6 non demostra nada sobre o outro lado. Moitos perfís comerciais son só IPv4 por dentro: o servidor dache un enderezo v4 e descarta todo o demais. Instala enriba unha ruta por defecto desde AllowedIPs e o núcleo enviará encantado IPv6 cara a unha interface cuxo par nunca o ve.
Proba desde o cliente mentres o túnel está activo. ping -6 -c 3 2001:4860:4860::8888 e ip -6 route get 2001:4860:4860::8888 responden preguntas distintas: se volve unha resposta e que dispositivo escolleu o núcleo. Cando o segundo nomea o teu túnel e o primeiro non devolve nada, o problema é a saída, non a ruta.
Se xestionas ti mesmo a saída, a proba do cliente pode pasar e o camiño aínda así rematar nun calexón sen saída. Confirma net.ipv6.conf.all.forwarding=1 na pasarela e que o seu cortafuegos acepta paquetes reenviados fóra do túnel. Un paquete correctamente encamiñado cara a unha saída que se nega a retransmitir parece exactamente un fallo de encamiñamento desde o lado do cliente.
Pode o cliente manter o seu camiño ata o extremo?
Este é o caso que me atrapou nun portátil cun extremo de WireGuard só IPv6. O enderezo do extremo é un enderezo global corrente, así que cae dentro de ::/0. Encamiña todo o prefixo cara á interface e os paquetes do aperto de mans perseguiranse a si mesmos dentro do túnel que aínda intentan construír. O túnel nunca sobe, e nada na saída do cliente di por que.
wg-quick encárgase disto en Linux. Deriva rutas de AllowedIPs, instálaas na súa propia táboa e engade unha regra de política para que o tráfico cara ao extremo se resolva primeiro pola táboa principal: a regra suppress_prefixlength 0 que atopas en ip -6 rule. Por iso wg-quick up ten éxito onde unha ip -6 route add default dev wg0 escrita á man déixache fóra.
Comproba ambos os estados con ip -6 route get <endpoint-v6>, antes e despois de levantar o túnel. Se a resposta cambia ao teu dispositivo de túnel, eliminaches o camiño que o túnel necesita. Cando escribas as rutas ti mesmo, engade unha ruta de host cara ao extremo pola pasarela orixinal, ou conéctate ao extremo por IPv4 e deixa IPv6 para a carga útil.
Que debe quedar fóra do túnel?
As rutas máis específicas vencen a ruta por defecto, así que un prefixo na ligazón ou un rango ULA con ruta propia segue funcionando sen esforzo extra. Esa é a razón silenciosa pola que sobreviven tantas configuracións IPv4 de túnel completo: os prefixos da LAN son máis específicos ca o de defecto e nunca entran no túnel.
Rómpese cando un dispositivo local é alcanzable por un enderezo global, algo normal nunha impresora á que o mesmo router deu un prefixo público, un NAS ou un televisor. Eses enderezos coinciden con ::/0 e con nada máis, así que se mudan ao túnel con todo o demais e desaparecen.
Decide por destino, non por protocolo. Se importan dous ou tres equipos locais, dá aos seus prefixos unha ruta pola interface física, ou quita os do conxunto negociado. Se a lista non deixa de crecer, a resposta honesta é túnel dividido para IPv6 cunha lista de excepcións escrita, non unha ruta por defecto que parcheas sen parar.
Se a resposta é non, bloquéao
Deixar IPv6 sen encamiñar non é o mesmo que deixalo en paz. Un equipo cunha ruta por defecto IPv6 funcionando segue usándoa mentres o túnel transporta IPv4, así que o tráfico sae ao lado da VPN e cada servizo que prefire IPv6 ve o teu enderezo real. Iso é unha fuga, non un túnel dividido.
Elixe unha e anota cal escolliches. Encamiña a ruta por defecto e acepta os compromisos anteriores, ou desactiva IPv6 mentres dure o túnel. Omitir o prefixo de AllowedIPs non abonda por si só, porque o sistema operativo mantén a súa propia ruta por defecto. En Linux a versión contundente é sysctl -w net.ipv6.conf.all.disable_ipv6=1; a versión fina deixa caer IPv6 fóra do túnel cunha regra de cortafuegos. Os clientes de teléfono inclúen un interruptor explícito de bloqueo de IPv6 que fai o mesmo traballo.
Verifícao como unha fuga
Levanta o túnel e le o estado en lugar de confiar no interruptor. ip -6 route show default debería mostrar unha soa ruta por defecto, e ip -6 route get para un destino fóra da túa LAN debería nomear o dispositivo de túnel. Repite ambos tras unha desconexión: unha ruta por defecto que sobrevive ao túnel é o fallo que buscabas.
Despois proba a outra dirección. Desde un equipo da rede local, chega ao cliente polo seu enderezo IPv6 local. Se iso deixa de funcionar, a condición tres nunca se cumpriu, dixese o que dixese a táboa de rutas naquel momento.
Escribe o resultado onde o atope a seguinte persoa: que prefixos quedan locais, por que e que fai o cliente tras unha desconexión. Dúas liñas nun runbook aforran ao seguinte enxeñeiro redescubrir o bucle do extremo a medianoite.