WireGuard en un espacio de nombres de red: por qué el socket se quedó atrás

La interfaz aparece en el espacio de nombres que quería, la aplicación está vinculada a ella y, aun así, nunca aparece tráfico del túnel. Esta es la firma de un dispositivo WireGuard del núcleo de Linux que se creó en un espacio de nombres y se movió a otro: la interfaz se movió y su socket UDP cifrado no. Ambos tienen que estar en el lugar correcto antes de que el tráfico interior importe. La comprobación es rápida en cuanto sabe que hay que mirar dos contextos en lugar de uno.

El síntoma: espacio de nombres correcto, sin paquetes

Dentro del espacio de nombres, el túnel parece sano. El dispositivo existe, las direcciones están asignadas y la configuración del par está presente. Fuera, el intercambio UDP esperado nunca aparece en la interfaz que estaba vigilando, y el lado opuesto informa de que no hay ningún apretón de manos.

La razón es que los paquetes internos de la aplicación llegan al dispositivo movido, y el dispositivo intenta enviarlos por un socket que pertenece a otro contexto de red. La ruta subyacente que utiliza, y cada regla de cortafuegos que se le aplica, son las del espacio de nombres donde se creó el dispositivo.

No es un error en el movimiento ni una configuración incorrecta del par. Es lo que hace la implementación del núcleo, y la documentación de espacios de nombres de WireGuard describe directamente la regla de creación.

Por qué el socket tiene un lugar de nacimiento

Un dispositivo WireGuard posee un socket UDP para su transporte cifrado, y ese socket se abre en el espacio de nombres donde se crea el dispositivo. Mover la interfaz con una orden de enlace traslada el dispositivo visible pero deja el transporte donde empezó. Entonces los dos objetos tienen propietarios distintos.

La consecuencia es fácil de pasar por alto porque las dos mitades se inspeccionan en lugares diferentes. La ruta interior se decide en el espacio de nombres donde se ejecuta la aplicación, y la ruta exterior se decide donde vive el socket. Comprobar solo una de ellas produce una conclusión segura y equivocada. Comprobar ambas suele terminar la investigación en una sola pasada.

Créelo donde quiera el socket

La solución es crear el dispositivo dentro del espacio de nombres de destino en lugar de crearlo fuera y moverlo. Suponiendo que ya existe un espacio de nombres aprobado y que el nombre no se usa:

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

Ahora tanto la interfaz como su socket pertenecen a ese contexto, así que la ruta subyacente y las reglas de filtrado aplicables son las configuradas allí. Si el diseño necesita el lado claro en otro sitio, ponga primero la interfaz subyacente en el espacio de nombres y cree el túnel después. El orden forma parte del diseño, no es un detalle de implementación.

Trátelas como órdenes de administración de red, no como una receta. Crean un dispositivo y muestran el estado; las claves, los pares, las direcciones y las rutas todavía tienen que venir de una configuración aprobada, y nunca debería sustituirse una interfaz de producción existente en un ejemplo.

Lea los dos lados del camino

Cuando el dispositivo esté en el lugar correcto, verifique las dos decisiones por separado. Empiece por la consulta interior desde el contexto de la aplicación y después compruebe el camino exterior desde el contexto que posee el socket:

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

Si la consulta interior se resuelve por el túnel y la captura exterior muestra el intercambio cifrado, las dos mitades coinciden. Si la captura está vacía, el socket sigue en otro sitio, o la ruta subyacente de su espacio de nombres no llega al punto final.

Una comprobación más pertenece al registro: cómo se crea el dispositivo tras un reinicio. Un gestor que recrea la interfaz con un contexto de creación distinto cambia el lugar de nacimiento del socket. Un movimiento manual que funcionó una vez no es prueba sobre el camino gestionado.