DNS با VPN در برابر DoH مرورگر: آنچه آزمون نشتی نمی‌تواند بگوید
نشانی آزمون نشتی فقط نشان می‌دهد کدام حل‌کننده پاسخ داده است. پرس‌وجوهای رمزنگاری‌شده، DNS تفکیک‌شده و سیاست مرورگر تعیین می‌کنند که نام‌های خصوصی اصلاً حل می‌شوند یا نه.
صفحه آزمون نشتی می‌گوید DNS شما خوب است، نشان مرورگر می‌گوید امن است، و ویکی داخلی هنوز بارگذاری نمی‌شود. هر سه می‌توانند همزمان درست باشند، چون نشانی یک حل‌کننده همان چیزی نیست که سیاست انتخاب‌کننده آن یا مسیری که پرس‌وجو طی کرده است. آنچه مردم نشتی DNS می‌نامند در واقع یک پرسش است: کدام حل‌کننده نام را دریافت کرد، و آیا آن انتخاب عمدی بود؟ روشن کردن این موضوع سه بررسی می‌خواهد، و فقط آخری شامل تغییر یک تنظیم است.
افسانه یکم: نشان نام حل‌کننده شما را می‌گوید
آزمون نشتی یک نام آزمایشی را حل می‌کند و نشانی‌ای که پاسخ داده است را گزارش می‌دهد. این آزمون سیاستی را که آن حل‌کننده را انتخاب کرده گزارش نمی‌دهد، و وقتی پرس‌وجو در DNS روی HTTPS پیچیده شده باشد، جعبه میانی روی مسیر اصلاً نام را نمی‌بیند. دو ماشین کاملاً متفاوت همان نشان اطمینان‌بخش را تولید می‌کنند: یکی که VPN در آن 10.8.0.1 را فرستاده و مرورگر از آن استفاده می‌کند، و دیگری که مرورگر فهرست سیستم را نادیده گرفته و نام را از میان تونل به ارائه‌دهنده رمزنگاری‌شده خودش فرستاده است.
این تفاوت در لحظه‌ای اهمیت دارد که یک نام خصوصی شکست می‌خورد. در چیدمان نخست حل‌کننده VPN برای منطقه شرکتی پاسخ می‌دهد؛ در دومی مرورگر هرگز از آن نپرسیده، پس نام میزبان کوتاه حل نمی‌شود و شکست مانند VPN خراب به نظر می‌رسد. این بررسی یک آزمون نشتی دیگر نیست، جست‌وجویی برای نامی است که فقط یک حل‌کننده می‌داند.
افسانه دوم: مرورگر تونل را ترک می‌کند
DNS نشانی را انتخاب می‌کند، مسیریابی اتصال را حمل می‌کند، و این دو لایه جداگانه‌اند. پرس‌وجویی که به یک ارائه‌دهنده عمومی DoH فرستاده می‌شود هنوز TCP درگاه 443 به نشانی‌ای قابل مسیریابی است. اگر جدول مسیر شما مسیر پیش‌فرض را به تونل بفرستد، آن پرس‌وجو هم از تونل می‌گذرد. برند حل‌کننده مسیر را تعیین نمی‌کند.
آنچه DoH مرورگر تغییر می‌دهد گیرنده نام‌هاست. این یک تصمیم واقعی حریم خصوصی و یک تصمیم واقعی سیاست است، اما دور زدن مسیریابی نیست. اگر الزام شما این است که نام‌ها نزد اپراتور VPN بمانند، پرس‌وجوی رمزنگاری‌شده به شخصی دیگر آن الزام را برآورده نمی‌کند، در حالی که همچنان از تونل برای اتصال واقعی استفاده می‌کند.
افسانه سوم: هر VPN بر هر مرورگری چیره می‌شود
DNS امن در مرورگر حالت دارد، نه کلید: خاموش، ارائه‌دهنده پیش‌فرض با جایگزین، الگوی سفارشی، یا سیاستی که سیستم عامل یا سازمان اعمال می‌کند. همین حالت جایگزین است که گزارش‌های گاه‌به‌گاه تولید می‌کند. وقتی نقطه پایانی رمزنگاری‌شده در دسترس نیست، مرورگر ممکن است به حل‌کننده سیستم بازگردد، پس همان لپ‌تاپ دوشنبه یک نام خصوصی را درست حل می‌کند و سه‌شنبه نه.
در همان زمان، بیشتر کارخواه‌های VPN هنگام بالا آمدن اتصال حل‌کننده سیستم را تنظیم می‌کنند و هنگام قطع آن حل‌کننده قبلی را بازمی‌گردانند. مرورگری که یک حل‌کننده رمزنگاری‌شده سفارشی نگه می‌دارد آن بازگردانی را اصلاً مشاهده نمی‌کند. به همین دلیل همان نمایه روی دو لپ‌تاپ متفاوت رفتار می‌کند و به همین دلیل resolv.conf درست به نظر می‌رسد در حالی که مرورگر هنوز از شخص دیگری می‌پرسد.
resolvectl status # per-link DNS servers and split-DNS domains
scutil --dns | head -30 # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1 # ask the VPN resolver directlyاین‌ها را هنگام اتصال اجرا کنید، توجه کنید هر حل‌کننده کدام دامنه‌ها را ادعا می‌کند، و با آنچه مرورگر درباره حالت خودش گزارش می‌دهد مقایسه کنید. مستندات DoH موزیلا توصیف معقولی است از اینکه رفتار پیش‌فرض و جایگزین مرورگر چگونه باید کار کند.
تصمیم سه ورودی دارد، نه یکی
نام‌های خصوصی، اعتماد به اپراتور و دسترسی‌پذیری چیدمان درست را تعیین می‌کنند. نام‌هایی که فقط حل‌کننده VPN می‌داند DNS تفکیک‌شده را الزامی می‌کنند: پسوند خصوصی به حل‌کننده فرستاده‌شده می‌رود، و بقیه از سیاستی پیروی می‌کند که برای نام‌های عمومی انتخاب کرده‌اید. اعتماد به اپراتور تعیین می‌کند که نام‌های عمومی هم باید به همان حل‌کننده بروند یا به سرویسی جدا. دسترسی‌پذیری تعیین می‌کند که حل‌کننده رمزنگاری‌شده انتخابی شما اصلاً در این شبکه قابل استفاده است یا نه.
| Condition | What it forces |
|---|---|
| Internal names must resolve | Split DNS: private suffixes to the VPN resolver, the rest to your chosen default |
| Queries must stay with one operator | Pin both the system resolver and the browser mode, and disable fallback |
| Resolver only reachable through the tunnel | Keep the pushed resolver; do not point DoH at an endpoint your routes exclude |
هیچ‌یک از این سطرها توصیه جهانی نیست. حل‌کننده‌ای که VPN اداره می‌کند مشاهدات را نزد همان اپراتور متمرکز می‌کند؛ سرویس جدا گیرنده دیگری برای نام‌های پرسیده‌شده اضافه می‌کند. هیچ‌یک از این چیدمان‌ها چیزی درباره نگهداری اثبات نمی‌کند مگر اینکه سیاست را بخوانید.
تصمیم را برای هر نمایه بنویسید، چون این تنظیم‌ها جابه‌جا می‌شوند. نمایه‌ای که ماه گذشته حل‌کننده‌ای را فرستاده ممکن است امروز چیزی نفرستد، و مرورگر با خوشحالی نقطه پایانی سفارشی قدیمی‌ای را نگه می‌دارد که هنوز پاسخ می‌دهد. آنچه باید در یادداشت باشد نشانی حل‌کننده، پسوندهایی که در اختیار دارد و حالت مرورگر است، نه برند سرویس.
سیاستی را که فکر می‌کنید پیکربندی کرده‌اید بیازمایید
با نام بیازمایید، نه با نشان. یک نام عمومی و یک نام خصوصی را از طریق حل‌کننده سیستم حل کنید، سپس آن را درون مرورگر با تنظیم DNS امن خودش در حالتی که قصد دارید استفاده کنید تکرار کنید. اگر نام خصوصی فقط در مرورگر شکست بخورد، ناهماهنگی گیرنده را بدون دست زدن به حتی یک تنظیم VPN پیدا کرده‌اید.
سپس دوباره وصل شوید و بازگردانی را بررسی کنید، چون خطاهای تحویل همان‌جا زندگی می‌کنند: قطع کنید، تأیید کنید حل‌کننده قبلی برگشته است، دوباره وصل کنید، تأیید کنید حل‌کننده فرستاده‌شده برگشته است. در پایان، اگر دارید مرورگری با سیاست مدیریت‌شده را بیازمایید، چون آن حالت ممکن است تغییر شما را کاملاً رد کند و بی‌صدا حل‌کننده قبلی را نگه دارد.
با پرسش فضای نام شروع کنید و بیشتر این مشکلات را دور می‌زنید. اگر ماشین باید به نام‌های داخلی برسد، حل‌کننده رمزنگاری‌شده مرورگر تصمیمی فقط درباره نیمه عمومی است، و نیمه خصوصی نزد هر چیزی می‌ماند که VPN فرستاده است.