Delegación de prefixos IPv6 a través dunha VPN de sitio a sitio: lista de verificación

Levantar o túnel é a metade fácil. Vin unha ligazón de sitio a sitio manterse establecida durante días mentres todos os equipos da LAN remota recibían silencio, porque o prefixo delegado detrás desa pasarela estaba configurado nunha interface pero nunca se encamiñou cara ao túnel. Os enderezos do túnel respondían aos pings todo o tempo, e por iso mesmo ninguén mirou o prefixo. Esta é a orde que comprobo cando un prefixo IPv6 delegado ten que cruzar unha VPN de sitio: o mapa de prefixos, os selectores de tráfico, o reenvío e a devasa, e despois o camiño de volta.

Escriba o mapa de prefixos antes de tocar o túnel

A delegación de prefixos entrega un bloque ao encamiñador que o solicitou. Non instala unha ruta no par, non estende ese bloque na ligazón nin lle di á pasarela remota que hai detrás do encamiñador solicitante. Esas tres cousas configúraas vostede, e teñen sitio nun plan de direccionamento antes de que cambie ningún ficheiro de configuración.

Para cada sitio, anote o prefixo delegado, o /64 que realmente se usa na LAN, os enderezos do túnel e o propietario de cada ruta. O provedor delega 2001:db8:a1::/56 ao sitio A, que serve 2001:db8:a1:10::/64 na súa LAN; o sitio B conserva 2001:db8:b2::/64. Se o sitio A só serve ese /64, ambos os extremos deberían nomear 2001:db8:a1:10::/64 en lugar de todo o /56.

Dous erros aparecen case sempre. Un é tratar o prefixo remoto como se estivese na ligazón, poñelo en ponte ou na interface do túnel para que a pasarela responda á solicitude de veciño de equipos que non pode alcanzar. O outro é anunciar todo o /56 cando só hai un /64 configurado: a táboa de rutas afirma que o bloque é alcanzable e a maioría dos enderezos caen nun burato negro.

Faga coincidir os selectores de tráfico de ambos os extremos coas rutas

IKEv2 e WireGuard rexeitan ambos o tráfico desaxustado, con suficiente discreción como para que o túnel siga parecendo san.

En strongSwan os selectores son explícitos. No sitio A:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

A conn do sitio B reflicte as dúas subredes. Cando non coinciden, o respondedor rexeita a CHILD_SA con TS_UNACCEPTABLE, así que a SA filla nunca sobe aínda que a IKE_SA si o fixese. En ambos os lados a subrede configurada ten que ser igual ao que o núcleo local encamiña cara ao túnel.

WireGuard leva a mesma información en AllowedIPs, cun xiro: AllowedIPs é un filtro de orixe ao recibir e tamén unha ruta ao enviar. Se a entrada de par do sitio B para o sitio A omite 2001:db8:a1:10::/64, os paquetes do sitio A chegan cun handshake válido e descártanse por non permitidos. Iso produce o patrón coñecido dun handshake que se renova sen parar mentres nunca sae unha resposta. Compare ambos os extremos con wg show wg0 allowed-ips. Volva revisar esa lista cada vez que cambie a delegación; un /64 obsoleto mantén a sesión arriba e o prefixo novo inalcanzable.

Descarte primeiro o reenvío, a devasa e a MTU

Antes de ler outra liña de rexistro, confirme que as pasarelas reenvían de todo. sysctl net.ipv6.conf.all.forwarding ten que devolver 1 en ambas, aplicado tamén ás interfaces do túnel e da LAN. Vén unha trampa incorporada: en canto o reenvío está activo, unha interface con accept_ra=1 deixa de aceptar anuncios de encamiñador do provedor, así que o equipo pode perder a súa ruta por defecto ascendente mentres encamiña perfectamente dentro do túnel. Pono accept_ra=2 onde aínda faga falta un RA do provedor.

Despois as regras da devasa teñen que permitir o prefixo en ambos os sentidos, e ICMPv6 ten que sobrevivir: o descubrimento de veciños, paquete-demasiado-grande e destino-inalcanzable non son opcionais. Se os descarta, o descubrimento de MTU da ruta rompe e obtén conexións que se abren e despois se atascan na primeira resposta grande. Un par mínimo de regras ten este aspecto:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

A MTU está detrás diso. Un túnel reduce a MTU utilizábel por baixo de 1500, e IPv6 esixe que cada ligazón transporte polo menos 1280. Os pings pequenos pasan, unha sesión SSH conxélase nunha ráfaga grande, e /proc/net/snmp6 mostra mensaxes de paquete-demasiado-grande que nunca volven. Fixe a MTU do túnel de forma explícita, ou limite o MSS de TCP na táboa mangle, e deixe que volva o ICMPv6 que informa da MTU menor.

Probe o camiño de volta, non o enderezo do túnel

O fallo que máis tempo custa é o encamiñamento unidireccional. Cada pasarela encamiña o prefixo remoto cara ao túnel, pero os equipos responden pola súa propia pasarela por defecto porque é onde vive o seu /64. Levar un paquete até o destino é só medio camiño.

Dous comandos resolven a maior parte. No sitio A, ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 mostra que interface usaría unha resposta desa orixe; faga a comprobación espello no sitio B. Logo xere tráfico desde un equipo e non desde a pasarela, e compare os contadores en ambos os extremos.

Se a solicitude de veciño para o prefixo remoto aparece no túnel, ese prefixo está na ligazón nalgún sitio onde non debería estar; arranxe iso antes de axustar rutas. Proxy NDP cobre os casos nos que a ponte é realmente necesaria, non é un substituto dunha ruta.

Planifique que o prefixo cambie baixo os seus pés

A delegación de prefixos é un arrendamento entre o encamiñador que delega e o que solicita, e unha renovación pode devolver un bloque distinto: un /56 diferente tras unha migración do provedor, ou un arrendamento máis curto que o tempo que leva arriba o túnel. Cada lugar que nomea o prefixo antigo queda obsoleto de golpe: rutas, selectores, AllowedIPs, regras de devasa, rexistros DNS e calquera monitorización que codifique enderezos literais. O fluxo de mensaxes está en RFC 8415.

Onde se espere que o prefixo se mova, manteña un plan de direccionamento interno que non dependa del e traduza na fronteira. NPTv6 é a opción sen estado e mantén lexíbel a política interna, pero é tradución de prefixos, non unha capa máxica: os límites /64 teñen que aliñarse, as sumas de comprobación axústanse, e as aplicacións que incrustan enderezos literais seguen rompendo. Se mantén os enderezos do provedor de extremo a extremo, anote o comportamento do arrendamento e un procedemento de cambio no plan de direccionamento.

Remate cunha proba que sobreviva ao tempo: un equipo permitido de cada LAN alcanza un servizo da outra LAN, a resposta volve polo túnel, e o mesmo par segue funcionando tras reiniciar o túnel e renovar a delegación. Se falla a última parte, o deseño depende dun estado que non durará a semana.