چرا پاسخ DNS در فایروال لبه VPN بی‌حالت شکست می‌خورد
پاسخ ورودی به پرس‌وجوی DNS یک میزبان VPN پورت مبدأ 53 را حمل می‌کند، نه پورت مقصد 53. قاعده را به ریزولور واقعی و لبهٔ مسیر محدود کنید.
تونل برپاست، کارخواهان به میزبان VPN می‌رسند، و میزبان نمی‌تواند چیزی را تفکیک کند. پرس‌وجوهای خروجی خودش به‌تمیزی از رابط بیرون می‌روند، پس خطا در مسیر بازگشت است: در لبهٔ بالادستی که ترافیک ورودی را بدون هیچ حافظه‌ای از آنچه میزبان همین حالا فرستاده پالایش می‌کند. اجازه دادن به پورت تونل اصلاً آن مبادله را توصیف نمی‌کند. پاسخ به یک پرس‌وجوی DNS جریان جداست، و اگر لبه بی‌حالت باشد، چیزی به آن اجازهٔ بازگشت نداده است.
این دو مبادله یک مبادله نیستند
چندتایی‌ها را بنویسید تا خطا آشکار شود. پورت مقصد درخواست به پورت مبدأ پاسخ تبدیل می‌شود، که برخلاف تصور بیشتر مردم هنگام افزودن قاعدهٔ ورودی برای پورت 53 است:
query: 203.0.113.10:53018 -> 198.51.100.53:53
reply: 198.51.100.53:53 -> 203.0.113.10:53018قاعدهٔ ورودی که پورت مقصد 53 را الزام می‌کند، ترافیکی را توصیف می‌کند که به شنوندهٔ DNS در حال اجرا روی میزبان نشانه رفته است، و این سرویس کاملاً دیگری است. آن نشانی‌ها نمونه‌های مستندسازی هستند و پورت مبدأ را کارخواه برای هر پرس‌وجو انتخاب می‌کند، پس مقداری نیست که بتوانید در قاعده کپی کنید و انتظار داشته باشید همچنان کار کند.
لبهٔ بی‌حالت در برابر فایروال میزبان باحالت
پالایهٔ لبهٔ بی‌حالت هر بستهٔ ورودی را بدون هیچ جدول اتصالی در پشت آن، در برابر فهرست قواعدش می‌سنجد. پرس‌وجوی خروجی که با موفقیت خارج شده هیچ اجازه‌ای برای پاسخ ورودی‌اش ایجاد نمی‌کند، زیرا دستگاه هیچ سابقه‌ای ندارد که پرس‌وجویی هرگز رخ داده باشد. فایروال میزبان باحالت برعکس است: ردیابی اتصال آن ترافیک بازگشتی یک مبادلهٔ مجاز را می‌شناسد و آن را بدون قاعده‌ای برای پاسخ عبور می‌دهد. هر دو مرز در یک مسیر معمول وجود دارند، و هر دو باید بستهٔ موردنظر را مجاز کنند.
این مقایسه مهم است زیرا دو دستگاه متفاوت شکست می‌خورند. فایروال باحالتی که پاسخ را رد می‌کند حذف بسته را ثبت می‌کند؛ لبهٔ بی‌حالت آن را بی‌صدا رد می‌کند، و به همین دلیل میزبان به‌سادگی به پایان زمان می‌رسد.
اجازه را حول پروتکل بسازید، نه شمارهٔ پورت
قاعده را به نشانی‌های واقعی ریزولور، میزبان مقصد و سیاست پورت دریافت که محصول پشتیبانی می‌کند محدود کنید. مسیر TCP در DNS را هم در نظر بگیرید، زیرا پاسخ بزرگ یا بازگشت به‌دلیل کوتاه‌سازی مبادله را به TCP منتقل می‌کند و قاعده‌ای فقط برای UDP آن را پوشش نمی‌دهد. اگر لبه بازرسی باحالت را برای جریان مشخصی پشتیبانی می‌کند، آن را بر قاعدهٔ پاسخ دست‌نویس ترجیح دهید، زیرا مسیر باحالت به‌طور خودکار از پورت‌هایی که کارخواه انتخاب می‌کند پیروی می‌کند.
سپس تأیید کنید کدام محصول در مسیر واقعاً ترافیک را پالایش می‌کند. دامنهٔ مستند لبهٔ IPv4 سیاست IPv6 را تثبیت نمی‌کند، و ترافیک داخلی ارائه‌دهنده ممکن است هرگز از همان پالایه عبور نکند.
چرا مجاز دانستن هر پورت مبدأ 53 راه‌حل نیست
قاعده‌ای که هر چیزی را که ادعای پورت مبدأ 53 دارد می‌پذیرد، قاعده‌ای است که هر آنچه فرستنده در یک فیلد سرآیند بنویسد می‌پذیرد. شمارهٔ پورت فرستنده را احراز هویت نمی‌کند و ثابت نمی‌کند که بار داده پاسخ معتبری است، پس قاعده سطح در معرض بودن میزبان را گسترش می‌دهد بی‌آنکه تفکیک را قابل‌اعتمادتر کند. محدودیت‌های مبدأ و بررسی‌های پاسخ خود کارخواه، از جمله تصادفی‌سازی پورت مبدأ، را حفظ کنید نه اینکه برای ساده‌کردن فهرست دسترسی خاموششان کنید.
اگر ریزولور سرویسی است که شما کنترل می‌کنید، محدودکردن به نشانی‌هایش کافی است. اگر ریزولور عمومی است، به نشانی‌هایی که تأیید کرده‌اید محدود کنید و آن‌ها را در توضیح قاعده بنویسید.
در مرز درست و جهت درست بررسی کنید
برای همان پرس‌وجو هم در میزبان و هم در لبه ضبط کنید و چندتایی‌ها را مقایسه کنید نه شمارش بسته‌ها. پرس‌وجویی که در هر دو سو دیده می‌شود ولی پاسخی در سو میزبان دیده نمی‌شود به پالایهٔ ورودی اشاره دارد؛ پرس‌وجویی که فقط در سو میزبان دیده می‌شود به مسیریابی یا خود ریزولور اشاره دارد. اگر فقط اجازهٔ UDP دارید با پرس‌وجوی TCP تکرار کنید، زیرا همان شکافی است که آزمون نخست نمی‌تواند ببیند.
رفع این مشکل یک مبادلهٔ DNS را کامل می‌کند که میزبان واقعاً به آن نیاز دارد. این کار میزبان را به ریزولور عمومی تبدیل نمی‌کند، جریان‌های VPN ارسال‌شده را مجاز نمی‌کند و ثابت نمی‌کند که DNS علت مشکلی نامرتبط با تونل بوده است.