نام‌های داخلی روی VPN شکست می‌خورند در حالی که سایت‌های عمومی باز می‌شوند

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

دو نشانه که یک نقص نیستند

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

تله این است که افزودن resolver دفتر به همه‌جا اولی را درست می‌کند و دومی را تضمین. افزودن resolver عمومی به همه‌جا برعکس عمل می‌کند.

هر دو مشاهده را با زمان ثبت کنید و سپس چهار بررسی زیر را به ترتیب انجام دهید.

resolver کدام آداپتور پرسش را می‌گیرد

در Windows کلاینت DNS سرورها را بر اساس ترتیب اتصال آداپتورها انتخاب می‌کند و آداپتور تونل به‌طور خودکار اول نیست. تنظیمات پیشرفته آداپتور را باز کنید و اتصال دسترسی از راه دور را بالای آداپتور فیزیکی ببرید، سپس دوباره وصل شوید تا تغییر در نشست تازه اعمال شود.

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

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

نام کوتاه پیش از مسیر به پسوند نیاز دارد

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

پسوند دستگاه سالم را در تب DNS در ویژگی‌های IPv4 آداپتور VPN کپی کنید و دوباره وصل شوید. در Linux معادل آن دامنه جست‌وجو روی پیوند تونل است که systemd-resolved آن را به‌ازای هر پیوند و نه به‌صورت سراسری نشان می‌دهد.

دو تنظیم را در یادداشت‌هایتان جدا نگه دارید. پسوند تغییر می‌دهد که چه چیزی پرسیده می‌شود؛ نشانی resolver تغییر می‌دهد که از چه کسی پرسیده می‌شود. درست کردن یکی وقتی دیگری غلط است نتیجه‌ای می‌دهد که تصادفی به نظر می‌رسد.

نخست از resolver بپرسید، سپس از نام

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

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

فرمان اول از سروری مشخص نامی کاملاً کامل را می‌پرسد. اگر پاسخ دهد، resolver و مسیر تا آن درست است و نقص در انتخاب یا پسوند است. اگر زمان تمام شود، نشانی غلط یا دست‌نیافتنی است و مشکل در مسیریابی است نه DNS. فرمان دوم نشان می‌دهد با نام کوتاه چه می‌شود و سومین پیکربندی resolver را به‌ازای هر پیوند روی میزبان systemd چاپ می‌کند.

مراقب پاسخ‌های عام باشید که برخی شبکه‌ها برای نام‌های ناشناس برمی‌گردانند. پاسخ باورپذیر اثبات این نیست که سرور موردنظر پاسخ داده است، پس نشانی برگشتی را با نشانی‌ای که سرویس داخلی واقعاً به کار می‌برد مقایسه کنید. اگر نشانی به صفحه پارکینگ یا پروکسی تعلق دارد، resolver پاسخ داده اما پاسخ هرگز مال شما نبوده است. همین تمایز یک ساعت دنبال تونلی گشتن را که تمام مدت کار می‌کرد ذخیره می‌کند.

در Linux کلاینت VPN که /etc/resolv.conf را بازنویسی می‌کند resolverهای محلی را کاملاً جایگزین می‌کند. vpnc برای جلوگیری از آن DNSUpdate no را در اختیار می‌گذارد و systemd-resolved می‌تواند فقط دامنه‌های فهرست‌شده را به پیوند تونل بفرستد. هر دو رویکرد نام‌های عمومی را روی resolver محلی نگه می‌دارند و نام‌های داخلی را به دفتر می‌فرستند.

نشت‌ها یک قاعده‌اند، نه یک کادر تیک

حل نام یک تبادل UDP به درگاه 53 است، پس تونلی که ترافیک وب را می‌برد اما UDP را نه، پرسش را روی مسیر فیزیکی می‌گذارد. این را با ثبت بسته‌ها روی کارت شبکه فیزیکی هنگام حل یک نام عمومی ثابت کنید. پرسشی که روی آن واسط به شکل خوانا دیده شود یعنی تونل آن را نمی‌برد.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

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

آن بخش آخر مهم‌تر از آن است که به نظر می‌رسد. OpenVPN را با route-nopull اجرا کنید و گزینه DNS هل‌داده‌شده همراه مسیرها ناپدید می‌شود، مگر آنکه فیلتر کشیدن گسترده شود تا آن را نگه دارد. و کلاینتی که dhcp-option DNS را نادیده می‌گیرد همان چیزی را که قبلاً داشت به کار می‌برد. هر تغییری در سمت سرور برای اعمال شدن نشست تازه می‌خواهد، چون فهرست resolver هنگام بالا آمدن تونل تحویل داده می‌شود و نشست کهنه همچنان وضعیت قبلی را نشان می‌دهد.

پیش از بستن تیکت ثبت کنید کدام نقص را واقعاً مشاهده کردید. پاسخ داخلی گم‌شده و پرسشی که از تونل می‌گریزد تعمیرهای متفاوتی می‌خواهند و تغییر پسوندی که اولی را درست می‌کند می‌تواند دومی را بی‌صدا بدتر کند. کسی که بعداً تیکت را بردارد به برچسب اعتماد می‌کند، پس برچسب را دقیق کنید.