Delegación de prefijos IPv6 a través de una VPN de sitio a sitio: lista de comprobación

Levantar el túnel es la mitad fácil. He visto un enlace de sitio a sitio mantenerse establecido durante días mientras todos los equipos de la LAN remota recibían silencio, porque el prefijo delegado detrás de esa puerta de enlace estaba configurado en una interfaz pero nunca se enrutó hacia el túnel. Las direcciones del túnel respondían a los pings todo el tiempo, y por eso mismo nadie miró el prefijo. Este es el orden que compruebo cuando un prefijo IPv6 delegado tiene que cruzar una VPN de sitio: el mapa de prefijos, los selectores de tráfico, el reenvío y el cortafuegos, y después la ruta de retorno.

Escriba el mapa de prefijos antes de tocar el túnel

La delegación de prefijos entrega un bloque al enrutador que lo solicitó. No instala una ruta en el par, no extiende ese bloque en el enlace ni le dice a la puerta de enlace remota qué hay detrás del enrutador solicitante. Esas tres cosas las configura usted, y tienen sitio en un plan de direccionamiento antes de que cambie ningún archivo de configuración.

Para cada sitio, anote el prefijo delegado, la /64 que realmente se usa en la LAN, las direcciones del túnel y el propietario de cada ruta. El proveedor delega 2001:db8:a1::/56 al sitio A, que sirve 2001:db8:a1:10::/64 en su LAN; el sitio B conserva 2001:db8:b2::/64. Si el sitio A solo sirve esa /64, ambos extremos deberían nombrar 2001:db8:a1:10::/64 en lugar de todo el /56.

Dos errores aparecen casi siempre. Uno es tratar el prefijo remoto como si estuviera en el enlace, puentearlo o ponerlo en la interfaz del túnel para que la puerta de enlace responda a la solicitud de vecino de equipos que no puede alcanzar. El otro es anunciar todo el /56 cuando solo hay una /64 configurada: la tabla de rutas afirma que el bloque es alcanzable y la mayoría de las direcciones caen en un agujero negro.

Haga coincidir los selectores de tráfico de ambos extremos con las rutas

IKEv2 y WireGuard rechazan ambos el tráfico desajustado, con la suficiente discreción como para que el túnel siga pareciendo sano.

En strongSwan los selectores son explícitos. En el 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

La conn del sitio B refleja las dos subredes. Cuando no coinciden, el respondedor rechaza la CHILD_SA con TS_UNACCEPTABLE, así que la SA hija nunca sube aunque la IKE_SA sí lo haya hecho. En ambos lados la subred configurada tiene que ser igual a lo que el núcleo local enruta hacia el túnel.

WireGuard lleva la misma información en AllowedIPs, con un giro: AllowedIPs es un filtro de origen al recibir y también una ruta al enviar. Si la entrada de par del sitio B para el sitio A omite 2001:db8:a1:10::/64, los paquetes del sitio A llegan con un handshake válido y se descartan por no permitidos. Eso produce el patrón conocido de un handshake que se renueva sin parar mientras nunca sale una respuesta. Compare ambos extremos con wg show wg0 allowed-ips. Vuelva a revisar esa lista cada vez que cambie la delegación; una /64 obsoleta mantiene la sesión arriba y el prefijo nuevo inalcanzable.

Descarte primero el reenvío, el cortafuegos y la MTU

Antes de leer otra línea de registro, confirme que las puertas de enlace reenvían en absoluto. sysctl net.ipv6.conf.all.forwarding tiene que devolver 1 en ambas, aplicado también a las interfaces del túnel y de la LAN. Viene una trampa incorporada: en cuanto el reenvío está activo, una interfaz con accept_ra=1 deja de aceptar anuncios de enrutador del proveedor, así que el equipo puede perder su ruta por defecto ascendente mientras enruta perfectamente dentro del túnel. Ponga accept_ra=2 donde todavía haga falta un RA del proveedor.

Después, las reglas del cortafuegos tienen que permitir el prefijo en ambos sentidos, y ICMPv6 tiene que sobrevivir: el descubrimiento de vecinos, paquete-demasiado-grande y destino-inalcanzable no son opcionales. Si los descarta, se rompe el descubrimiento de MTU de la ruta y obtiene conexiones que se abren y luego se atascan en la primera respuesta grande. Un par mínimo de reglas tiene 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

La MTU está detrás de eso. Un túnel reduce la MTU utilizable por debajo de 1500, y IPv6 exige que cada enlace transporte al menos 1280. Los pings pequeños pasan, una sesión SSH se congela con una ráfaga grande, y /proc/net/snmp6 muestra mensajes de paquete-demasiado-grande que nunca vuelven. Fije la MTU del túnel de forma explícita, o limite el MSS de TCP en la tabla mangle, y deje que vuelva el ICMPv6 que informa de la MTU menor.

Pruebe la ruta de retorno, no la dirección del túnel

El fallo que más tiempo cuesta es el enrutamiento unidireccional. Cada puerta de enlace enruta el prefijo remoto hacia el túnel, pero los equipos responden por su propia puerta de enlace predeterminada porque ahí vive su /64. Llevar un paquete hasta el destino es solo medio camino.

Dos comandos resuelven la mayor parte. En el sitio A, ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 muestra qué interfaz usaría una respuesta de esa fuente; haga la comprobación espejo en el sitio B. Luego genere tráfico desde un equipo y no desde la puerta de enlace, y compare los contadores en ambos extremos.

Si la solicitud de vecino para el prefijo remoto aparece en el túnel, ese prefijo está en el enlace en algún sitio donde no debería estar; arréglelo antes de ajustar rutas. Proxy NDP cubre los casos en los que el puenteo es realmente necesario, no es un sustituto de una ruta.

Planifique que el prefijo cambie bajo sus pies

La delegación de prefijos es un arrendamiento entre el enrutador que delega y el que solicita, y una renovación puede devolver un bloque distinto: un /56 diferente tras una migración del proveedor, o un arrendamiento más corto que el tiempo que lleva arriba el túnel. Cada lugar que nombra el prefijo antiguo queda obsoleto de golpe: rutas, selectores, AllowedIPs, reglas de cortafuegos, registros DNS y cualquier monitorización que codifique direcciones literales. El flujo de mensajes está en RFC 8415.

Donde se espere que el prefijo se mueva, mantenga un plan de direccionamiento interno que no dependa de él y traduzca en la frontera. NPTv6 es la opción sin estado y mantiene legible la política interna, pero es traducción de prefijos, no una capa mágica: los límites /64 tienen que alinearse, las sumas de comprobación se ajustan, y las aplicaciones que incrustan direcciones literales siguen rompiéndose. Si mantiene las direcciones del proveedor de extremo a extremo, anote el comportamiento del arrendamiento y un procedimiento de cambio en el plan de direccionamiento.

Termine con una prueba que sobreviva al tiempo: un equipo permitido de cada LAN alcanza un servicio de la otra LAN, la respuesta vuelve por el túnel, y el mismo par sigue funcionando tras reiniciar el túnel y renovar la delegación. Si falla la última parte, el diseño depende de un estado que no durará la semana.