Prueba el enrutamiento VPN en espacios de nombres sin tocar las rutas del host

Dos laboratorios pueden modelar la misma topología VPN y fallar de formas completamente distintas: uno vive en espacios de nombres de red, el otro en las rutas propias del host. La versión con espacios de nombres mantiene cada interfaz, ruta y socket en un contexto que puedes borrar, mientras que la versión con el host arranca más rápido y deja estado detrás. Ese estado residual es la razón por la que el segundo laboratorio es difícil de repetir un mes después. Compara primero la limpieza, porque decide si puedes ejecutar el experimento dos veces.

Dos formas de construir el mismo laboratorio, y cuándo gana cada una

En un laboratorio de rutas del host añades una interfaz de túnel y rutas a la máquina en la que trabajas, así que el experimento comparte suerte con tu shell, tu gestor de paquetes y cualquier otra conexión. En un laboratorio de espacios de nombres cada rol recibe su propia pila de interfaces, direcciones, rutas y sockets, y borrar el espacio de nombres elimina todo eso. Ningún modelo es más correcto, porque responden a preguntas distintas. Elige espacios de nombres cuando el tema sea el enrutamiento y el reenvío, y un laboratorio con el host cuando el tema sea cómo se integra un cliente de escritorio.

Mezclar los dos es el error habitual: un laboratorio de espacios de nombres probado contra un cliente solo del host no demuestra nada sobre ninguna de las dos disposiciones. Decide qué pregunta haces antes de crear el primer enlace.

Un contexto por rol, conectado a propósito

Crea un espacio de nombres por rol y mueve cada extremo de cada par veth al contexto que lo posee. Los cuatro primeros comandos bastan para ver la forma:

ip netns add client
ip netns add gateway
ip link add veth-c type veth peer name veth-g
ip link set veth-c netns client

Da al laboratorio rangos que no se solapen con nada del host, y anota antes de empezar qué espacio de nombres posee qué dirección. Un laboratorio que funcione necesita dos caminos separados: uno exterior para que el extremo VPN llegue a su par, y un camino de retorno para el recurso que se protege. Modélalos como dos decisiones, porque un laboratorio que solo construye la mitad de salida pasa una prueba de apretón de manos y falla una prueba de aplicación.

El rol de reenvío es donde los laboratorios se vuelven interesantes

Un rol tiene que reenviar, lo que significa habilitar el reenvío dentro de ese espacio de nombres y añadir la regla que el diseño necesite. El estado de reenvío es por espacio de nombres, así que la configuración del host es irrelevante para el laboratorio y la configuración del laboratorio no se filtra hacia fuera, como describe la documentación sobre espacios de nombres de red. WireGuard documenta que una interfaz y su socket exterior pueden vivir en espacios de nombres distintos, lo que es un truco útil y una excelente manera de confundirte. No asumas que mover una interfaz mueve cada parte de la conexión de la misma forma.

Comprueba el contador de reenvío después de un paquete de prueba, porque una regla que nunca coincidió y una regla que descartó se ven idénticas en la tabla de rutas. Solo los contadores las separan.

Registra una línea base, luego rompe una ruta

Empieza registrando lo que existe, con el contexto escrito junto a cada línea. Lee los espacios de nombres, luego la ruta que tomaría un destino de prueba dentro de uno de ellos, luego los contadores en el enlace que la transporta:

ip netns list
ip -n client route get 10.0.0.5
ip -n gateway -s link show veth-g

El tercer comando es el que la gente omite, y ahí es donde vive la evidencia: los contadores de descartes y errores te dicen si un paquete llegó siquiera al rol de reenvío. Captura las mismas tres vistas después de un cambio, y deja que el diff sea la evidencia en lugar de tu memoria. Luego rompe exactamente una cosa, ya sea borrando una ruta o añadiendo una regla de denegación en el camino de reenvío, y confirma el síntoma que predijiste: un apretón de manos completado sin respuesta, o un fallo de resolución en lugar de un tiempo de espera agotado. Un laboratorio que solo demuestra éxito enseña muy poco.

La limpieza es lo que hace repetible la siguiente ejecución

Mantén la limpieza limitada a los recursos que nombraste, porque un reinicio general del cortafuegos o la eliminación de una ruta del host no es reproducibilidad, es un segundo incidente. Guarda la topología, los comandos exactos y las observaciones que esperabas, para que la siguiente ejecución reproduzca el mismo fallo en lugar de adivinar qué contexto tenía el estado anterior. Sin ese registro, el laboratorio es una historia y no un procedimiento.

Usa credenciales generadas localmente para el laboratorio y mantén las cuentas de producción fuera de los ejemplos compartidos. Luego borra cada espacio de nombres y confirma que la vista del host no ha cambiado, que es toda la razón para elegir este modelo. Un laboratorio que no puedes eliminar limpiamente es un cambio en el host con pasos extra.