فیلتر DNS از طریق VPN بارگذاری یک وبسایت را متوقف کرد: پاسخ را بخوانید
یک حلکننده فیلترکننده میتواند یک نام را مسدود کند در حالی که تونل کار میکند. نوع پاسخ را بخوانید، بفهمید حلکننده از کیست و فقط چیزی را تغییر دهید که خودتان کنترل میکنید.
یک نام شکست میخورد در حالی که تونل برپاست، و مرورگر آن را خطای شبکه مینامد، در حالی که علت واقعی پاسخی است که حلکننده برگردانده است. یک حلکننده فیلترکننده میتواند یک نام را نگه دارد، رد کند یا بازنویسی کند و هر جستجوی دیگر را سالم بگذارد. تونل پرسوجو را حمل میکند؛ حلکننده پاسخ را تعیین میکند. پیش از دست زدن به تنظیمات رمزنگاری، همان پاسخ را بررسی کنید.
تونل برپاست، پس رمزنگاری مظنون نیست
وضعیت اتصال میگوید بستهها جابهجا میشوند یا نه، نه اینکه نامی حل میشود یا نه. حلسازی پرسوجویی است به سروری که کارخواه با آن پیکربندی شده است، و سیاستی در آنجا میتواند به یک دامنه متفاوت از بقیه پاسخ دهد. از سمت مرورگر همهٔ آن پاسخها در یک خطای عمومی فرو میریزند، به همین دلیل چراغ وضعیت چیز کمی را ثابت میکند.
نخست سه چیز را یادداشت کنید: حلکنندهای که کارخواه استفاده کرد، کد پاسخ برای نامی که شکست میخورد، و همان پرسوجو برای نامی که باید کار کند. با dig example.com @10.20.0.1 مستقیماً از حلکننده بپرسید و خط وضعیت را بخوانید، نه پیام مرورگر را. اگر نام کنترل حل شود و نام شکستخورده پاسخی سیاستی برگرداند، شواهد کامل است. اگر هر دو شکست بخورند، فیلتر هنوز در میان نیست.
چهار پاسخ، چهار مالک متفاوت
حلکننده فیلترکننده تنها یک راه برای گفتن نه ندارد، و شکل رد کردن به گام بعدی متفاوتی اشاره میکند. کد پاسخ را بنویسید، زیرا مرورگر هر چهار را به چیزی بازنویسی میکند که شبیه اتصال قطعشده است.
| Answer | What it points at |
|---|---|
| NXDOMAIN | The name is withheld: a policy entry or a zone decision removed it |
| Refused | The resolver declines to answer; usually an access or policy rule |
| Replacement address | A redirect to a block page or sinkhole you can query and inspect |
| No answer at all | Weakest evidence: reachability, load or routing, not necessarily policy |
پاسخ را با جدول تطبیق دهید پیش از آنکه چیزی را به تونل نسبت دهید. رد کردن و نام نگهداشتهشده هر دو یعنی حلکننده تصمیمی گرفته است، در حالی که سکوت یعنی پرسوجو هرگز پاسخی نگرفت. همین تفاوت تعیین میکند که دنبال مالک سیاست بروید یا مسیر شبکه.
دو مرورگر میتوانند دو سیاست را دنبال کنند
مرورگری که حلکننده رمزنگاریشده خود را میآورد لازم نیست از سروری استفاده کند که سیستمعامل توزیع میکند، پس میتواند سیاستی را که تونل برای اعمال آن ساخته شده نادیده بگیرد. آنگاه دو مرورگر روی یک دستگاه درباره یک نام میزبان اختلاف دارند و هیچکدام خراب نیست. بررسی کنید هر برنامه به کدام حلکننده بسته است پیش از آنکه فیلتر را ناسازگار بخوانید.
وقتی هر دو برنامه از حلکننده تونل استفاده میکنند و فقط یکی شکست میخورد، تفاوت در برنامه است نه در DNS. نشانی حلکننده را برای هر برنامه بنویسید، چون این جزئیات با بسته شدن پنجره از بین میرود.
آنچه مالک آن هستید را تغییر دهید، آنچه نیست را بالا ببرید
گام بعدی شما به این بستگی دارد که حلکنندهای که به آن اشاره میکنید از کیست. آنکه خودتان اداره میکنید قابلیتی است که میتوانید بخوانید و پیکربندی کنید: گزینه مستند فیلتر و استثناهایش را بررسی کنید، سپس همان یک نام را مجاز کنید. آنکه کارفرما یا ارائهدهندهتان اداره میکند تیکتی است با دامنه، پاسخ دقیق و زمان.
هرگز حلکننده عمومی را جایگزین نکنید تا سایت را به زور باز کنید، چون نامهای خصوصی دیگر حل نمیشوند و سیاست عمدی دیگر اعمال نمیشود. تغییر باریک شواهد را هم دستنخورده نگه میدارد، تا مالک بتواند گزارش شما را با سوابق خود بسنجد. پس از تغییر، آزمون اصلی برنامه را تکرار کنید نه جستجو از پوسته.
صفحه مسدودسازی گواهی قابلاعتماد نیست
صفحه جایگزینی که گواهی خود را ارائه میدهد هشدار هویت HTTPS ایجاد میکند، و تغییر مسیر آن گواهی را معتبر نمیکند. چون تونل برپاست از آن رد نشوید؛ هشدار تصمیمی جداگانه درباره اعتماد است که هنوز باید درست باشد.
تشخیص زمانی بسته میشود که نام شکستخورده پاسخی سیاستی و نام کنترل پاسخی عادی از همان حلکننده بگیرد. در آن نقطه تعمیر تغییر سیاست است نه تغییر تونل، و RFC 1035 کدهای پاسخ چیزی است که در گزارش نقل میکنید. هر دو نام و پاسخ را کنار هم نگه دارید؛ تمام ماجرا همین است.