چرا ورودی /etc/hosts شما به DNS شبکه VPN نمی‌رسد

شما نامی را به /etc/hosts اضافه کردید، به VPN وصل شدید و انتظار داشتید رکورد برای همه ظاهر شود. این اتفاق نمی‌افتد و غافلگیری معمولاً با نشانه دوم همراه است: نام روی دستگاه شما حل می‌شود و روی دستگاه همکارتان شکست می‌خورد، که شبیه سرویس DNS معیوب VPN به نظر می‌رسد و در واقع فایل hosts دقیقاً همان کاری را می‌کند که برای آن طراحی شده است. فایل hosts پیکربندی محلی حل نام است، نه به‌روزرسانی ناحیه، و هیچ چیز در یک اتصال عادی VPN آن را بارگذاری نمی‌کند.

Hosts یک بازنویسی محلی است، نه به‌روزرسانی ناحیه

این فایل فهرستی از نگاشت‌هاست که کتابخانه‌های سرویس نام پیش از پرسیدن از سرور DNS یا به‌جای آن به آن مراجعه می‌کنند. خطی مانند 10.40.0.20 build.corp.example آنچه برنامه‌ها روی همان یک دستگاه نتیجه می‌گیرند را تغییر می‌دهد. رکوردی ایجاد نمی‌کند، از تونل عبور نمی‌کند، و سرور DNS که تونل به آن اشاره می‌کند هیچ اطلاعی از وجودش ندارد.

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

دو فرمان، دو مؤلفه متفاوت

سریع‌ترین راه پایان دادن به این بحث این است که تفاوت را در دو فرمان قابل مشاهده کنید، هر دو روی کلاینتی که ورودی hosts را دارد اجرا می‌شوند:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

اولی مسیر جستجوی خود سیستم را می‌پرسد که در یک سیستم معمول glibc فایل‌های محلی را پیش از DNS می‌خواند. دومی یک پرسش DNS را مستقیماً به سرور در آن نشانی می‌فرستد و اصلاً به فایل‌های محلی مراجعه نمی‌کند. وقتی اولی ورودی شما را برمی‌گرداند و دومی NXDOMAIN را، ثابت کرده‌اید که رکورد در DNS وجود ندارد و دستگاه شما از یک بازنویسی محلی پاسخ می‌دهد.

ترتیب قابل پیکربندی است و ارزش دارد پیش از هر نتیجه‌گیری درباره یک توزیع خاص آن را بررسی کنید. به خط hosts: در /etc/nsswitch.conf نگاه کنید؛ hosts: files dns ابتدا فایل‌ها را بررسی می‌کند. آن مثال را فقط برای تغییر ترتیب روی یک پیکربندی کارآمد کپی نکنید، زیرا سیستم‌های واقعی اغلب منابع اضافی و ورودی‌های سرویس شرطی را فهرست می‌کنند که مثال آن‌ها را ندارد.

systemd-resolved آزمون را مبهم می‌کند

در سیستمی که از systemd-resolved استفاده می‌کند، استاب محلی نیز نام‌ها را از پایگاه داده hosts ارائه می‌دهد. بنابراین پرسش از 127.0.0.53 آزمون مستقلی از سرور راه دور نیست، هرچند شبیه پرسش DNS به نظر می‌رسد و مانند آن رفتار می‌کند. می‌توانید تأیید کنید که resolver چه می‌داند و از کدام سرورها می‌پرسد با:

resolvectl query build.corp.example
resolvectl status

خروجی status سرورهای DNS را برای هر پیوند نام می‌برد و به این ترتیب می‌فهمید که آیا پیوند VPN اصلاً resolver دریافت کرده است. این پرسش از ورودی hosts جداست و همان پرسشی است که ارزش پرسیدن دارد وقتی یک نام خصوصی برای همه کاربران شکست می‌خورد نه برای یکی.

برنامه‌ها می‌توانند لایه دیگری اضافه کنند. مرورگری با تنظیم DNS-over-HTTPS خودش، کانتینری با پیکربندی resolver خودش، یا محیط اجرایی که جستجوها را در تمام عمر فرایند در حافظه نگه می‌دارد، هر یک می‌توانند متفاوت از سیستم پاسخ دهند. برنامه‌ای را که برایتان مهم است آزمون کنید، نه اینکه فرض کنید یک فرمان هر برنامه روی دستگاه را توصیف می‌کند.

چه چیزی واقعاً یک نام را در سراسر VPN به اشتراک می‌گذارد

اگر یک نام خصوصی باید برای همه کار کند، به مالکی نیاز دارد که resolver همه به آن برسد. پاسخ پاک این است که رکورد را در یک ناحیه مدیریت‌شده منتشر کنید و آن ناحیه را از طریق مسیر DNS مورد نظر VPN قابل حل کنید. آن‌گاه رکورد یک منبع حقیقت، یک رد حسابرسی و یک چرخه عمر دارد و هیچ‌کس لازم نیست به خاطر بسپارد کدام لپ‌تاپ بازنویسی محلی دارد.

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

ثبت پویا در DNS سومین سازوکار است، با مجوزها، احراز هویت به‌روزرسانی و عمر رکورد خودش. از یک ورودی hosts ناشی نمی‌شود و از صرفاً وصل شدن یک کلاینت هم ناشی نمی‌شود، مگر اینکه سرور و کلاینت هر دو برای این کار پیکربندی شده باشند. رکوردی که خودبه‌خود ظاهر می‌شود نشانه آن است که کسی به‌روزرسانی‌های امن را فعال کرده و کلاینتی خودش را ثبت می‌کند، و این پیکربندی به سند طراحی تعلق دارد نه به رشته عیب‌یابی. اگر هیچ‌کس نمی‌تواند بگوید مالک آن تنظیم کیست، رکورد خودکار را تأییدنشده بدانید و ناحیه مدیریت‌شده را منبع حقیقت نگه دارید.

نام حل‌شده مسیر نیست

حل نام و دسترسی‌پذیری از هم جدا هستند و نگاشت محلی کهنه روش کلاسیک اشتباه گرفتن آن‌هاست. ورودی hosts که به نشانی اشاره می‌کند که جابه‌جا شده، مدت‌ها پس از اصلاح DNS همچنان میزبان کهنه را انتخاب می‌کند و نشانه مانند شکست مسیریابی روی نامی به نظر می‌رسد که خوب حل می‌شود.

پس وقتی گزارش این است که «نام حل می‌شود اما سرویس در دسترس نیست»، جستجوی سیستم را با یک پرسش صریح از سرور DNS شبکه VPN مقایسه کنید، سپس نشانی‌ای را که گرفتید با نشانی‌ای که سرویس واقعاً استفاده می‌کند بسنجید. مرجع systemd-resolved منابع محلی‌ای را که بررسی می‌کند مستند می‌کند و این همان نقشه‌ای است که برای آن مقایسه نیاز دارید.

سپس بازنویسی را از طریق مالکش اصلاح کنید. حذف یک خط از فایل hosts خودتان برای آن دوازده لپ‌تاپی که همان خط را از یک اسکریپت استقرار گرفته‌اند کاری نمی‌کند و این همان نسخه‌ای از این مشکل است که مردم واقعاً دارند.