Programa VPN vardų erdvėje nepasiekiama iš LAN

Tinklo vardų erdvė suteikia vienai programai savo tunelį ir savo loopback. Skelbkite tik jo portą per socat šuolį arba veth porą, o ne per visą hostą.

Jūsų tarnyba veikia mašinoje, tunelis pakeltas, o naršyklė ant jūsų stalo vis dar laukia atsakymo. Įprasta prasme niekas nesugedę: programa klausosi tinklo vardų erdvės viduje, ir ta krūva yra nematoma LAN tinklui. Jos loopback priklauso vardų erdvei, todėl klientas kitoje mašinoje neturi adreso, kuris pasiektų portą. Vienas sąmoningas šuolis arba viena veth pora tai ištaiso nejudinant likusio hosto.

Kodėl LAN adresu niekas neatsako

Vardų erdvė yra visa tinklo krūva: sąsajos, maršrutai, ugniasienės taisyklės ir privatus loopback. Procesas, paleistas per ip netns exec, mato tik šią krūvą ir nieko daugiau, todėl adresas, prie kurio jis jungiasi, sprendžiamas tik vardų erdvės viduje. Pačio hosto 127.0.0.1 yra visiškai kitas loopback.

Štai kodėl curl hoste nepavyksta, o ta pati komanda vardų erdvės viduje pavyksta. Programa sveika; adreso tiesiog nėra hosto krūvoje.

Paskelbkite vieną portą socat šuoliu

socat sujungia dvi krūvas vartotojo erdvėje, ir to pakanka, kai turi praeiti vienas TCP portas. Hosto pusė klausosi LAN tinkle ir kiekvienam priimtam ryšiui vardų erdvės viduje paleidžia antrą socat, kuris jungiasi prie programos loopback. Vidinis procesas pasiekia programą lygiai taip, kaip tai darytų vietinis klientas. Vardų erdvės maršrutizavimas nesikeičia, todėl programa toliau naudoja tunelį kaip vienintelį išėjimą.

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

Išoriniam procesui reikia root arba galimybės įeiti į vardų erdvę. Jei VPN nukrenta, programa praranda kelią, o paskelbtas portas užsidaro, ir būtent tokio elgesio norite iš kalėjimo.

Naudokite veth porą, kai praeina daugiau nei vienas portas

veth pora yra teisingas atsakymas, kai turi praeiti keli portai ar protokolai arba kai kiti hostai turi inicijuoti ryšius. Vienas galas lieka hoste, kitas persikelia į vardų erdvę, o mažas /30 abiem pusėms suteikia stabilų adresą. Tada hosto maršrutas siunčia vardų erdvės adresą per porą.

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

Nepridėkite numatytojo maršruto per hostą, nebent ketinate sulaužyti kalėjimą. Tunelis turi likti išėjimu, todėl per porą pasiekiamas tik paskelbtas paslaugos adresas. Duokite vardų erdvei ir savo resolver failą, nes ip netns exec skaito /etc/netns/vpn/resolv.conf, o be jo vardų sprendimas kalėjimo viduje tuščias.

Testuokite iš kitos mašinos, ne iš hosto

Vykdykite testą iš antros mašinos, nes hostas gali pasiekti vietinį klausytoją keliais, kurie nieko nesako apie LAN. Pirmiausia patikrinkite, prie ko programa iš tikrųjų prisijungė vardų erdvės viduje, tada iš išorės prisijunkite prie paskelbto adreso. Prisijungimas prie visų adresų ten nepadidina kalėjimo, nes pakaitos simbolis vis dar priklauso vardų erdvei, o LAN jo negali matyti.

ip netns exec vpn ss -lntp

Jei ryšys iš hosto veikia, o iš LAN ne, trūkstama dalis yra šuolis ar maršrutas, o ne prisijungimo adresas. Paleiskite OpenVPN vardų erdvės viduje, o ne perkelkite ten veikiantį tun įrenginį, nes sąsajos perkėlimas ją išjungia ir gali išvalyti maršrutus, kurių vėliau iš išorės nesutaisysite. Laikykite atkūrimo komandas konsolėje, o ne kalėjimo viduje.

Susiję straipsniai