چرا نام‌های خصوصی DNS روی کلاینت‌های VPN شکست می‌خورند و کجا باید بررسی کرد

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

پیش از ویرایش هر پروفایلی، تأیید کنید که کلاینت با نام چه می‌کند. در Linux، resolvectl query files.corp.example نشان می‌دهد کدام پیوند و کدام حل‌کننده پاسخ را ساخته‌اند. در Windows، Resolve-DnsName files.corp.example سروری را که پاسخ داده و نشانی‌ای را که برگردانده نشان می‌دهد.

پاسخ را بخوانید پیش از آنکه چیزی را تغییر دهید

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

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

حل‌کننده را از داخل تونل توزیع کنید

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

OpenVPN در گروه نخست است. روی سرور، push "dhcp-option DNS 10.8.0.53" و push "dhcp-option DOMAIN corp.example" از کانال کنترل پایین می‌آیند، اما تنها اگر در پیکربندی کلاینت pull هنوز فعال باشد. کلاینتی که دستی ویرایش شده و pull-filter ignore "dhcp-option" را حمل می‌کند هرگز آن‌ها را نخواهد دید، و همان یک خط شمار شگفت‌آوری از موارد «سرور آن را هل می‌دهد اما لپ‌تاپ من موافق نیست» را توضیح می‌دهد.

WireGuard در گروه دوم است، چون پروتکل هیچ مذاکره‌ای بر سر گزینه‌ها ندارد. حل‌کننده و دامنه جست‌وجو در بلوک [Interface] خود کلاینت به‌صورت DNS = 10.8.0.53, corp.example می‌نشینند. wg-quick آن را از طریق resolvconf یا systemd-resolved اعمال می‌کند، و در Windows کلاینت رسمی قواعد NRPT را نصب می‌کند که تنها تا زمانی که تونل برپاست وجود دارند: Get-DnsClientNrptPolicy آن‌ها را فهرست می‌کند، و همین آن را راهی سریع برای دیدن این می‌کند که آیا کلاینت هرگز فایل شما را اعمال کرده است.

IPsec/IKEv2 میان این دو است. افزونه attr در strongSwan می‌تواند سرور DNS برگرفته از یک استخر را بازگرداند، و کلاینت Windows معمولاً آن را می‌پذیرد، اما پروفایلی که سرور نام خودش را میخکوب می‌کند بر هر چیزی که درگاه پیشنهاد دهد چیره می‌شود. روی کلاینت Linux گام دستی معادل resolvectl dns wg0 10.8.0.53 و سپس resolvectl domain wg0 '~corp.example' است؛ هر دو با از میان رفتن رابط ناپدید می‌شوند، که دقیقاً همان چیزی است که برای تنظیمی محدود به تونل می‌خواهید.

پسوند را محدود کنید به‌جای بلعیدن هر پرس‌وجو

هدایت تمام فهرست حل‌کننده‌های کلاینت به سرور داخلی‌تان آسان و معمولاً نادرست است. آن‌گاه هر نام عمومی از خروجی مرکز داده شما حل می‌شود، CDNها نشانی‌های دور برمی‌گردانند، و یک قطعی حل‌کننده مرور کاربر را با خود می‌برد.

فقط پسوند خصوصی را به داخل بفرستید. در systemd-resolved دامنه‌ای که با ~ آغاز می‌شود تنها برای مسیریابی است، پس ~corp.example یعنی پرس‌وجوهای زیر آن پسوند به سرورهای همان پیوند می‌روند در حالی که بقیه همچنان از شبکه فیزیکی استفاده می‌کنند. Windows همین کار را با قواعد NRPT محدود به یک فضای نام انجام می‌دهد، و macOS با فایل حل‌کننده تکمیلی زیر /etc/resolver/.

نام‌های چندپخشی پاسخ خودشان را می‌طلبند. نام‌های .local بنا به طراحی link-local هستند (RFC 6762) و رابط tun نقطه‌به‌نقطه آن گروه چندپخشی را حمل نمی‌کند، پس افزودن حل‌کننده عمومی آن‌ها را منتشر نمی‌کند و پرسیدن از حل‌کننده داخلی تک‌پخشی درباره آن‌ها NXDOMAIN برمی‌گرداند. بازتابنده‌ای مانند avahi در حالت بازتاب می‌تواند دو بخش را به هم پل بزند، اما آن تصمیمی در سمت سرور است که هیچ کلاینتی نمی‌تواند بخواهد. اگر چاپگر یا NAS باید با نام در دسترس باشد، در عوض یک رکورد A در ناحیه خود به آن بدهید.

اثبات کنید که پاسخ می‌تواند بازگردد

پاسخ درستی که به نشانی دسترس‌ناپذیر اشاره می‌کند دقیقاً مانند یک مشکل حل‌کننده به نظر می‌رسد تا وقتی مسیر را بررسی کنید. از هسته بپرسید پاسخ کجا می‌رود: ip route get 10.20.5.20 رابط و، به‌شکلی سودمندتر، نشانی مبدأیی را که استفاده می‌کند نام می‌برد.

خود نشانی حل‌کننده را زیر نظر بگیرید. کلاینتی که DNS = 10.8.0.53 را کنار AllowedIPs = 10.20.0.0/16 دارد پرس‌وجوهایش را از کارت شبکه فیزیکی بیرون می‌فرستد، جایی که بی‌صدا می‌میرند، چون حل‌کننده درون هیچ پیشوندی که تونل ادعا می‌کند نیست. این ناسازگاری شایع‌ترین خرابی تک‌علتی در سراسر این حوزه است و تا وقتی تنظیم DNS را خط‌به‌خط با پیشوندهای مجاز مقایسه نکنید نامرئی می‌ماند.

بازه‌های هم‌پوشان خرابی معکوس را ایجاد می‌کنند. پاسخ درست است، مسیر وجود دارد، و به میزبان اشتباه اشاره می‌کند، چون 192.168.0.0/24 در خانه مشخص‌تر از مسیر تونل به همان بازه است. یک طرف را دوباره شماره‌گذاری کنید یا مسیر باریک‌تری را هل دهید، سپس دیوار آتش و مسیر بازگشت میزبان سرویس را تأیید کنید؛ یادداشت‌های strongSwan درباره ارسال رو به جلو سمت sysctl آن مسیر را پوشش می‌دهند.

گواهی‌ها یک بررسی هویت جداگانه‌اند که مردم آن را به DNS نسبت می‌دهند. اگر مرورگر به‌جای خطای حل، از ناسازگاری نام خبر دهد، جست‌وجو از قبل کار کرده و آنچه باید اصلاح شود SAN در گواهی است. HTTPS را با نام آزمایش کنید، هرگز با IP لخت.

از کلاینت دوباره آزمایش کنید، نه از درگاه

داخل برنامه‌ای آزمایش کنید که کاربر از آن شکایت دارد، چون جست‌وجو از خط فرمان ثابت نمی‌کند که مرورگر همان مسیر را می‌رود. DNS امن Chrome و network.trr.mode در Firefox می‌توانند حل‌کننده سیستم را کاملاً دور بزنند، و وقتی چنین کنند نام خصوصی یا شکست می‌خورد یا به یک حل‌کننده عمومی درز می‌کند. مقایسه resolvectl query با dig @10.8.0.53 files.corp.example که دستی اجرا شده به شما می‌گوید کدام‌یک از آن دو رخ داده است.

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

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