WireGuard en un espai de noms de xarxa: per què el sòcol es va quedar enrere

La interfície apareix a l’espai de noms que volíeu, l’aplicació hi està lligada i, tot i això, no apareix mai trànsit del túnel. Aquesta és la signatura d’un dispositiu WireGuard del nucli de Linux que es va crear en un espai de noms i es va moure a un altre: la interfície es va moure i el seu sòcol UDP xifrat no. Tots dos han de ser al lloc correcte abans que el trànsit interior tingui importància. La comprovació és ràpida quan sabeu que cal mirar dos contexts en lloc d’un.

El símptoma: espai de noms correcte, cap paquet

Dins de l’espai de noms, el túnel sembla sa. El dispositiu existeix, les adreces estan assignades i la configuració del parell és present. A fora, l’intercanvi UDP esperat no apareix mai a la interfície que estàveu vigilant, i el costat oposat informa que no hi ha cap encaixada de mans.

El motiu és que els paquets interiors de l’aplicació arriben al dispositiu mogut, i el dispositiu intenta enviar-los per un sòcol que pertany a un context de xarxa diferent. La ruta subjacent que utilitza, i cada regla de tallafoc que hi aplica, són les de l’espai de noms on es va crear el dispositiu.

No és un error en el moviment ni una configuració incorrecta del parell. És el que fa la implementació del nucli, i la documentació d’espais de noms de WireGuard descriu directament la regla de creació.

Per què el sòcol té un lloc de naixement

Un dispositiu WireGuard posseeix un sòcol UDP per al seu transport xifrat, i aquest sòcol s’obre a l’espai de noms on es crea el dispositiu. Moure la interfície amb una ordre d’enllaç trasllada el dispositiu visible però deixa el transport on va començar. Aleshores els dos objectes tenen propietaris diferents.

La conseqüència és fàcil de passar per alt perquè les meitats s’inspeccionen en llocs diferents. La ruta interior es decideix a l’espai de noms on s’executa l’aplicació, i la ruta exterior es decideix on viu el sòcol. Comprovar només una d’elles produeix una conclusió segura i equivocada. Comprovar-les totes dues sol tancar la investigació en una sola passada.

Creeu-lo on vulgueu el sòcol

La solució és crear el dispositiu dins de l’espai de noms de destinació en lloc de crear-lo fora i moure’l. Suposant que ja existeix un espai de noms aprovat i que el nom no s’utilitza:

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

Ara tant la interfície com el seu sòcol pertanyen a aquest context, així que la ruta subjacent i les regles de filtratge aplicables són les configurades allà. Si el disseny necessita el costat clar en un altre lloc, poseu primer la interfície subjacent a l’espai de noms i créeu el túnel després. L’ordre forma part del disseny, no és un detall d’implementació.

Tracteu-les com a ordres d’administració de xarxa, no com una recepta. Creen un dispositiu i mostren l’estat; les claus, els parells, les adreces i les rutes encara han de venir d’una configuració aprovada, i mai no s’ha de substituir una interfície de producció existent en un exemple.

Llegiu els dos costats del camí

Quan el dispositiu sigui al lloc correcte, verifiqueu les dues decisions per separat. Comenceu per la consulta interior des del context de l’aplicació i després comproveu el camí exterior des del context que posseeix el sòcol:

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 es resol pel túnel i la captura exterior mostra l’intercanvi xifrat, les dues meitats coincideixen. Si la captura és buida, el sòcol encara és en un altre lloc, o la ruta subjacent del seu espai de noms no arriba al punt final.

Una comprovació més pertany al registre: com es crea el dispositiu després d’un reinici. Un gestor que recrea la interfície amb un context de creació diferent canvia el lloc de naixement del sòcol. Un moviment manual que va funcionar una vegada no és prova sobre el camí gestionat.