O aplicație dintr-un spațiu de nume VPN nu este accesibilă din LAN

Serviciul tău rulează pe mașină, tunelul este ridicat și totuși browserul de pe birou încă așteaptă un răspuns. Nimic nu este stricat în sensul obișnuit: aplicația ascultă în interiorul unui spațiu de nume de rețea, iar stiva aceea este invizibilă pentru LAN. Loopback-ul ei aparține spațiului de nume, așa că un client de pe altă mașină nu are nicio adresă care să ajungă la port. Un singur salt deliberat, sau o singură pereche veth, rezolvă asta fără a muta restul gazdei.

De ce nimic nu răspunde la adresa LAN

Un spațiu de nume este o stivă de rețea completă: interfețe, rute, reguli de firewall și un loopback privat. Un proces lansat prin ip netns exec vede doar acea stivă și nimic altceva, așa că adresa la care se leagă este rezolvată doar în interiorul spațiului de nume. Propriul 127.0.0.1 al gazdei este un loopback complet diferit.

De aceea curl eșuează pe gazdă, în timp ce aceeași comandă din interiorul spațiului de nume reușește. Aplicația este sănătoasă; adresa pur și simplu nu există în stiva gazdei.

Publică un singur port cu un salt socat

socat unește cele două stive în spațiul utilizatorului, ceea ce este suficient când trebuie să treacă un singur port TCP. Partea gazdă ascultă în LAN și, pentru fiecare conexiune acceptată, pornește un al doilea socat în interiorul spațiului de nume care se conectează la loopback-ul aplicației. Procesul interior ajunge la aplicație exact așa cum ar face-o un client local. Nimic din rutarea spațiului de nume nu se schimbă, așa că aplicația continuă să folosească tunelul ca singura ieșire.

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

Procesul exterior are nevoie de root sau de capacitatea de a intra în spațiul de nume. Dacă VPN-ul cade, aplicația își pierde calea, iar portul publicat eșuează închis, iar acesta este comportamentul pe care îl vrei de la o cușcă.

Folosește o pereche veth când trec mai multe porturi

O pereche veth este răspunsul corect când trebuie să treacă mai multe porturi sau protocoale, sau când alte gazde trebuie să inițieze conexiuni. Un capăt rămâne în gazdă, celălalt se mută în spațiul de nume, iar un /30 mic oferă ambelor părți o adresă stabilă. Apoi o rută a gazdei trimite adresa spațiului de nume prin pereche.

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

Nu adăuga o rută implicită prin gazdă decât dacă intenționezi să spargi cușca. Tunelul trebuie să rămână ieșirea, așa că prin pereche este accesibilă doar adresa serviciului publicat. Dă spațiului de nume și propriul fișier de rezolvare, pentru că ip netns exec citește /etc/netns/vpn/resolv.conf și fără el rezolvarea numelor în cușcă este goală.

Testează de pe o a doua mașină, nu de pe gazdă

Rulează testul de pe o a doua mașină, pentru că gazda poate ajunge la un ascultător local pe căi care nu spun nimic despre LAN. Verifică mai întâi la ce s-a legat de fapt aplicația în interiorul spațiului de nume, apoi conectează-te din exterior la adresa publicată. Legarea la fiecare adresă de acolo nu lărgește cușca, pentru că wildcard-ul aparține în continuare spațiului de nume, iar LAN-ul nu îl poate vedea.

ip netns exec vpn ss -lntp

Dacă conexiunea din gazdă funcționează și cea din LAN nu, piesa lipsă este saltul sau ruta, nu adresa de legare. Pornește OpenVPN în interiorul spațiului de nume în loc să muți acolo un dispozitiv tun activ, deoarece mutarea interfeței îl oprește și poate șterge rute pe care apoi nu le vei putea repara din exterior. Ține comenzile de recuperare pe consolă, nu în cușcă.