Planificación de IPv6 para un concentrador WireGuard de dos sedes: prefijo, pares, rutas

Dos LAN, un concentrador WireGuard y un plan de direcciones IPv6 que debe responder tres preguntas distintas: qué prefijo, qué dirección corresponde a cada enrutador y qué par es dueño de qué subred. Un error en cualquiera de ellas produce un túnel que hace el saludo y no enruta nada. El plan siguiente recorre un diseño privado de dos sedes en ese orden. Deliberadamente no proporciona acceso a Internet por IPv6.

Decida para qué sirve el prefijo

Un prefijo local único de fd00::/8 es la elección natural cuando el objetivo es la conectividad privada entre sedes. Permanece estable sin importar qué proveedor atiende cada ubicación y no se anuncia en la tabla de enrutamiento global, así que no puede filtrar su numeración interna a Internet.

La misma propiedad es la limitación. Una ULA no ofrece ninguna ruta de retorno pública, porque ningún proveedor superior sabe enrutarla hacia su puerta de enlace. Si el requisito incluye salida a Internet por IPv6, necesita una asignación de un proveedor que se la enrute, y esa es una decisión de diseño aparte con su propio tamaño de prefijo.

No asuma que todo despliegue necesita un /48. RFC 6177 se alejó de un único tamaño obligatorio para el sitio final, y el tamaño correcto depende del número de redes que vaya a operar. Genere la ULA con el procedimiento RFC 4193 en lugar de inventar un prefijo que otra organización también podría usar. Escriba el resultado en el plan de direcciones antes de configurar cualquier dispositivo, porque un prefijo que nadie registró es un prefijo que alguien reutilizará.

Divida el prefijo en roles

El ejemplo siguiente usa fd7c:2e91:4a00::/48, y la tabla está organizada por dónde se escribe cada bloque, no por sede. Trate los valores como una muestra y genere los suyos antes de desplegar nada.

Los bloques LAN son /64 porque el SLAAC ordinario espera un identificador de interfaz de 64 bits. Dividir una LAN en un bloque más pequeño rompe esa suposición en la mayoría de los equipos, y el coste operativo no compensa el ahorro de direcciones en un plan privado. Ambos bloques LAN proceden del centro del /48, dejando el rango bajo libre para sedes posteriores.

Las direcciones de túnel son un depósito administrativo, no una red en el enlace. Cada interfaz recibe una única /128 de él, así que ningún equipo supone una subred compartida en el túnel y no se ejecuta descubrimiento de vecinos donde no hace falta. Mantenga los roles disjuntos y regístrelos en el plan de direcciones de la organización para que una sede posterior no reutilice un bloque.

Dé a cada enrutador una dirección de túnel

Asigne una /128 por enrutador y conserve las claves y los extremos existentes del concentrador que funciona. Los tres valores siguientes solo difieren en la parte del equipo.

Hub:    Address = fd7c:2e91:4a00:ff00::1/128
Site A: Address = fd7c:2e91:4a00:ff00::2/128
Site B: Address = fd7c:2e91:4a00:ff00::3/128

Esta /128 describe la única dirección asignada a esa interfaz. No dice nada sobre cuántos destinos puede enrutar el par, porque la conectividad se expresa en AllowedIPs y no en el prefijo de la interfaz.

Cada enrutador de sede también necesita una dirección en su bloque LAN y una forma de distribuirla, normalmente anuncios de enrutador para SLAAC. WireGuard no envía esos anuncios por usted y no une las dos LAN. El enrutador de sede es un enrutador en ambos sentidos.

Ponga la propiedad de la subred en AllowedIPs

La entrada de par del concentrador para la Sede A posee la dirección de túnel de A y la LAN de A, y ese emparejamiento es toda la declaración de propiedad. Nada más en esa sección de par necesita describir la sede.

AllowedIPs = fd7c:2e91:4a00:ff00::2/128, fd7c:2e91:4a00:10::/64

La entrada de par para la Sede B posee el par correspondiente, y aquí la simetría importa más que la brevedad. Lea las dos líneas juntas y la división de propiedad se vuelve visible de un vistazo.

AllowedIPs = fd7c:2e91:4a00:ff00::3/128, fd7c:2e91:4a00:20::/64

Son dos secciones de par separadas, no dos listas que compiten por un par. WireGuard usa AllowedIPs en ambos sentidos: elige el par para un destino saliente y rechaza un paquete entrante cuya origen no coincide con el rango asignado al par que lo descifró. Dar todo el /48 a ambos pares desactivaría esa segunda comprobación y difuminaría qué sede posee qué bloque. Esa distinción es lo que hace visible una dirección de origen incorrecta en lugar de aceptarla en silencio.

Cada sede solo necesita los destinos alcanzables a través de su par de concentrador: la Sede A enumera la dirección del concentrador, la dirección de túnel de la Sede B y la LAN de B, y la Sede B enumera el conjunto recíproco. Las listas son asimétricas a propósito, porque cada enrutador ve un lado distinto de la topología. Escriba ambas desde el plan de direcciones y no desde la configuración de la otra sede, que es como un rango obsoleto sobrevive a una renumeración.

Con wg-quick, estos rangos también crean rutas. Con systemd-networkd o una configuración manual, añada usted mismo las rutas equivalentes; de lo contrario el túnel transporta paquetes que el núcleo nunca le envía.

Complete el reenvío y pruebe ambos sentidos

Active el reenvío de IPv6 en el concentrador y en ambos enrutadores de sede, y permita los servicios necesarios entre sedes en la política de reenvío. Mantenga utilizables los mensajes ICMPv6 Packet Too Big, porque descartarlos rompe el descubrimiento de MTU de la ruta y produce bloqueos en transferencias grandes que parecen fallos de aplicación. Un concentrador que reenvía sin el permiso del cortafuegos descarta el paquete entre el enrutamiento y el túnel. Ese modo de fallo merece conocerse, porque el túnel sigue activo y solo mueren algunos flujos.

sysctl net.ipv6.conf.all.forwarding
ip -6 route
ping -6 -c 3 fd7c:2e91:4a00:20::1

Pruebe desde un equipo de la Sede A hasta un equipo de la Sede B y después en la dirección opuesta. Un ping a la dirección de túnel del concentrador solo ejercita el primer salto y pasará incluso cuando las rutas LAN sean incorrectas. El flujo de equipo a equipo es el que demuestra el plan.

La conexión WireGuard exterior puede funcionar sobre IPv4 mientras el tráfico interior es IPv6, y esa independencia es útil durante la migración. Si más adelante se añade salida global IPv6, revise la asignación del proveedor, la selección de dirección de origen y el enrutamiento de retorno como un nuevo paso de diseño; el plan privado anterior sigue siendo válido para el tráfico entre sedes.