A VPN-névtérben futó alkalmazás nem érhető el a LAN-ról

A szolgáltatás fut a gépen, az alagút él, és az asztalán lévő böngésző mégis válaszra vár. Semmi sem hibás a szokásos értelemben: az alkalmazás egy hálózati névtéren belül figyel, és az a verem a LAN számára láthatatlan. A loopbackje a névtérhez tartozik, ezért egy másik gépen lévő kliensnek nincs olyan címe, amely elérné a portot. Egy szándékos ugrás, vagy egy veth-pár megoldja ezt anélkül, hogy a gazdagép többi részét mozgatná.

Miért nem válaszol semmi a LAN-címen

A névtér teljes hálózati verem: interfészek, útvonalak, tűzfal-szabályok és egy privát loopback. Az ip netns exec segítségével indított folyamat csak ezt a vermet látja és semmi mást, ezért a cím, amelyhez kötődik, csak a névtéren belül oldódik fel. A gazdagép saját 127.0.0.1 címe teljesen más loopback.

Ezért hiúsul meg a curl a gazdagépen, miközben ugyanaz a parancs a névtéren belül sikerül. Az alkalmazás egészséges; a cím egyszerűen nem létezik a gazdagép vermében.

Tegyen közzé egy portot socat-ugrással

A socat felhasználói térben hidalja át a két vermet, ami elég, ha egyetlen TCP-portnak kell átkelnie. A gazdagép oldala a LAN-on figyel, és minden elfogadott kapcsolatnál egy második socatot indít a névtéren belül, amely az alkalmazás loopbackjéhez csatlakozik. A belső folyamat pontosan úgy éri el az alkalmazást, ahogy egy helyi kliens tenné. A névtér útválasztásában semmi sem változik, ezért az alkalmazás továbbra is az alagutat használja egyetlen kijárataként.

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

A külső folyamatnak rootra vagy a névtérbe való belépés képességére van szüksége. Ha a VPN leszakad, az alkalmazás elveszíti az útját, és a közzétett port zárt állapotban hibázik, ez az a viselkedés, amit egy börtöntől vár.

Használjon veth-párt, ha egynél több port kel át

A veth-pár a helyes válasz, ha több portnak vagy protokollnak kell átkelnie, vagy ha más gazdagépeknek kell kapcsolatot kezdeményezniük. Az egyik vég a gazdagépen marad, a másik átkerül a névtérbe, és egy kis /30 mindkét oldalnak stabil címet ad. Ezután egy gazdagép-útvonal küldi a névtér címét a páron át.

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

Ne adjon hozzá alapértelmezett útvonalat a gazdagépen át, hacsak nem akarja feltörni a börtönt. Az alagútnak kell maradnia a kijáratnak, ezért a páron át csak a közzétett szolgáltatáscím érhető el. Adjon a névtérnek saját feloldófájlt is, mert az ip netns exec a /etc/netns/vpn/resolv.conf fájlt olvassa, és nélküle a névfeloldás a börtönben üres.

Teszteljen másik gépről, ne a gazdagépről

Futtassa a tesztet egy második gépről, mert a gazdagép olyan útvonalakon érhet el helyi hallgatót, amelyek semmit nem mondanak a LAN-ról. Először ellenőrizze, mihez kötődött valójában az alkalmazás a névtéren belül, majd kívülről csatlakozzon a közzétett címhez. Az ottani összes címre kötés nem szélesíti a börtönt, mert a helyettesítő karakter továbbra is a névtérhez tartozik, és a LAN nem láthatja.

ip netns exec vpn ss -lntp

Ha a gazdagépről induló kapcsolat működik, a LAN-ról induló pedig nem, a hiányzó rész az ugrás vagy az útvonal, nem a kötési cím. Indítsa az OpenVPN-t a névtéren belül, ahelyett hogy élő tun-eszközt mozgatna bele, mert az interfész mozgatása lekapcsolja, és olyan útvonalakat törölhet, amelyeket utána kívülről nem tud megjavítani. Tartsa a helyreállítási parancsokat a konzolon, ne a börtönben.