Una aplicació dins d’un espai de noms VPN no és accessible des de la LAN

El teu servei funciona a la màquina, el túnel està aixecat i el navegador de la teva taula encara no rep cap resposta. No hi ha res trencat en el sentit habitual: l’aplicació escolta dins d’un espai de noms de xarxa, i aquesta pila és invisible per a la LAN. El seu bucle local pertany a l’espai de noms, així que un client en una altra màquina no té cap adreça que arribi al port. Un salt deliberat, o una parella veth, ho arregla sense moure la resta de l’amfitrió.

Per què no respon res a l’adreça de la LAN

Un espai de noms és una pila de xarxa completa: interfícies, rutes, regles de tallafoc i un bucle local privat. Un procés llançat amb ip netns exec veu aquesta pila i res més, així que l’adreça que enllaça es resol només dins de l’espai de noms. El propi 127.0.0.1 de l’amfitrió és un bucle local completament diferent.

Per això curl falla a l’amfitrió mentre la mateixa ordre dins de l’espai de noms té èxit. L’aplicació és sana; l’adreça simplement no existeix a la pila de l’amfitrió.

Publica un sol port amb un salt de socat

socat connecta les dues piles a l’espai d’usuari, cosa que n’hi ha prou quan ha de travessar un sol port TCP. El costat de l’amfitrió escolta a la LAN i, per a cada connexió acceptada, inicia un segon socat dins de l’espai de noms que es connecta al bucle local de l’aplicació. El procés intern arriba a l’aplicació exactament com ho faria un client local. No canvia res de l’encaminament de l’espai de noms, així que l’aplicació continua fent servir el túnel com a única sortida.

socat TCP-LISTEN:9100,reuseaddr,fork EXEC:'ip netns exec vpn socat STDIO tcp-connect:127.0.0.1:9100',nofork

El procés extern necessita root o la capacitat d’entrar a l’espai de noms. Si la VPN cau, l’aplicació perd el camí i el port publicat falla tancat, que és el comportament que vols d’una gàbia.

Fes servir una parella veth quan travessa més d’un port

Una parella veth és la resposta correcta quan han de travessar diversos ports o protocols, o quan altres amfitrions han d’iniciar connexions. Un extrem es queda a l’amfitrió, l’altre passa a l’espai de noms, i una /30 petita dona a tots dos costats una adreça estable. Després una ruta d’amfitrió envia l’adreça de l’espai de noms per la parella.

ip link add veth0 type veth peer name veth1
ip link set veth1 netns vpn
ip addr add 10.77.0.1/30 dev veth0
ip link set veth0 up
ip netns exec vpn ip addr add 10.77.0.2/30 dev veth1
ip netns exec vpn ip link set veth1 up

No afegeixis una ruta per defecte a través de l’amfitrió si no vols trencar la gàbia. El túnel ha de continuar sent la sortida, així que per la parella només és accessible l’adreça del servei publicat. Dona a l’espai de noms també el seu propi fitxer de resolució, perquè ip netns exec llegeix /etc/netns/vpn/resolv.conf i sense ell la resolució de noms dins de la gàbia és buida.

Prova-ho des d’una altra màquina, no des de l’amfitrió

Executa la prova des d’una segona màquina, perquè l’amfitrió pot arribar a un oient local per camins que no diuen res de la LAN. Primer comprova a què s’ha enllaçat realment l’aplicació dins de l’espai de noms i després connecta’t a l’adreça publicada des de fora. Enllaçar a totes les adreces d’allà no eixampla la gàbia, perquè el comodí encara pertany a l’espai de noms i la LAN no el pot veure.

ip netns exec vpn ss -lntp

Si la connexió des de l’amfitrió funciona i la de la LAN no, la peça que falta és el salt o la ruta, no l’adreça d’enllaç. Inicia OpenVPN dins de l’espai de noms en lloc de moure-hi un dispositiu tun viu, ja que moure la interfície el desactiva i pot esborrar rutes que després no podràs reparar des de fora. Tingues les ordres de recuperació a la consola, no dins de la gàbia.