چرا DNS خودِ روتر تونل VPN را دور می‌زند؟
پرس‌وجوی کلاینت و پرس‌وجوی بالادستی روتر دو جریان متفاوت‌اند. هر دو را ثبت کنید، خروجی حل‌کننده را انتخاب کنید و سپس حالت قطع تونل را آزمایش کنید.
پرس‌وجوهای کلاینت‌ها از تونل پیروی می‌کنند، در حالی که پرس‌وجوهای خودِ روتر از WAN بیرون می‌روند، و قاعدهٔ دیوار آتش که یکی را اداره می‌کند هیچ تأثیری بر دیگری ندارد. دلیلش یک باگ نیست: درخواست عبورداده‌شده و درخواستی که خود روتر می‌سازد دو جریان جداگانه‌اند و هر یک با بخش متفاوتی از پیکربندی تطبیق داده می‌شود. ثبت تنها نیمهٔ کلاینت پاسخ مطمئنی درباره مسیری می‌دهد که نیمهٔ دوم هرگز از آن استفاده نمی‌کند. راه اصلاح این است که حل‌کنندهٔ روتر را آگاهانه جهت دهید و سپس دو مسیر را جداگانه آزمایش کنید.
ثبت بسته‌ها در واقع به کدام جریان تعلق دارد
یک پرس‌وجو دو تبادل دارد. کلاینت LAN پرس‌وجویی به حل‌کنندهٔ روتر می‌فرستد و آن به‌صورت ترافیک عبورداده‌شده روی واسط LAN می‌رسد، بنابراین قاعدهٔ مسیریابی سیاستی یا NAT که برای بسته‌های عبورداده‌شده نوشته شده می‌تواند با آن تطبیق پیدا کند. سپس روتر از حافظهٔ نهان پاسخ می‌دهد یا در صورت نبود، پرس‌وجوی خودش را به یک سرور بالادستی باز می‌کند.
آن پرس‌وجوی دوم منبعش خود روتر و مقصدش هم خود اوست، و پلتفرم مسیرش را از بلوک پیکربندی دیگری انتخاب می‌کند. هر دو تبادل نام یکسانی دارند و هیچ‌یک رونوشت دیگری نیست. بنابراین ثبتی که در سمت LAN گرفته شود اثبات می‌کند بستهٔ کلاینت کجا رفت و دربارهٔ بستهٔ خروجی چیزی نمی‌گوید.
بررسی عملی این است که هر دو سمت را هم‌زمان ببینید. روی روتر، سوکت حل‌کننده را فهرست کنید، از آن به‌صورت محلی پرس‌وجو کنید و واسط WAN را ثبت کنید:
sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53اگر فهرست سوکت‌ها شنونده‌ای نشان دهد که به نشانی loopback یا LAN بسته شده، روتر به‌صورت محلی پاسخ می‌دهد نه اینکه به میزبان دیگری عبور دهد. آن‌گاه ثبت نشان می‌دهد پرس‌وجوی بالادستی حاصل از واسط تونل بیرون می‌رود یا از WAN، و این همان پاسخی است که قاعدهٔ مسیریابی سیاستی هرگز نمی‌داد.
چرا مسیریابی سیاستی هرگز پرس‌وجوی دوم را نمی‌بیند
قواعد دیوار آتش بر پایهٔ واسط، منبع، مقصد و درگاه نوشته می‌شوند و برای بسته‌هایی ارزیابی می‌شوند که از دستگاه عبور می‌کنند. پرس‌وجویی که روتر می‌سازد از هیچ‌چیز عبور نمی‌کند، چون یک فرایند محلی آن را مستقیماً به جدول مسیریابی می‌سپارد. مسیریابی سیاستی و NAT از این رو فقط بر مسیر عبورداده‌شده اعمال می‌شوند، و به همین دلیل مجموعه‌ای از قواعد می‌تواند کامل به نظر برسد و در همان حال DNS روتر را بیرون از تونل بگذارد.
این تمایز از هر بازنویسی میان‌افزار جان سالم به در می‌برد، چون از مسیر بسته ناشی می‌شود نه از یک قابلیت. هر چیزی که دستگاه برای خودش می‌سازد، چه پرس‌وجوهای حل‌کننده، چه همگام‌سازی زمان، چه بررسی‌های به‌روزرسانی یا دسترسی به آینه‌های بسته، منشأ محلی دارد و در همان نقطهٔ کور می‌افتد. به همین دلیل هم آزمونی که از یک لپ‌تاپ کار می‌کند دربارهٔ روتر چیزی اثبات نمی‌کند.
کجا حل‌کنندهٔ pfSense مسیر بالادستی خودش را تعیین می‌کند
pfSense این شکاف را دیدنی می‌کند. ترافیک کلاینت‌ها می‌تواند با سیاست از یک دروازهٔ VPN عبور کند، در حالی که ترافیک خودِ دیوار آتش تنظیم خروجی حل‌کننده را پیروی می‌کند نه قواعد LAN را. در رابط وب این تنظیم زیر Services > DNS Resolver > Outgoing Network Interfaces قرار دارد و مقدارش فهرست واسط‌هایی است که حل‌کننده می‌تواند برای پرس‌وجوهای بالادستی به کار ببرد.
نام‌بردن واسط تونل در آنجا، و تنها همان واسط، همان چیزی است که پرس‌وجوهای خودِ روتر را به دنبال تونل می‌اندازد. اگر بر پیش‌فرض رها شود، حل‌کننده خروجی را از جدول مسیریابی انتخاب می‌کند که روی میزبان دو-WAN یا VPN اغلب WAN است.
میان‌افزارهای دیگر همین تصمیم را با برچسبی دیگر آشکار می‌کنند: فهرست سرورهای بالادستی بسته‌شده به یک نشانی منبع، حالت فقط‌عبور، یا خط مشی مسیریابی مستند. تنظیمی که باید دنبالش بگردید همیشه همان است که برای پرس‌وجوهای محلی‌ساخته خروجی یا منبع انتخاب می‌کند. مرجع پیکربندی حل‌کننده آن گزینه را برای pfSense مستند می‌کند و ارزش خواندن پیش از تغییر را دارد.
رفتار خرابی را پیش از تنظیم انتخاب کنید
وقتی تونل می‌افتد دو رفتار قابل دفاع است: توقف پرس‌وجوهای بالادستی تا چیزی نشت نکند، یا بازگشت به یک حل‌کنندهٔ تأییدشده روی مسیری شناخته‌شده. هر دو سیاست‌اند و هیچ‌یک آن چیزی نیست که به‌طور پیش‌فرض می‌گیرید. پیش از دست زدن به فهرست واسط‌ها تصمیم بگیرید شبکه کدام را می‌خواهد.
بسته‌شدن در خرابی دفاع از آن آسان‌تر است، اما قطع تونل را به قطع حل نام برای هر دستگاهی پشت روتر تبدیل می‌کند. بازگشت دفتر را قابل استفاده نگه می‌دارد، به بهای یک تبادل بالادستی بیرون از تونل که باید عمداً پذیرفتنی باشد نه تصادفی. انتخاب را بنویسید، چون نفر بعدی که نشانی حل‌کننده‌ای بیرون از VPN ببیند آن را نشت می‌خواند مگر اینکه یادداشتی خلافش را بگوید. همان یادداشت است که بازگشت مستند را از یافته‌ای توضیع‌نشده در بازبینی فصل بعد جدا می‌کند.
دو حالت تصمیم را پیچیده می‌کند. نام‌های خصوصی ممکن است به حل‌کنندهٔ درونی نیاز داشته باشند که تونل به آن برسد، و مرورگر یا برنامه‌ای با DNS رمزنگاری‌شدهٔ خودش می‌تواند کاملاً از روتر دور بزند، پس حل‌کننده‌ای که پیکربندی کرده‌اید همیشه همانی نیست که یک برنامهٔ معین به کار می‌برد.
هر دو مسیر را آزمایش کنید و نتایج را جدا نگه دارید
آزمون DNS مبتنی بر مرورگر به پرسشی باریک پاسخ می‌دهد: آن مرورگر در شرایط آن آزمون از کدام حل‌کننده‌ها استفاده کرد. این آزمون دستگاه‌های شبکه را فهرست نمی‌کند و نمی‌تواند پرس‌وجویی را ببیند که روتر برای خودش ساخته است. خروجی آن را یک نقطهٔ داده بدانید نه یک حسابرسی.
از یک کلاینت LAN، از روتر یک نام عمومی و سپس نامی خصوصی بخواهید که فقط منطقهٔ درونی شما باید پاسخش را بدهد. شکست تنها در پرس‌وجوی دوم به عبور نام اشاره دارد نه به تونل:
dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lanسپس تونل را پایین بیاورید و هر دو پرس‌وجو را تکرار کنید. پاسخ‌های ردشده یعنی حل‌کننده در خرابی بسته می‌شود؛ پاسخ موفق به یک حل‌کنندهٔ بازگشتی و مسیری که استفاده کرده اشاره دارد. آن را با یادداشتی که نوشتید و با ثبتی روی واسط WAN که در همان دقیقه گرفته شده مقایسه کنید.
مشاهدات را در سابقه جدا نگه دارید: تبادل کلاینت با روتر، تبادل روتر با بالادست، و پیکربندی‌ای که دومی را تعیین کرد. تغییر مسیریابی بعدی آن تبادل دوم را بی‌هشدار به کار می‌اندازد. پاسخی که از جایی جز نقطهٔ پایانی VPN برسد به‌خودی‌خود نشت نیست؛ تنها وقتی نشت می‌شود که پیکربندی آن مسیر را تصادفی انتخاب کرده باشد.