عبور DNS تنها از طریق resolver VPN شما: یک راهنمای گام به گام
یک جست‌وجوی نام را از مرورگر تا پاسخ دنبال کنید. ببینید resolver کجا انتخاب می‌شود، فایروال کجا آن را اعمال می‌کند و قاعده پورت 53 هرگز چه چیزی را پوشش نمی‌دهد.
یک جست‌وجوی نام را از همان لحظه‌ای که آن را تایپ می‌کنید دنبال کنید. مرورگر از سیستم‌عامل می‌پرسد، سیستم‌عامل از resolverی می‌پرسد که سیاستش انتخاب کرده است، و پرس‌وجو از طریق فلان رابط با فلان ترابری از دستگاه خارج می‌شود. طرح VPN شما می‌گوید پاسخ باید از resolver مشخصی و از مسیر مشخصی بیاید. شکاف میان این دو جمله همان چیزی است که پیکربندی می‌کنید و سپس اعمال.
گام 1: resolver و مسیر را نام ببرید
پیش از دست زدن به فایروال سه چیز را بنویسید: نشانی resolver، پروتکل و پورتی که انتظار دارید، و رابطی که پرس‌وجو باید از آن خارج شود. بدون این فهرست، قاعده یک گمان درباره ترافیک است نه اجرای یک تصمیم. یک VPN می‌تواند داده‌های برنامه را حمل کند در حالی که DNS ترتیب جداگانه‌ای را دنبال می‌کند، و این به‌خودی‌خود خطا نیست. این همان چیزی است که وقتی هیچ‌کس چیز دیگری به کلاینت نگفته باشد رخ می‌دهد.
نام‌بردن صریح مسیر، تفاوت میان یک طرح و یک تصادف است. همچنین چیزی به شما می‌دهد که بعداً بیازمایید، زیرا هر مشاهده را می‌توان با یک انتظار مکتوب مقایسه کرد. این فهرست را در تیکت تغییر نگه دارید نه در ذهن کسی.
گام 2: سیاست را همان‌جا بگذارید که واقعاً زندگی می‌کند
انتخاب resolver به کلاینت تعلق دارد: پیکربندی شبکه سیستم‌عامل، تنظیمات خود کلاینت VPN یا یک سیاست مدیریت‌شده مرورگر. نخست آن را همان‌جا بگذارید، با سازوکاری که پلتفرم پشتیبانی می‌کند، زیرا فایروال نمی‌تواند کلاینت را وادار کند resolverی را انتخاب کند که هرگز درباره‌اش چیزی نشنیده است. در کلاینت تونل تقسیم‌شده صریحاً بگویید کدام دامنه‌ها به resolver داخلی می‌روند. در یک ناوگان مدیریت‌شده، سیاست مرورگر غالباً تنها اهرم برای DoH است، چون مرورگر می‌تواند resolver رمزنگاری‌شده خود را مستقل از تنظیم سیستم انتخاب کند.
اگر این را رد کنید و مستقیم سراغ فایروال بروید، قاعده‌ای می‌گیرید که resolver درست را مجاز می‌داند به‌همراه کلاینتی که هرگز از آن استفاده نمی‌کند. قاعده درست به نظر می‌رسد و گزارش‌های resolver خالی می‌مانند، که جفت گیج‌کننده‌ای برای عیب‌یابی است. نخست انتخاب را پیکربندی کنید، سپس آن را اعمال کنید.
گام 3: مسیر را به‌شکل باریک اعمال کنید
اکنون مجوز شبکه برای مسیر مجاز را اضافه کنید: نشانی resolver، پروتکل و پورت، و رابطی که باید از آن خارج شود. قاعده را به همان resolver محدود نگه دارید به‌جای آنکه همه DNS خروجی را مجاز کنید. سه مسیر زیر همان‌هایی هستند که یک کلاینت مدرن می‌تواند برگزیند، و تنها مسیر اول است که قاعده پورت 53 آن را پوشش می‌دهد.
| Path | Port | Who controls it |
|---|---|---|
| Classic DNS | UDP and TCP 53 | System resolver settings |
| DNS over TLS | TCP 853 | Resolver or stub configuration |
| DNS over HTTPS | TCP 443 | Browser or application policy |
مسدود کردن DoH و DoT مشروع است؛ اما فرض اینکه یک قاعده پورت 53 از پیش آن‌ها را مسدود کرده، مشروع نیست. مرورگری که از DoH استفاده می‌کند نام‌ها را از مسیری حل می‌کند که قاعده شما هرگز توصیف نکرده است، و برنامه‌ای که resolver خود را همراه دارد همان کار را می‌کند. هر مسیری که می‌خواهید مجاز کنید و هر مسیری که می‌خواهید رد کنید را بنویسید. قاعده‌ای که مسیری را نام نمی‌برد درباره آن تصمیم نگرفته است.
گام 4: نام‌های خصوصی و عمومی را دنبال کنید
DNS تقسیم‌شده آگاهانه فقط فضای نام خصوصی را به resolver داخلی می‌فرستد در حالی که نام‌های عمومی جای دیگری می‌روند، پس بیش از یک resolver در طرح به معنای نشت نیست. نشت آن پرس‌وجویی است که باید به resolver شما می‌رفت و جای دیگری سر می‌زند، یا مسیر مقصودی که دست‌نیافتنی است و کلاینت را بی‌صدا به عقب برمی‌گرداند. این دو حالت همان چیزی است که باید بجویید. یک نام داخلی و یک نام عمومی را زیر سیاست مقصود دنبال کنید و بنویسید کدام resolver به هر یک پاسخ داد.
سایتی آزمایشی که resolver شما را گزارش می‌کند یک نشانه است نه مدرک، زیرا فقط پرس‌وجوهایی را می‌بیند که به آن رسیده‌اند. وقتی باید بدانید پرس‌وجو در واقع کدام مسیر را رفته، آن را در سمت کلاینت ثبت کنید و سپس دو مشاهده را مقایسه کنید. وقتی ناسازگار باشند، بازگشتی یافته‌اید که کسی مستند نکرده است.
اگر نشانی resolver درست ولی دست‌نیافتنی است، مشکل در مسیریابی یا فیلترکردن است نه در سیاست. پرس‌وجو را تا آن نشانی دنبال کنید و تأیید کنید پاسخ از رابط مورد انتظار بازمی‌گردد، پیش از آنکه هر تنظیم resolver را تغییر دهید.
گام 5: راهی برای بازگشت باز بگذارید
پیش از سخت‌تر کردن دسترسی DNS در دروازه، روشی برای بازیابی تأیید کنید که به حل نام وابسته نباشد. resolver خراب دسترسی به هر ابزار تعمیر را سخت‌تر می‌کند، از جمله آن‌هایی که با آن‌ها تغییر را برمی‌گردانید. یک کنسول محلی یا مسیری بیرون از باند را باز نگه دارید تا سیاست تازه اثبات شود. تنها پس از آنکه سیاست از یک اتصال دوباره جان سالم به در برد آن را بردارید.
پس از اتصال دوباره یا به‌روزرسانی سیاست مرورگر، وضعیت مؤثر را دوباره بررسی کنید، زیرا هر دو می‌توانند resolver را بدون تغییر قاعده شما عوض کنند. شرط لازم گیرنده‌ای شناخته‌شده و مسیری محافظت‌شده برای پرس‌وجوهاست، نه برچسب آرامش‌بخش resolver در یک تصویر صفحه. مشخصات RFC 8484 برای DNS over HTTPS مرجع مسیر رمزنگاری‌شده‌ای است که قاعده پورت شما آن را نمی‌بیند.