ip netns exec و DNS: چرا نام‌ها درون فضای نام شکست می‌خورند

یک فرمان بدون هیچ شکایتی به 10.8.0.5 درون فضای نام VPN می‌رسد، و همان فرمان درست در لحظه‌ای که از نام میزبان استفاده می‌کند شکست می‌خورد. فضای نام رابط‌ها، مسیرها و سوکت‌های خودش را دارد؛ فایل حل‌کنندهٔ خودش را ندارد. مگر اینکه چیزی یکی را آنجا بگذارد، فرایند درون آن فایل /etc/resolv.conf میزبان را می‌خواند و از سروری می‌پرسد که ممکن است از آن پشتهٔ شبکه در دسترس نباشد.

این مسئلهٔ انتخاب فایل است نه مسئلهٔ مسیریابی، و دقیقاً به همین دلیل مقصد عددی هنوز کار می‌کند.

نمای حل‌کننده‌ای را که فرایند واقعاً می‌گیرد بررسی کنید

فرض نکنید پوسته‌ای که استفاده کرده‌اید با فرایندی که اشکال‌زدایی می‌کنید یکی است. یک برنامهٔ گرافیکی، یک واحد systemd و یک کانتینر هرکدام می‌توانند به بافت نصب یا شبکهٔ متفاوتی وارد شوند. جست‌وجو را از همان مسیر راه‌اندازی اجرا کنید و فایل حل‌کننده را از درون آن چاپ کنید.

برای فضای نامی که با ip netns add ساخته شده است، بررسی فقط‌خواندنی کوتاه است:

ip netns exec vpn cat /etc/resolv.conf

توجه کنید که نتیجه نشانی قابل‌دسترس، یک استاب loopback، یا پیوند نمادینی را نام می‌برد که به جایی با دسترس‌پذیری متفاوت اشاره می‌کند.

آنچه کمک‌کنندهٔ exec واقعاً نصب می‌کند

ابزار ip-netns پیکربندی هر فضای نام را زیر /etc/netns/NAME/ مستند می‌کند. وقتی فرایندی را راه‌اندازی می‌کند، کمک‌کننده یک فضای نام نصب می‌سازد و آن فایل‌ها را روی مسیرهای معمولشان نصب می‌کند، تا فرایند نسخهٔ مخصوص فضای نام را ببیند. این یک آسودگی از آنِ همین راه‌انداز است. ورود به فضای نام شبکه از راهی دیگر، مثل unshare یا یک رانتایم کانتینر، این را به‌طور خودکار بازتولید نمی‌کند.

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

حل‌کننده‌ای انتخاب کنید که فضای نام به آن دسترسی دارد

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

برنامه‌هایی با حل‌کنندهٔ خودشان، مثل آن‌که از DNS over HTTPS استفاده می‌کند، ممکن است فایل را کاملاً نادیده بگیرند. اگر ابزار تنظیم DNS خودش را داشته باشد، تغییر resolv.conf روی آن اثری نمی‌گذارد، و فضای نام هرگز مشکل نبود.

فایل را در جای درست بنویسید

فایل مخصوص هر فضای نام را زیر /etc/netns/NAME/resolv.conf بسازید و بگذارید راه‌انداز آن را ارائه کند. آن را کمینه نگه دارید: یکی دو سرور قابل‌دسترس و دامنه‌های جست‌وجویی که وظیفه لازم دارد. فایل حل‌کنندهٔ تولیدشدهٔ میزبان را برای درست‌کردن نمایی که برای یک گروه فرایند در نظر گرفته شده ویرایش نکنید، چون آن هر برنامه‌ای روی ماشین را تغییر می‌دهد. اگر میزبان از مدیر حل‌کننده استفاده می‌کند، مسیر فضای نام را از طریق همان مدیر پیکربندی کنید، نه با جنگیدن با آن.

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

کل مسیر را دوباره آزمایش کنید

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

تأیید کنید که فرایند، نه پوسته، فایل را دریافت می‌کند. جست‌وجویی که از یک پوستهٔ تعاملی کار می‌کند و از یک سرویس شکست می‌خورد یافته‌ای دربارهٔ بافت نصب است، و ارزش دارد پیش از حادثهٔ بعدی نوشته شود، نه اینکه از صفر دوباره کشف شود.