پشتیبان DNS در VPN شما: پرس‌وجو در واقع کجا می‌رود
تغییر resolver به‌طور خودکار نشتی نیست. پیش از آنکه آن را چنین بنامید، دریافت‌کننده جایگزین، مسیر مورد استفاده و نام‌های درگیر را مشخص کنید.
تنظیم resolver از نشانی خصوصی به نشانی عمومی تغییر می‌کند و نتیجه بی‌درنگ می‌آید: تونل نشتی دارد. گاهی چنین است. اغلب پرس‌وجوی پشتیبان همچنان درون تونل به resolverی می‌رفت که مدیر انتخاب کرده بود، و این آن را به تصمیمی سیاستی نه نقص تبدیل می‌کند. جدا کردن این موارد سه واقعیت می‌خواهد نه یکی، و نخستین آن‌ها این است که چه کسی پاسخ داد. دریابید چه کسی پرس‌وجو را دریافت کرد، کدام مسیر آن را برد و چه نام‌هایی پرسیده شد.
پشتیبان یک سیاست است، نه یک رفتار واحد
هر کارخواه باید تصمیم بگیرد وقتی resolver ترجیحی از پاسخ دادن بازمی‌ماند چه کند. می‌تواند حل را مسدود کند، دوباره تلاش کند، از جایگزین پیکربندی‌شده استفاده کند یا آن را به سیستم‌عامل بسپارد، و از دید حریم خصوصی این‌ها چهار محصول متفاوت‌اند. خواندن صفحه تنظیمات می‌گوید کدام رفتار پیکربندی شده است؛ نمی‌گوید کدام رخ داده است. صفحه‌ای با یک کلید، چهار امکان را توصیف نمی‌کند.
مرورگرها لایه خودشان را می‌افزایند. مرورگری با DNS امن فعال می‌تواند نامی را از طریق ارائه‌دهنده‌ای که خودش برگزیده حل کند، حتی وقتی سیستم‌عامل جای دیگری را نشان می‌دهد، یعنی ممکن است سیاست کارخواه تونل هرگز برای درخواست‌هایی که واقعاً برایتان مهم است پرسیده نشود. برنامه‌ای را که درخواست را فرستاده بررسی کنید، نه فقط تنظیم سیستم را.
هویت resolver جایگزین نخستین واقعیتی است که ارزش اثبات دارد. resolver عمومی متعلق به ارائه‌دهنده‌ای که از قبل به آن اعتماد دارید وضعیتی دیگر از نشانی‌ای است که شبکه‌ای که در آن هستید فراهم می‌کند. خود نشانی به‌ندرت می‌گوید به کدام یک از این دو نگاه می‌کنید.
چه کسی پرس‌وجو را پس از تغییر دریافت می‌کند
دریافت‌کننده و مسیر مستقل‌اند و تنها ترکیب آن‌ها میزان مواجهه را توصیف می‌کند. resolver عمومی که از راه تونل به آن می‌رسیم هرگز نشانی شبکه دسترسی شما را نمی‌بیند، در حالی که همان resolver اگر مستقیم به آن برسیم می‌بیند. هر دو حالت پاسخی تولید می‌کنند و آزمون نشتی که فقط نشانی resolver را گزارش می‌کند آن‌ها را یکسان توصیف خواهد کرد. هنگام خواندن نتیجه، هم نشانی و هم رابط را بپرسید.
نام‌های داخلی تمایز را عینی می‌کنند. resolver عمومی معمولاً نمی‌تواند به نامی از نوع split-horizon پاسخ دهد، پس پرس‌وجو شکست می‌خورد در حالی که نام همچنان برای طرفی فاش شده که کاری با دیدنش نداشت. پس دسترس‌پذیری و حریم خصوصی اینجا با هم حرکت می‌کنند نه اینکه با هم معامله شوند.
تونل می‌تواند پرس‌وجو را به resolverی هم ببرد که ارائه‌دهنده VPN اداره‌اش نمی‌کند، زیرا تونل به‌جای حل کردن، ارسال می‌کند. میزبان ارسال‌کننده پرس‌وجو را به‌شکل متن روشن می‌بیند و سپس اتصال خودش را به جلو باز می‌کند، که گام بعدی را محافظت می‌کند ولی گام نخست را نه.
مسیر و دریافت‌کننده را با هم بررسی کنید
بسته‌ها را مشاهده کنید نه پیکربندی را. از سیستم بپرسید کدام resolver استفاده می‌شد، سپس تأیید کنید که پرس‌وجو واقعاً از رابط انتظارشده به نشانی انتظارشده رفت.
resolvectl status | grep -E "Current DNS Server|DNS Servers|DNSOverTLS"
dig +short example.com
tcpdump -ni any udp port 53 or tcp port 853اگر ضبط نشان دهد پرس‌وجو در حالی که تونل برپاست از رابط فیزیکی خارج می‌شود، پشتیبان تونل را دور زده است بی‌آنکه فهرست resolverها هر چه می‌گوید اهمیت داشته باشد. اگر روی رابط تونل ظاهر شود، پرسش این می‌شود که چه کسی انتهای دور را اداره می‌کند و چه چیزی نگه می‌دارد.
بررسی را برای یک نام داخلی و یک نام عمومی تکرار کنید. پرس‌وجوی داخلی جایی است که پیکربندی پشتیبان معمولاً خودش را نشان می‌دهد، زیرا resolverی که نمی‌تواند پاسخ دهد باز هم پرسش را دریافت می‌کند.
تصمیم بگیرید آیا پشتیبان باید مجاز باشد
اگر شرط این است که حل کردن هنگام دسترس‌نبودن resolver ترجیحی متوقف شود، سیاست اجرایی‌ای پیکربندی کنید که بسته شکست بخورد و پیامد را بپذیرید: نام‌ها در هنگام قطعی حل نمی‌شوند. این معامله‌ای عامدانه بر سر دسترس‌پذیری است نه خرابی، و طراحی باید پیش از رخ دادن قطعی آن را بگوید.
اگر شرط تنها این است که پرس‌وجوها بیرون از تونل نروند، resolver عمومی که از راه تونل به آن می‌رسیم می‌تواند پذیرفتنی باشد به شرط آنکه اپراتور و سیاست نگهداری‌اش شناخته باشد. چنین پذیرشی داوری درباره طرف سوم است نه بیانیه‌ای درباره رمزنگاری، و از آنِ کسی است که ادعای حریم خصوصی را دارد. اگر نام‌های داخلی باید همچنان کار کنند، پشتیبان باید resolverی باشد که مناطق داخلی را در اختیار دارد، که معمولاً یعنی هدف پشتیبان سروری دیگر است نه خانواده‌ای دیگر از نشانی‌ها.
نتیجه را به‌صورت جمله‌ای درباره رفتار مستند کنید: کدام resolver در کار عادی پرس‌وجوها را می‌گیرد، کدام پس از خرابی آن‌ها را می‌گیرد، و آیا نام‌های داخلی در حالت دوم حل می‌شوند. آزمون نشتی‌ای که در نهایت صفحه‌ای را بار می‌کند کمتر از آن جمله را اثبات می‌کند، زیرا صفحه می‌تواند از طریق resolverی بار شود که هرگز نباید از آن پرسیده می‌شد.