Síťové jmenné prostory Linuxu pro VPN: co neizolují

Spusťte VPN uvnitř jejího vlastního jmenného prostoru, spusťte tam jednu aplikaci, a provoz přesto odchází přes trasu hostitele. Nic není rozbité: jmenný prostor řídí jen procesy, které do něj vstoupí, a únik přišel z procesu, který do něj nikdy nevstoupil. Rozhraní, adresy, trasy, pravidla firewallu a sockety jsou to, co jmenný prostor vlastní. Soubory, účty a už běžící služby ne, a odtud pochází většina překvapení.

Co jmenný prostor vlastní a kde se rodí socket

Přesuňte rozhraní do jmenného prostoru a hostitel o něj přijde; postavte uvnitř tunel a hostitel ho neuvidí. To je mechanismus VPN omezené na jmenný prostor: zařízení a trasy k němu žijí v kontextu, kam se dostanou jen vybrané procesy. Hostitel si ponechá výchozí trasu, takže vše venku zůstává nedotčeno.

U WireGuardu je kontext vytvoření stejně důležitý jako aktuální umístění: socket UDP se váže ve jmenném prostoru, kde bylo rozhraní vytvořeno, i poté, co se zařízení přesune jinam. Kterou směrovací tabulku šifrované pakety sledují, závisí na tomto místě zrození. Když socket zůstane v kontextu bez trasy k protějšku, rozhraní se dotazuje a handshake nikdy neodejde. Zkontrolujte místo jeho zrození, pak jeho aktuální umístění.

Co jmenný prostor neizoluje

Nic zde neodděluje souborové systémy, účty ani tajemství, a žádná z těchto hranic nevzniká proto, že jste vytvořili jmenný prostor. Konfigurace resolveru je soubor, takže proces uvnitř může stále přečíst nastavení ukazující na resolver hostitele a odeslat svůj dotaz trasou, kterou to implikuje. Aplikace, která předá požadavek už běžícímu zprostředkovateli nebo systémové službě, zahrnuje proces ve zcela jiném kontextu. Oba jsou požadavky, na které hranice nikdy neměla odpovídat.

Řešením je soubor pro každý jmenný prostor v /etc/netns/<name>/resolv.conf, nebo bind mount připraveného souboru, namířený na resolver dostupný zevnitř. Úprava /etc/resolv.conf na hostiteli nemění nic, co jmenný prostor vidí.

Umístění procesů je ovládací prvek

Izolace, kterou dostanete, je přesně izolací procesů, které spustíte uvnitř. Shell spuštěný přes pomocník exec jmenného prostoru a vše, co vyplodí, zůstává uvnitř; desktopová aplikace spuštěná ze sezení hostitele ne. Vytvořte kontext, přesuňte zařízení a pak dokažte obě strany:

ip netns add vpn1
ip link set wg0 netns vpn1
ip netns exec vpn1 wg show
wg show

Přečtěte první wg show zevnitř jmenného prostoru a druhý z hostitele a očekávejte, že jen jeden z nich vypíše protějšek. Pokud oba, zařízení se nikdy nepřesunulo; pokud ani jeden, odešlo jinam. Když je spouštěčem správce služeb, upravovat se má soubor jednotky, ne zástupce na ploše. Jednotka bez nastavení jmenného prostoru spustí démona v kontextu hostitele a tiše zruší návrh.

Testujte z kontextu aplikace

Spusťte kontrolu se stejným binárním souborem a stejným uživatelem, jaké používá aplikace, uvnitř jmenného prostoru. Zahrňte DNS a obě rodiny adres, protože trasa IPv6, na kterou jste nemysleli, je běžná cesta ven. Test z vašeho vlastního shellu dokazuje jen to, že váš shell je izolovaný.

Pak spusťte totožnou kontrolu na hostiteli a potvrďte, že odpovědi se liší: adresa tunelu a zamýšlený odchod uvnitř, trasa hostitele a kancelářský odchod venku, a resolver podle jména. Pojmenujte jmenné prostory podle nasazení, ne podle protokolu, aby si úklidový skript nespletl dva z nich.

Přeposílání, politika selhání a úklid

U brány zapněte přeposílání vědomě a rozhodněte, co se má stát, když tunel spadne. Jmenný prostor neblokuje trasy, které v něm nainstalujete, takže záložní trasa k hostiteli se použije, pokud ji vytvoříte. To je politické rozhodnutí a mělo by být zapsáno dřív, než ho otestuje výpadek.

Zaznamenejte názvy jmenných prostorů, rozhraní a kdo vlastní konfiguraci, aby úklid odstranil jen to, co nasazení vytvořilo. Reset síťování hostitele během vracení změní úklid ve výpadek. network_namespaces(7) je krátká stránka a stojí za přečtení, než tuto cestu navrhnete.