Mga network namespace ng Linux para sa VPN: ano ang hindi nila inihihiwalay

Simulan ang VPN sa loob ng sarili nitong namespace, magpatakbo ng isang aplikasyon doon, at lumalabas pa rin ang trapiko sa ruta ng host. Walang sira: ang namespace ay namamahala lamang sa mga prosesong pumapasok dito, at ang pagtagas ay nagmula sa isang prosesong hindi kailanman pumasok. Ang mga interface, address, ruta, patakaran ng firewall at socket ang pagmamay-ari ng namespace. Ang mga file, account at tumatakbong serbisyo ay hindi, at doon nagmumula ang karamihan ng sorpresa.

Ano ang pagmamay-ari ng namespace, at saan isinilang ang socket

Ilipat ang isang interface sa namespace at mawawala ito sa host; gumawa ng tunnel sa loob at hindi ito makikita ng host. Ito ang mekanismo ng VPN na limitado sa namespace: ang device at ang mga rutang nakaturo rito ay naninirahan sa isang kontekstong naaabot lamang ng mga piling proseso. Pinapanatili ng host ang default na ruta nito, kaya nananatiling hindi ginalaw ang lahat sa labas.

Para sa WireGuard, kasinghalaga ng kasalukuyang lokasyon ang konteksto ng paglikha: ang UDP socket ay itinatali sa namespace kung saan ginawa ang interface, kahit na lumipat pa ang device sa ibang lugar. Kung aling routing table susundin ng mga naka-encrypt na packet ay nakasalalay sa lugar ng kapanganakan na iyon. Kapag nanatili ang socket sa kontekstong walang ruta patungo sa kapareha, naghahanap ang interface at hindi kailanman lumalabas ang pakikipagkamay. Suriin ang lugar ng kapanganakan nito, pagkatapos ang kasalukuyang lokasyon.

Ano ang hindi inihihiwalay ng namespace

Walang anuman dito ang naghihiwalay ng mga filesystem, account o lihim, at wala sa mga hangganang iyon ang lumilitaw dahil gumawa ka ng namespace. Ang configuration ng resolver ay isang file, kaya ang proseso sa loob ay makakabasa pa rin ng setting na nakaturo sa resolver ng host at maipapadala ang query nito sa rutang ipinahihiwatig nito. Ang aplikasyong nagbibigay ng kahilingan sa tumatakbong broker o serbisyo ng system ay nagsasangkot ng proseso sa ganap na ibang konteksto. Pareho silang kahilingang hindi kailanman nilayon na sagutin ng hangganan.

Ang solusyon ay isang file kada namespace sa /etc/netns/<name>/resolv.conf, o isang bind mount ng inihandang file, na nakaturo sa resolver na naaabot mula sa loob. Ang pag-edit ng /etc/resolv.conf sa host ay walang binabago sa nakikita ng namespace.

Ang paglalagay ng mga proseso ang kontrol

Ang paghihiwalay na nakukuha mo ay eksaktong paghihiwalay ng mga prosesong sinimulan mo sa loob. Ang shell na sinimulan sa pamamagitan ng exec helper ng namespace, at lahat ng nililikha nito, ay nananatili sa loob; ang desktop application na inilunsad mula sa session ng host ay hindi. Gumawa ng konteksto, ilipat ang device, pagkatapos patunayan ang dalawang panig:

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

Basahin ang unang wg show mula sa loob ng namespace at ang pangalawa mula sa host, at asahan na isa lamang sa kanila ang maglilista ng kapareha. Kung pareho silang gumawa, hindi kailanman gumalaw ang device; kung wala, pumunta ito sa ibang lugar. Kapag ang launcher ay isang service manager, ang unit file ang dapat i-edit, hindi ang shortcut sa desktop. Ang unit na walang setting ng namespace ay nagsisimula ng daemon sa konteksto ng host at tahimik na binabalewala ang disenyo.

Subukan mula sa konteksto ng aplikasyon

Patakbuhin ang pagsusuri gamit ang parehong binary at parehong user na ginagamit ng aplikasyon, sa loob ng namespace. Isama ang DNS at parehong pamilya ng address, dahil ang rutang IPv6 na hindi mo kailanman naisip ay karaniwang labasan. Ang pagsubok mula sa sarili mong shell ay nagpapatunay lamang na ang shell mo ay nakahiwalay.

Pagkatapos patakbuhin ang parehong pagsusuri sa host at tiyakin na magkaiba ang mga sagot: address ng tunnel at nilalayong labasan sa loob, ruta ng host at labasan ng opisina sa labas, at ang resolver sa pangalan. Pangalanan ang mga namespace ayon sa deployment at hindi sa protocol, upang hindi malito ng script ng paglilinis ang dalawa.

Pagpapasa, patakaran sa pagkabigo at paglilinis

Para sa isang gateway, sadyang i-on ang pagpapasa at magpasya kung ano ang dapat mangyari kapag bumagsak ang tunnel. Hindi hinaharangan ng namespace ang mga rutang ini-install mo sa loob, kaya gagamitin ang fallback na ruta patungo sa host kung gagawa ka ng isa. Desisyon ito sa patakaran, at dapat itong isulat bago pa ito subukan ng isang pagkaabala.

Itala ang mga pangalan ng namespace, ang mga interface at kung kanino ang configuration, upang ang paglilinis ay magtanggal lamang ng ginawa ng deployment. Ang pag-reset ng network ng host habang nag-ro-rollback ay ginagawang pagkaabala ang paglilinis. Ang pahina network_namespaces(7) ay maikli at sulit basahin bago mo idisenyo ang rutang iyon.