چرا هات‌اسپات پیش از اتصال VPN، DNS را تغییر مسیر می‌دهد؟
هات‌اسپات جست‌وجوها را در شبکه خودش بازنویسی می‌کند و نقطه پایانی نام میزبان پیش از وجود هر تونلی حل می‌شود. دنبال کنید کدام resolver به هر پرسش پاسخ داده است.
پیوستن به شبکه یک هتل دو تصمیم DNS را در لحظه‌های متفاوت پیش روی شما می‌گذارد: جست‌وجوهایی که دستگاه هنگام ورود انجام می‌دهد، و جست‌وجوهایی که پس از بالا آمدن تونل انجام می‌شوند. هات‌اسپات می‌تواند بر نخستین‌ها از طریق شبکه‌ای که کنترل می‌کند اثر بگذارد. دومی به سیاست خود کلاینت بستگی دارد، که موضوعی جداگانه برای بررسی است.
اتصال را به ترتیب دنبال کنید، از نخستین اجاره DHCP تا پرسشی که یک نام خصوصی را حل کرد. آن‌گاه دو خرابی که در یک تیکت پشتیبانی یکسان به نظر می‌رسند به‌روشنی از هم جدا می‌شوند: یکی پیش از وجود تونل رخ داد و دیگری درون آن.
هات‌اسپات چه چیزی را می‌تواند لمس کند و چه چیزی را نه
شبکه دسترسی نشانی یک resolver را در DHCP توزیع می‌کند و می‌تواند پورت 53 را به سمت آن نشانی رهگیری کند. این برای پاسخ دادن به هر جست‌وجوی محافظت‌نشده با نشانی درگاه یا صفحه مسدودسازی کافی است. برای شکستن کلاینت VPN که نقطه پایانی‌اش به شکل نام میزبان نوشته شده هم کافی است.
چیزی که هات‌اسپات نمی‌تواند بکند خواندن یا بازنویسی پرسش است، وقتی که درون یک تونل برقرار سفر می‌کند، به شرط آنکه تونل واقعاً آن را حمل کند. رهگیری وابسته به دیدن پرسش به‌صورت متن ساده است.
پرسش‌ها به هر حال تونل را ترک می‌کنند، به دلایلی که ربطی به هات‌اسپات ندارند: تنظیم DNS امن مرورگر، قاعده split-DNS که پسوند سازمانی را روی resolver محلی نگه می‌دارد، یا کلاینتی که برای کنار گذاشتن DNS از تونل پیکربندی شده است. هر یک انتخابی از سمت کلاینت است و هر یک از بیرون مانند دخالت هات‌اسپات به نظر می‌رسد.
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
جست‌وجوی آغازین پیش از وجود تونل رخ می‌دهد
کلاینتی که نام میزبان دریافت می‌کند باید نخست آن را حل کند و در آن لحظه هیچ تونلی از پرسش محافظت نمی‌کند. اگر هات‌اسپات با نشانی درگاه پاسخ دهد، مذاکره شکست می‌خورد یا معلق می‌ماند. اگر با هیچ چیز پاسخ دهد، کلاینت خطای نام را گزارش می‌کند و تونل هرگز شروع نمی‌شود. هر یک از این دو نتیجه یک گزارش خالی تونل را توضیح می‌دهد که در غیر این صورت بی‌گناه به نظر می‌رسد.
سیستم‌عامل‌ها بررسی‌های اتصال و کشف درگاه خودشان را هم اجرا می‌کنند، که در RFC 8910 و RFC 8952 توصیف شده‌اند، و این درخواست‌ها پیش از بالا آمدن هر VPN خارج می‌شوند. دیدن آن‌ها در گزارش پروکسی رفتار مورد انتظار است نه اثبات نشت.
راه‌حل عملی این است که به کلاینت نقطه پایانی بدهیم که به جست‌وجو نیاز ندارد. وقتی این ناممکن است، نخست ورود را کامل کنید و سپس متصل شوید.
بفهمید کدام resolver پاسخ داده است
از سیستم بپرسید نه از مرورگر، و پرسش را دو بار اجرا کنید: یک بار از طریق هر resolver که دستگاه اکنون استفاده می‌کند، یک بار علیه یک نشانی ثابت.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
پاسخی از فرمان نخست که با سومی متفاوت است به شما می‌گوید resolver محلی چیز دیگری برمی‌گرداند، و این همان کاری است که هات‌اسپات تغییرمسیردهنده انجام می‌دهد. شکست سومی همراه با موفقیت نخستی به درگاه اشاره دارد: resolver محلی نشانی ورود را سرو کرد در حالی که پورت 53 خروجی کنار گذاشته شده بود. پایان مهلت در هر دو یعنی شبکه تا کامل شدن احراز هویت DNS را دور می‌ریزد.
پس از اتصال تکرار کنید و مقایسه کنید. پاسخ ذخیره‌شده در حافظه پنهان از گذار جان سالم به در می‌برد، پس حافظه پنهان را پاک کنید یا برای مشاهده دوم نام تازه‌ای بپرسید.
جست‌وجوهای بعدی را روی مسیری که در نظر داشتید نگه دارید
پروفایل تونل کامل که DNS را هم می‌گیرد ساده‌ترین چیدمان است: هر پرسش از هر برنامه به resolverی می‌رود که تونل هل می‌دهد، و شبکه محلی فقط ترافیک رمزگذاری‌شده را می‌بیند. این را با حل یک نام داخلی و یک نام عمومی پس از اتصال و سپس مقایسه هر دو پاسخ با آنچه resolver تونل به‌تنهایی برمی‌گرداند ثابت کنید.
Split-DNS به فهرستی از دامنه‌ها نیاز دارد که با قصد نوشته شده باشد: پسوندهای سازمانی از طریق تونل، بقیه به‌صورت محلی، و هیچ همپوشانی میان این دو.
DNS امن مرورگر بیرون از آن سیاست است، پس اگر باید خاموش باشد تا پروفایل به‌طور قابل پیش‌بینی رفتار کند، آن را برای همان پروفایل خاموش کنید نه برای دستگاه. این کار را در تنظیمات مرورگر انجام دهید نه با ویرایش resolver سیستم، تا تغییر دفعه بعد دیده شود. پاسخ، resolver و مرحله اتصال را در یک خط برای هر آزمون ثبت کنید. گزارشی که می‌گوید DNS در Wi-Fi هتل شکست خورده، نشانه‌ای را با دست‌کم سه علت متفاوت توصیف می‌کند.