Añadir IPv6 privada a un laboratorio OpenVPN, un punto de control a la vez

Ya tiene un cliente que se conecta por IPv4 y llega a una carga de trabajo IPv4 privada detrás del servidor. El objetivo es llegar a una carga de trabajo IPv6 privada por el mismo túnel sin tocar el transporte exterior. Ese orden importa: la ruta exterior sigue en IPv4 y solo cambian el plan de direcciones interior, la ruta del cliente y el camino de vuelta del servidor a la LAN. Cinco puntos de control, cada uno con algo concreto que mirar antes de seguir.

Punto de control uno: la conexión que ya funciona

Conecte el cliente y confirme la ruta IPv4 antes de añadir nada. Un túnel que funciona le da una línea base que separa un error IPv6 nuevo de un problema de conectividad antiguo. También le dice qué instancia del servidor está editando en realidad.

Anote el grupo, la topología y las rutas empujadas en las que ya confía. El trabajo de IPv6 amplía esa configuración; no la sustituye.

Punto de control dos: elija los prefijos interiores

Elija una ULA /48 para el sitio y corte dos /64 de ella: una para los clientes del túnel, otra para el segmento de LAN que alberga la carga IPv6. Genere el ID global de 40 bits en lugar de copiar un prefijo de ejemplo, y compruebe ambas subredes contra cada red que el sitio ya enruta:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

Dos /64 independientes evitan que el grupo de clientes se recorte del segmento de LAN, lo que importa más adelante cuando escriba la ruta de vuelta. Los valores de arriba son un ejemplo resuelto, no un prefijo para reutilizar.

Punto de control tres: añada el ayudante y el empuje de ruta

Lea la configuración actual del servidor antes de añadir nada. Una segunda copia de una directiva existente no se fusiona con la primera, y el error resultante nombra la directiva, no IPv6. Con el ayudante IPv4 ya presente, dos líneas lo amplían. Cada una responde a una pregunta distinta:

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

La primera es un ayudante cómodo que configura la interfaz y el grupo de clientes. La segunda nombra el destino de LAN que el cliente debe alcanzar. Asignar una dirección IPv6 a un cliente no le dice qué redes hay detrás del servidor, así que hacen falta ambas líneas.

El ayudante no convive con un grupo IPv6 estático ni con nopool. Si el despliegue asigna direcciones de forma estática a propósito, mantenga esa política y diseñe el equivalente IPv6 de forma explícita en lugar de borrar la política para encajar en un ejemplo.

Punto de control cuatro: reenvío y la ruta de respuesta

Active el reenvío IPv6 en el servidor a través del propio dueño de la configuración del sistema, no con una escritura de ejecución puntual que olvidará. La forma de ejecución sirve para una prueba rápida. La configuración persistente va en un archivo drop-in que lee el dueño de red de la distribución:

sysctl -w net.ipv6.conf.all.forwarding=1

El reenvío cambia el comportamiento IPv6 del host más allá de enrutar paquetes. Un host que aceptaba anuncios de router como cliente deja de hacerlo del mismo modo en cuanto reenvía. Por eso una máquina cuyo enlace IPv6 depende de los RA necesita un plan explícito para ese enlace.

Después dé a la LAN una ruta de vuelta al grupo del túnel. La puerta de enlace IPv6 de la carga es el router de la LAN, no el servidor VPN, así que la ruta va en ese router y apunta a la dirección de LAN del servidor:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

Conserve los tipos ICMPv6 que necesita el enlace, incluida la realimentación de MTU de ruta. Una regla de cortafuegos IPv4 no implica una regla IPv6, y un bloqueo total de IPv6 rompe el descubrimiento de vecinos de formas que parecen un fallo de enrutamiento.

Punto de control cinco: lea el cliente y luego pruebe

Vuelva a conectar el cliente y lea las direcciones que recibió de verdad en lugar de deducirlas de la dirección del ayudante del servidor. El listado de la interfaz muestra ambas familias en el mismo dispositivo:

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

Una ruta que elige el túnel demuestra que el cliente sabe adónde enviar el paquete. No demuestra que el servidor lo reenvíe, que el router de la LAN tenga la ruta de vuelta ni que la aplicación tenga permiso para responder.

Pruebe la aplicación en sí por cada familia por turnos y repita tras una reconexión y tras reiniciar el host. Una ruta o un sysctl que solo sobrevive hasta el reinicio es una prueba, no un diseño.

Publique un registro AAAA solo cuando la ruta IPv6 responda de extremo a extremo. Un DNS consultado por IPv4 aún puede devolver una dirección IPv6, así que un nombre resoluble no es prueba de que algo escuche. La guía RFC 4193 para ULA cubre la generación del ID global que hace que estos prefijos sean suyos y no una copia.