Ang app sa loob ng VPN namespace ay hindi maabot mula sa LAN

Gumagana ang serbisyo mo sa makina, nakataas ang tunnel, ngunit ang browser sa iyong mesa ay naghihintay pa rin ng sagot. Walang sira sa karaniwang kahulugan: nakikinig ang aplikasyon sa loob ng network namespace, at ang stack na iyon ay hindi nakikita ng LAN. Pag-aari ng namespace ang loopback nito, kaya ang kliyente sa ibang makina ay walang address na umaabot sa port. Isang sinadyang hop, o isang veth pair, ang nag-aayos nito nang hindi ginagalaw ang natitirang bahagi ng host.

Bakit walang sumasagot sa address ng LAN

Ang namespace ay isang buong network stack: mga interface, ruta, panuntunan ng firewall at pribadong loopback. Ang prosesong inilunsad sa pamamagitan ng ip netns exec ay nakikita lamang ang stack na iyon at wala nang iba, kaya ang address na binibigkisan nito ay nareresolba lamang sa loob ng namespace. Ang sariling 127.0.0.1 ng host ay lubos na ibang loopback.

Kaya nabibigo ang curl sa host habang nagtatagumpay ang parehong utos sa loob ng namespace. Malusog ang aplikasyon; wala lang talaga ang address sa stack ng host.

I-publish ang isang port gamit ang socat hop

Inuugnay ng socat ang dalawang stack sa userspace, na sapat kapag isang TCP port lang ang kailangang tumawid. Nakikinig ang panig ng host sa LAN at, para sa bawat tinanggap na koneksyon, naglulunsad ng pangalawang socat sa loob ng namespace na kumokonekta sa loopback ng app. Naabot ng panloob na proseso ang aplikasyon kung paano mismo gagawin ng lokal na kliyente. Walang nababago sa routing ng namespace, kaya patuloy na ginagamit ng app ang tunnel bilang tanging labasan nito.

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

Kailangan ng panlabas na proseso ng root o ang kakayahang pumasok sa namespace. Kung bumagsak ang VPN, nawawala ang landas ng app at nabibigo nang sarado ang na-publish na port, at iyon ang pag-uugaling gusto mo mula sa isang kulungan.

Gumamit ng veth pair kapag higit sa isang port ang tumatawid

Ang veth pair ang tamang sagot kapag maraming port o protocol ang kailangang tumawid, o kapag kailangang magsimula ng koneksyon ang ibang host. Nanatili ang isang dulo sa host, lumipat ang isa sa namespace, at binibigyan ng maliit na /30 ang dalawang panig ng matatag na address. Pagkatapos, ipinapadala ng ruta ng host ang address ng namespace sa pares.

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

Huwag magdagdag ng default na ruta sa pamamagitan ng host maliban kung balak mong sirain ang kulungan. Dapat manatiling labasan ang tunnel, kaya sa pares ay naaabot lamang ang na-publish na address ng serbisyo. Bigyan din ang namespace ng sariling resolver file, dahil binabasa ng ip netns exec ang /etc/netns/vpn/resolv.conf at kung wala ito, walang laman ang paglutas ng pangalan sa loob ng kulungan.

Subukan mula sa ibang makina, hindi mula sa host

Patakbuhin ang pagsubok mula sa pangalawang makina, dahil naaabot ng host ang lokal na tagapakinig sa mga landas na walang sinasabi tungkol sa LAN. Tingnan muna kung ano talaga ang binigkisan ng aplikasyon sa loob ng namespace, pagkatapos kumonekta mula sa labas sa na-publish na address. Ang pagbigkis sa bawat address doon ay hindi nagpapalawak ng kulungan, dahil pag-aari pa rin ng namespace ang wildcard at hindi ito nakikita ng LAN.

ip netns exec vpn ss -lntp

Kung gumagana ang koneksyon mula sa host at hindi ang mula sa LAN, ang kulang na piraso ay ang hop o ang ruta, hindi ang address ng bigkis. Simulan ang OpenVPN sa loob ng namespace sa halip na ilipat doon ang buhay na tun device, dahil ang paglipat ng interface ay pinapatay ito at maaaring magbura ng mga rutang hindi mo na maaayos mula sa labas. Itago ang mga utos sa pagbawi sa console, hindi sa loob ng kulungan.