وقتی کیل سوئیچ VPN پورت 53 را مسدود می‌کند، DNS حل نمی‌شود
کیل سوئیچ می‌تواند DNS را عمداً مسدود کند. حل نام فقط داخل تونل را با استثنای یک resolver محلی مقایسه کنید و سپس مشخص کنید کدام لایه واقعاً از کار افتاده است.
وقتی کیل سوئیچ تونل را قطع می‌کند، مسیر DNS را هم با خود می‌برد، و resolver باقی‌مانده به‌ندرت همانی است که انتظار دارید. دو طراحی به آن لحظه بسیار متفاوت واکنش می‌دهند: مسدود کردن هر بسته DNS که داخل تونل نیست، یانگه داشتن یک resolver به‌عنوان استثنا. هر دو قابل دفاع است. از یک زبانه مرورگر، نشانه‌ها تقریباً یکسان به نظر می‌رسند، پس کار اول این است که بفهمید واقعاً کدام طراحی را مستقر کرده‌اید.
این تفکیک را پیش چشمانم نگه می‌دارم، چون اصلاح در هر حالت برعکس است. یک طراحی استثنای گسترده‌تر می‌خواهد، دیگری استثنای باریک‌تر. حدس زدن برایتان یا حریم خصوصی را هزینه دارد یا یک بعدازظهر.
دو طراحی DNS برای یک قطعی
طراحی A با resolver مثل هر سرویس دیگری پشت تونل رفتار می‌کند. قواعد فایروال UDP و TCP 53 را فقط روی واسط تونل مجاز می‌کند، و نشانی‌ای که به کلاینت داده می‌شود resolverی داخل تونل است. وقتی تونل قطع می‌شود، جست‌وجوها متوقف می‌شوند، و این نتیجه مطلوب است نه یک عیب.
طراحی B یک resolver را در شبکه محلی در دسترس نگه می‌دارد، معمولاً روتر روی 192.168.1.1 یا stub سیستم‌عامل روی 127.0.0.53، با این استدلال که حل نام نباید با تونل بمیرد. در یک LAN خانگی که روتر برای تمام خانه حل می‌کند، راحت است. در Wi-Fi هتل یا فرودگاه همان استثنا به سرور شخص دیگری اشاره می‌کند، و هر نامی که تایپ می‌کنید افشا می‌شود، هرچند ترافیک وب شما مسدود بماند.
مرز این است که resolver از آنِ کیست. اگر به resolver محلی اعتماد دارید، استثنا یک حفره کوچک و صادقانه است. اگر ندارید، طراحی فقط-تونل تنها گزینه‌ای است که دوام می‌آورد، و بهایش این است که تونل قطع‌شده همه نام‌ها را با خود می‌برد.
چرا جست‌وجوی خودِ کلاینت VPN هنوز کار می‌کند
کلاینت باید پیش از وجود تونل نام میزبان دروازه را حل کند، پس مسدودسازی سخت نباید مسیر راه‌اندازی کلاینت را بپوشاند. بیشتر کلاینت‌ها یا نشانی نقطه پایانی را کش می‌کنند یا استثنای راه‌اندازی مستندشده‌ای برای همان یک میزبان ارائه می‌دهند. اگر مجموعه قواعد شما آن جست‌وجو را مسدود کند، تونل هرگز برنمی‌گردد و گزارش‌ها کلاینتی را نشان می‌دهند که به سرور خودش نمی‌رسد؛ این نقص خط‌مشی است نه نقص DNS.
DNS تقسیم‌شده جای دیگری است که این موضوع ظاهر می‌شود. کلاینت یک ناحیه داخلی را به resolver خصوصی می‌فرستد و بقیه را به resolver سیستم می‌سپارد. پس از قطع، نام‌های عمومی ممکن است هنوز حل شوند در حالی که نام‌های داخلی به پایان زمان می‌رسند، چون ناحیه خصوصی هیچ مسیری ندارد. برای کاربر این یعنی «VPN اینترنت را خراب کرد»؛ برای گزارش resolver یعنی پرس‌وجویی که هرگز نرسید.
در systemd-resolved می‌توانید تقسیم را مستقیم ببینید.resolvectl statusسرورهای DNS هر پیوند و دامنه‌های مسیریابی را فهرست می‌کند، و پس از پایین آمدن تونل، دامنه داخلی همچنان به سروری روی پیوندی اشاره می‌کند که دیگر وجود ندارد. stub روی 127.0.0.53 هنوز پرس‌وجو را می‌پذیرد، سپس منتظر بالادستی می‌ماند که پاسخ نخواهد داد، و به همین دلیل شکست چند ثانیه طول می‌کشد به‌جای اینکه فوراً برگردد.
DNS رمزنگاری‌شده از یک فیلتر بسته عبور نمی‌کند
DNS over HTTPS و DNS over TLS روی 443 و 853 سفر می‌کنند، پس قاعده‌ای که پورت 53 را مسدود می‌کند دربارهٔ آن‌ها چیزی نگفته است. مسدود کردن «DNS» بر اساس پورت یک خط‌مشی دربارهٔ پورت است، نه دربارهٔ حل نام. اگر کیل سوئیچ شما تمام ترافیک بیرون تونل را مسدود کند، DoH به‌طور تصادفی پوشش داده می‌شود. اگر برای یک captive portal یا resolver عمومی استثنا قائل شده‌اید، پوشش داده نمی‌شود.
کنترل‌های سمت کلاینت اهرم ارزان‌تری هستند. Firefox وقتی نام قناریuse-application-dns.netحل نشود resolver DoH خود را رها می‌کند، و به همین دلیل شبکه‌های مدیریت‌شده آن دامنه را به‌صورت NXDOMAIN منتشر می‌کنند؛ خط‌مشی سازمانی هم می‌تواند آن را خاموش تثبیت کند. Android Private DNS و DNS امن Chrome کلیدها و پیش‌فرض‌های خودشان را دارند. خاموش کردن آن‌ها مطمئن‌تر از دنبال کردن نشانی resolverهاست، چون فهرست نشانی‌ها تغییر می‌کند و مجموعه قواعد شما نه.
نسخه‌ای از این هست که اصلاً دربارهٔ نشت نیست. برنامه‌ای با resolver تثبیت‌شده هنوز به مسیر شبکه برای رسیدن به آن نیاز دارد. رمزنگاری تغییر می‌دهد چه کسی پرس‌وجو را می‌خواند، نه اینکه بسته بتواند از دستگاه خارج شود، پس مسدودسازی کل دستگاه تنظیم را بدون لمس کردن آن شکست می‌دهد.
نشانه را به لایه وصل کنید
بیشتر گزارش‌ها به‌صورت یک جمله می‌رسند، و آن جمله معمولاً از قبل لایه را نام می‌برد. جدول زیر چیزی است که پیش از دست زدن به هر قاعده مرور می‌کنم؛ هدف این است که تصمیم بگیرم پرس‌وجو مسدود شد، بد مسیر رفت، یا هرگز فرستاده نشد.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
دو ردیف اول همان‌هایی هستند که مردم بد تشخیص می‌دهند. قطع بی‌صدا و رد کردن هر دو در مرورگر مثل «DNS خراب است» به نظر می‌رسند، اما فقط یکی از آن‌ها یعنی کیل سوئیچ شما کارش را می‌کند. رد کردن یعنی چیزی پاسخ داده، پس مسدودسازی آن‌جایی نیست که فکر می‌کنید.
خط‌مشی resolver را برگردانید و سپس آن را اثبات کنید
طراحی را درست کنید، نه نشانه را. برای حل فقط داخل تونل، 53 را روی واسط تونل مجاز کنید، resolver داخلی را همراه پیکربندی تونل فشار دهید و پیوند فیزیکی را بدون هیچ اجازه DNS بگذارید. در wg-quick خطی که resolver را در پیکربندی واسط می‌نویسدDNS =همان است، پس تونلی که آن را جا بیندازد resolver قدیمی را سر جایش می‌گذارد و هر پرس‌وجو روی مسیر اشتباه می‌رود.راهنمای wg-quickاین رفتار را برای هر پلتفرم مستند می‌کند.
سپس به این ترتیب بررسی کنید. در Linuxresolvectl statusپیوند فعال را نشان می‌دهد،dig +short example.comیک نام عمومی را می‌آزماید،dig @10.8.0.1 internal.example.comنام خصوصی را می‌آزماید، وsudo tcpdump -ni any port 53نشان می‌دهد بسته‌ها هنگام اجرای هر دو از کدام واسط می‌روند. در WindowsGet-DnsClientServerAddress -AddressFamily IPv4وResolve-DnsName example.comهمان دو واقعیت را می‌دهند: چه کسی پیکربندی شده و چه کسی پاسخ می‌دهد.
با آزمون منفی تمام کنید. تونل را قطع کنید، تأیید کنید که یک نام عمومی تازه شکست می‌خورد، تأیید کنید که نام خصوصی شکست می‌خورد، وتأیید کنید که هیچ بستهٔ پورت 53 از آداپتور فیزیکی خارج نشده است. مسدودسازی‌ای که فقط برای پاسخ‌های کش‌شده دوام می‌آورد اصلاً دوام نمی‌آورد.
فهرست بررسی پیش از بستن تیکت:
- resolverی که در زمان قطعی استفاده می‌شود همانی است که خط‌مشی در نظر دارد.
- جست‌وجوی نقطه پایانی خود کلاینت هنوز مجاز است، از طریق کش یا استثنا.
- DoH و DoT یا زیر پوشش مسدودسازی‌اند یا با خط‌مشی غیرفعال شده‌اند.
- ناحیه‌های خصوصی وقتی تونل رفت، بسته شکست می‌خورند نه باز.