WireGuard nun espazo de nomes de rede: por que o socket quedou atrás

A interface aparece no espazo de nomes que quería, a aplicación está vinculada a ela e, aínda así, nunca aparece tráfico do túnel. Esta é a sinatura dun dispositivo WireGuard do núcleo de Linux que se creou nun espazo de nomes e se moveu a outro: a interface moveuse e o seu socket UDP cifrado non. Ambos teñen que estar no lugar correcto antes de que o tráfico interior importe. A comprobación é rápida en canto sabe que hai que mirar dous contextos en lugar de un.

O síntoma: espazo de nomes correcto, sen paquetes

Dentro do espazo de nomes, o túnel parece san. O dispositivo existe, as direccións están asignadas e a configuración do par está presente. Fóra, o intercambio UDP esperado nunca aparece na interface que estaba vixiando, e o lado oposto informa de que non hai ningún aperto de mans.

A razón é que os paquetes internos da aplicación chegan ao dispositivo movido, e o dispositivo tenta envialos por un socket que pertence a outro contexto de rede. A ruta subxacente que usa, e cada regra de cortafogos que se lle aplica, son as do espazo de nomes onde se creou o dispositivo.

Non é un erro no movemento nin unha configuración incorrecta do par. É o que fai a implementación do núcleo, e a documentación de espazos de nomes de WireGuard describe directamente a regra de creación.

Por que o socket ten un lugar de nacemento

Un dispositivo WireGuard posúe un socket UDP para o seu transporte cifrado, e ese socket ábrese no espazo de nomes onde se crea o dispositivo. Mover a interface cunha orde de ligazón traslada o dispositivo visible pero deixa o transporte onde comezou. Entón os dous obxectos teñen propietarios distintos.

A consecuencia é fácil de pasar por alto porque as dúas metades inspecciónanse en lugares diferentes. A ruta interior decídese no espazo de nomes onde se executa a aplicación, e a ruta exterior decídese onde vive o socket. Comprobar só unha delas produce unha conclusión segura e equivocada. Comprobar ambas adoita rematar a investigación nunha soa pasada.

Créao onde queira o socket

A solución é crear o dispositivo dentro do espazo de nomes de destino en lugar de crealo fóra e movelo. Supoñendo que xa existe un espazo de nomes aprobado e que o nome non se usa:

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

Agora tanto a interface como o seu socket pertencen a ese contexto, así que a ruta subxacente e as regras de filtrado aplicables son as configuradas alí. Se o deseño necesita o lado claro noutro sitio, poña primeiro a interface subxacente no espazo de nomes e cree o túnel despois. A orde forma parte do deseño, non é un detalle de implementación.

Tráteas como ordes de administración de rede, non como unha receita. Crean un dispositivo e mostran o estado; as claves, os pares, as direccións e as rutas aínda teñen que vir dunha configuración aprobada, e nunca se debería substituír unha interface de produción existente nun exemplo.

Lea os dous lados do camiño

Cando o dispositivo estea no lugar correcto, verifique as dúas decisións por separado. Comece pola consulta interior desde o contexto da aplicación e despois comprobe o camiño exterior desde o contexto que posúe o 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

Se a consulta interior se resolve polo túnel e a captura exterior mostra o intercambio cifrado, as dúas metades coinciden. Se a captura está baleira, o socket segue noutro sitio, ou a ruta subxacente do seu espazo de nomes non chega ao punto final.

Unha comprobación máis pertence ao rexistro: como se crea o dispositivo tras un reinicio. Un xestor que recrea a interface cun contexto de creación distinto cambia o lugar de nacemento do socket. Un movemento manual que funcionou unha vez non é proba sobre o camiño xestionado.