فضاهای نام شبکه لینوکس برای VPN: چه چیزهایی را جدا نمی‌کنند

VPN را درون فضای نام خودش اجرا کنید، یک برنامه را همان‌جا اجرا کنید، و ترافیک همچنان از مسیر میزبان خارج می‌شود. هیچ چیز خراب نیست: فضای نام فقط فرایندهایی را که به آن وارد می‌شوند کنترل می‌کند، و نشت از فرایندی آمد که هرگز وارد نشد. رابط‌ها، نشانی‌ها، مسیرها، قواعد دیوار آتش و سوکت‌ها چیزهایی هستند که فضای نام مالک آن‌هاست. فایل‌ها، حساب‌ها و سرویس‌های در حال اجرا چنین نیستند، و بیشتر غافلگیری‌ها از همین‌جا می‌آید.

فضای نام چه چیزی را مالک است و سوکت کجا زاده می‌شود

یک رابط را به فضای نام منتقل کنید و میزبان آن را از دست می‌دهد؛ درون آن تونلی بسازید و میزبان نمی‌تواند آن را ببیند. این سازوکار VPN محدود به فضای نام است: دستگاه و مسیرهایی که به آن اشاره می‌کنند در زمینه‌ای زندگی می‌کنند که فقط فرایندهای برگزیده به آن می‌رسند. میزبان مسیر پیش‌فرض خود را نگه می‌دارد، پس هر چیزی در بیرون دست‌نخورده می‌ماند.

برای WireGuard، زمینهٔ ایجاد به‌اندازهٔ مکان کنونی مهم است: سوکت UDP در همان فضای نامی بسته می‌شود که رابط در آن ساخته شده، حتی پس از آنکه دستگاه جای دیگری می‌رود. اینکه بسته‌های رمزگذاری‌شده از کدام جدول مسیریابی پیروی کنند به همان زادگاه بستگی دارد. وقتی سوکت در زمینه‌ای می‌ماند که مسیری به همتا ندارد، رابط جست‌وجو می‌کند و دست‌دادن هرگز بیرون نمی‌رود. ابتدا زادگاهش را بررسی کنید، سپس مکان کنونی‌اش را.

فضای نام چه چیزی را جدا نمی‌کند

هیچ چیز اینجا فایل‌سیستم‌ها، حساب‌ها یا رازها را جدا نمی‌کند، و هیچ‌یک از این مرزها به این دلیل که فضای نام ساخته‌اید پدید نمی‌آید. پیکربندی resolver یک فایل است، بنابراین فرایندی درون آن همچنان می‌تواند تنظیمی را بخواند که به resolver میزبان اشاره می‌کند و پرس‌وجوی خود را از مسیری که این اقتضا می‌کند بیرون بفرستد. برنامه‌ای که درخواست را به یک واسطه یا سرویس سیستمی در حال اجرا می‌سپارد، فرایندی در زمینه‌ای کاملاً دیگر را درگیر می‌کند. هر دو درخواست‌هایی هستند که مرز هرگز برای پاسخ‌دادن به آن‌ها ساخته نشده بود.

راه‌حل یک فایل به‌ازای هر فضای نام در /etc/netns/<name>/resolv.conf است، یا bind mount از یک فایل آماده که به resolver قابل دسترس از درون اشاره کند. ویرایش /etc/resolv.conf روی میزبان هیچ‌چیز از آنچه فضای نام می‌بیند را تغییر نمی‌دهد.

قرارگیری فرایندها همان کنترل است

جداسازی‌ای که به دست می‌آورید دقیقاً جداسازی فرایندهایی است که درون آن آغاز می‌کنید. پوسته‌ای که از طریق کمک‌کنندهٔ exec فضای نام آغاز شود، و هر چیزی که تولید کند، درون می‌ماند؛ برنامهٔ میزکاری که از نشست میزبان اجرا شود، نه. زمینه را بسازید، دستگاه را جابه‌جا کنید، سپس هر دو سو را اثبات کنید:

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

اولین wg show را از درون فضای نام و دومی را از میزبان بخوانید و انتظار داشته باشید فقط یکی از آن‌ها همتا را فهرست کند. اگر هر دو چنین کنند، دستگاه هرگز جابه‌جا نشده است؛ اگر هیچ‌کدام، به جای دیگری رفته است. وقتی راه‌انداز یک مدیر سرویس است، فایل unit چیزی است که باید ویرایش شود، نه میان‌بر میزکار. واحدی بدون تنظیم فضای نام، سرویس را در زمینهٔ میزبان آغاز می‌کند و طراحی را بی‌صدا باطل می‌کند.

از زمینهٔ برنامه آزمایش کنید

بررسی را با همان فایل اجرایی و همان کاربری که برنامه استفاده می‌کند، درون فضای نام اجرا کنید. DNS و هر دو خانوادهٔ نشانی را بگنجانید، زیرا مسیر IPv6‌ای که هرگز به آن فکر نکردید راه خروج رایجی است. آزمایش از پوستهٔ خودتان فقط ثابت می‌کند که پوستهٔ شما جدا شده است.

سپس همان بررسی را روی میزبان اجرا کنید و تأیید کنید که پاسخ‌ها متفاوت‌اند: نشانی تونل و خروج موردنظر در درون، مسیر میزبان و خروج دفتر در بیرون، و resolver به نام. فضاهای نام را بر اساس استقرار نام‌گذاری کنید نه بر اساس پروتکل، تا اسکریپت پاک‌سازی دو مورد را اشتباه نگیرد.

ارسال، سیاست خرابی و پاک‌سازی

برای یک دروازه، ارسال را آگاهانه روشن کنید و تصمیم بگیرید وقتی تونل می‌افتد چه باید رخ دهد. فضای نام مسیرهایی را که درون آن نصب می‌کنید مسدود نمی‌کند، پس اگر مسیر جایگزینی به میزبان بسازید از آن استفاده خواهد شد. این یک تصمیم سیاستی است و باید پیش از آنکه یک قطعی آن را بیازماید نوشته شود.

نام فضاهای نام، رابط‌ها و اینکه پیکربندی از کیست را ثبت کنید، تا پاک‌سازی فقط چیزی را که استقرار ساخته حذف کند. بازنشانی شبکهٔ میزبان در حین بازگردانی، پاک‌سازی را به قطعی تبدیل می‌کند. صفحهٔ network_namespaces(7) کوتاه است و ارزش خواندن پیش از طراحی آن مسیر را دارد.