Program in 'n VPN-naamruimte is nie vanaf die LAN bereikbaar nie

Jou diens werk op die rekenaar, die tonnel is op, en die blaaier op jou lessenaar kry steeds geen antwoord nie. Niks is in die gewone sin stukkend nie: die toepassing luister binne 'n netwerknaamruimte, en daardie stapel is onsigbaar vir die LAN. Sy loopback behoort aan die naamruimte, so 'n kliënt op 'n ander masjien het geen adres wat die poort bereik nie. Een doelbewuste sprong, of een veth-paar, maak dit reg sonder om die res van die gasheer te verskuif.

Waarom niks op die LAN-adres antwoord nie

'n Naamruimte is 'n volledige netwerkstapel: koppelvlakke, roetes, firewall-reëls en 'n private loopback. 'n Proses wat deur ip netns exec begin word, sien daardie stapel en niks anders nie, so die adres wat dit bind, los net binne die naamruimte op. Die gasheer se eie 127.0.0.1 is heeltemal 'n ander loopback.

Dit is waarom curl op die gasheer misluk terwyl dieselfde opdrag binne die naamruimte slaag. Die toepassing is gesond; die adres bestaan eenvoudig nie in die gasheer se stapel nie.

Publiseer een poort met 'n socat-sprong

socat oorbrug die twee stapels in gebruikersruimte, wat genoeg is wanneer 'n enkele TCP-poort moet oorgaan. Die gasheerkant luister op die LAN en begin vir elke aanvaarde verbinding 'n tweede socat binne die naamruimte wat aan die toepassing se loopback koppel. Die binneproses bereik die toepassing presies soos 'n plaaslike kliënt sou. Niks aan die naamruimte se roetering verander nie, so die toepassing bly die tonnel as sy enigste uitgang gebruik.

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

Die buitenste proses benodig root of die vermoë om die naamruimte binne te gaan. As die VPN val, verloor die toepassing sy pad en die gepubliseerde poort sluit, wat die gedrag is wat jy van 'n tronk wil hê.

Gebruik 'n veth-paar wanneer meer as een poort oorgaan

'n veth-paar is die regte antwoord wanneer verskeie poorte of protokolle moet oorgaan, of wanneer ander gashere verbindings moet begin. Een kant bly in die gasheer, die ander skuif in die naamruimte in, en 'n klein /30 gee beide kante 'n stabiele adres. 'n Gasheerroete stuur dan die naamruimte-adres oor die paar.

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

Moenie 'n verstekroete deur die gasheer byvoeg nie, tensy jy van plan is om die tronk te breek. Die tonnel moet die uitgang bly, so net die gepubliseerde diensadres is oor die paar bereikbaar. Gee die naamruimte ook sy eie resolver-lêer, want ip netns exec lees /etc/netns/vpn/resolv.conf en sonder dit is naamresolusie binne die tronk leeg.

Toets vanaf 'n ander masjien, nie die gasheer nie

Voer die toets vanaf 'n tweede masjien uit, want die gasheer kan 'n plaaslike luisteraar bereik deur paaie wat niks oor die LAN sê nie. Kyk eers waaraan die toepassing werklik binne die naamruimte gebind het, en koppel dan van buite aan die gepubliseerde adres. Om daar aan elke adres te bind, verbreed nie die tronk nie, want die wildcard behoort steeds aan die naamruimte en die LAN kan dit nie sien nie.

ip netns exec vpn ss -lntp

As die gasheerverbinding werk en die LAN-verbinding nie, is die ontbrekende stuk die sprong of die roete, nie die bindadres nie. Begin OpenVPN binne die naamruimte eerder as om 'n lewendige tun-toestel daarin te skuif, want om die koppelvlak te skuif skakel dit af en kan roetes uitvee wat jy dan nie van buite kan herstel nie. Hou die herstelopdragte op die konsole, nie binne die tronk nie.