En app i et VPN-navnerum er ikke tilgængelig fra LAN

Din tjeneste kører på maskinen, tunnelen er oppe, og browseren på dit skrivebord venter stadig forgæves. Intet er i stykker i sædvanlig forstand: applikationen lytter inde i et netværksnavnerum, og den stak er usynlig for LAN. Dens loopback tilhører navnerummet, så en klient på en anden maskine har ingen adresse, der når porten. Et enkelt bevidst hop, eller et enkelt veth-par, retter det uden at flytte resten af værten.

Hvorfor intet svarer på LAN-adressen

Et navnerum er en komplet netværksstak: grænseflader, ruter, firewallregler og en privat loopback. En proces startet gennem ip netns exec ser den stak og intet andet, så den adresse, den binder til, opløses kun inde i navnerummet. Værtens egen 127.0.0.1 er en helt anden loopback.

Derfor fejler curl på værten, mens den samme kommando inde i navnerummet lykkes. Applikationen er sund; adressen findes ganske enkelt ikke i værtens stak.

Udgiv én port med et socat-hop

socat bygger bro mellem de to stakke i brugerrummet, og det er nok, når én enkelt TCP-port skal krydse. Værtsiden lytter på LAN og starter for hver accepteret forbindelse en anden socat inde i navnerummet, som opretter forbindelse til appens loopback. Den indre proces når applikationen præcis som en lokal klient ville. Intet i navnerummets routing ændres, så appen fortsætter med at bruge tunnelen som sin eneste udgang.

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

Den ydre proces kræver root eller rettigheden til at gå ind i navnerummet. Hvis VPN'en falder, mister appen sin vej, og den udgivne port fejler lukket, hvilket er den adfærd, du ønsker af et fængsel.

Brug et veth-par, når mere end én port skal krydse

Et veth-par er det rigtige svar, når flere porte eller protokoller skal krydse, eller når andre værter skal starte forbindelser. Den ene ende bliver i værten, den anden flytter ind i navnerummet, og et lille /30 giver begge sider en stabil adresse. En værtsrute sender derefter navnerummets adresse over parret.

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

Tilføj ikke en standardrute gennem værten, medmindre du har til hensigt at bryde fængslet. Tunnelen skal forblive udgangen, så kun den udgivne tjenesteadresse er nåelig over parret. Giv også navnerummet sin egen resolver-fil, fordi ip netns exec læser /etc/netns/vpn/resolv.conf, og uden den er navneopløsningen inde i fængslet tom.

Test fra en anden maskine, ikke fra værten

Kør testen fra en anden maskine, fordi værten kan nå en lokal lytter ad veje, der intet siger om LAN. Kontroller først, hvad applikationen faktisk bandt til inde i navnerummet, og opret derefter forbindelse til den udgivne adresse udefra. At binde til alle adresser der udvider ikke fængslet, fordi jokertegnet stadig tilhører navnerummet, og LAN kan ikke se det.

ip netns exec vpn ss -lntp

Hvis værtsforbindelsen virker, og LAN-forbindelsen ikke gør, er det manglende stykke hoppet eller ruten, ikke bindeadressen. Start OpenVPN inde i navnerummet i stedet for at flytte en levende tun-enhed ind i det, da flytning af grænsefladen tager den ned og kan rydde ruter, som du derefter ikke kan reparere udefra. Hold gendannelseskommandoerne på konsollen, ikke inde i fængslet.