App inne i et VPN-navnerom er ikke tilgjengelig fra LAN

Et nettverksnavnerom gir ett program sin egen tunnel og sin egen loopback. Publiser bare porten med et socat-hopp eller et veth-par i stedet for verten.

Tjenesten din kjører på maskinen, tunnelen er oppe, og likevel venter nettleseren på skrivebordet ditt fortsatt på svar. Ingenting er ødelagt i vanlig forstand: applikasjonen lytter inne i et nettverksnavnerom, og den stakken er usynlig for LAN-et. Loopback-en tilhører navnerommet, så en klient på en annen maskin har ingen adresse som når porten. Ett bevisst hopp, eller ett veth-par, ordner det uten å flytte resten av verten.

Hvorfor ingenting svarer på LAN-adressen

Et navnerom er en komplett nettverksstakk: grensesnitt, ruter, brannmurregler og en privat loopback. En prosess startet gjennom ip netns exec ser den stakken og ingenting annet, så adressen den binder til løses bare inne i navnerommet. Vertens egen 127.0.0.1 er en helt annen loopback.

Derfor feiler curl på verten mens den samme kommandoen inne i navnerommet lykkes. Applikasjonen er sunn; adressen finnes rett og slett ikke i vertens stakk.

Publiser én port med et socat-hopp

socat bygger bro mellom de to stakkene i brukerrommet, og det er nok når én enkelt TCP-port skal krysse. Vertsiden lytter på LAN-et og starter for hver aksepterte tilkobling en andre socat inne i navnerommet som kobler til appens loopback. Den indre prosessen når applikasjonen akkurat slik en lokal klient ville gjort. Ingenting i rutingen til navnerommet endres, så appen fortsetter å bruke tunnelen som sin eneste utgang.

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

Den ytre prosessen trenger root eller rettigheten til å gå inn i navnerommet. Hvis VPN-et faller, mister appen veien sin, og den publiserte porten feiler lukket, og det er oppførselen du vil ha fra et fengsel.

Bruk et veth-par når mer enn én port krysser

Et veth-par er det riktige svaret når flere porter eller protokoller må krysse, eller når andre verter må starte tilkoblinger. Den ene enden blir i verten, den andre flyttes inn i navnerommet, og en liten /30 gir begge sider en stabil adresse. En vertsrute sender deretter navnerommets adresse over paret.

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

Ikke legg til en standardrute gjennom verten med mindre du har tenkt å bryte fengslet. Tunnelen skal forbli utgangen, så bare den publiserte tjenesteadressen er nåbar over paret. Gi navnerommet også sin egen resolver-fil, fordi ip netns exec leser /etc/netns/vpn/resolv.conf, og uten den er navneoppslaget inne i fengslet tomt.

Test fra en annen maskin, ikke fra verten

Kjør testen fra en annen maskin, fordi verten kan nå en lokal lytter via veier som ikke sier noe om LAN-et. Sjekk først hva applikasjonen faktisk bandt til inne i navnerommet, og koble deretter til den publiserte adressen utenfra. Å binde til hver adresse der utvider ikke fengslet, fordi jokertegnet fortsatt tilhører navnerommet, og LAN-et kan ikke se det.

ip netns exec vpn ss -lntp

Hvis tilkoblingen fra verten virker og tilkoblingen fra LAN-et ikke, er den manglende delen hoppet eller ruten, ikke bindeadressen. Start OpenVPN inne i navnerommet i stedet for å flytte en levende tun-enhet inn i det, siden flytting av grensesnittet tar det ned og kan fjerne ruter du deretter ikke kan reparere utenfra. Hold gjenopprettingskommandoene på konsollen, ikke inne i fengslet.

Relaterte artikler