فیلتر DNS در VPN: مسدود کردن نام‌ها آگهی‌ها را مسدود نمی‌کند

یک خط dnsmasq می‌تواند به یک نام با NXDOMAIN پاسخ دهد، و همین کل سازوکار است. هرگز HTML نمی‌خواند، هرگز مسیر یک درخواست را بررسی نمی‌کند و هرگز نمی‌بیند یک برنامه با اتصالی که پیش‌تر باز کرده چه می‌کند. بنابراین مقایسه آن با یک افزونه مرورگر، مقایسه دو کار متفاوت است. یکی تصمیم می‌گیرد نامی حل می‌شود یا نه؛ دیگری تصمیم می‌گیرد پس از آن چه رخ می‌دهد.

یک فیلتر نام در واقع چه چیزی را کنترل می‌کند

گزینه address=/metrics.example/، بدون هیچ چیز پس از آخرین اسلش، باعث می‌شود حل‌کننده برای آن نام و زیردامنه‌هایش NXDOMAIN برگرداند. خالی گذاشتن نشانی بخش مهم ماجراست: جلوی فرستادن کلاینت‌ها به یک سرور جایگزین بی‌ربط یا جا زدن یک نشانی loopback به‌عنوان مقصد واقعی را می‌گیرد. راهنمای dnsmasq این شکل را پاسخی منفی می‌داند، نه یک تغییر مسیر.

هر کاری که قاعده می‌تواند بکند از همان یک تصمیم برمی‌آید. کلاینتی که از این حل‌کننده می‌پرسد پاسخ منفی می‌گیرد؛ کلاینتی که از حل‌کننده دیگری می‌پرسد هر چه آن حل‌کننده بگوید می‌گیرد. فیلتر هیچ چیزی درباره مسیر، رشته پرس‌وجو یا حسابی که برنامه به کار می‌برد نمی‌داند.

این ریزدانگی مهم است چون یک نام میزبان اغلب چند کاربرد دارد. نقاط ورود، تصاویر و ردیابی می‌توانند یک دامنه را شریک شوند، و قاعده‌ای که کل نام را حذف می‌کند ممکن است یک گردش کار را هم با آن حذف کند. سیاستی در سطح نام باید این معامله را بپذیرد یا نام‌های باریک‌تری انتخاب کند.

مسدودکننده سمت کلاینت کجا متفاوت است

افزونه مرورگر درخواست را پیش از بیرون رفتن می‌بیند، پس می‌تواند مسیر یک URL را تطبیق دهد، درخواست مشخصی را لغو کند و عنصری را که نتیجه را نشان می‌داد پنهان کند. می‌تواند example.com/article را اجازه دهد و example.com/ads/ را رد کند، چیزی که هیچ پاسخ DNS نمی‌تواند بیان کند. این دید در سطح مسیر همان توانایی است که حل‌کننده به‌سادگی ندارد. به همین دلیل هم فهرست فیلتری که برای یک ابزار ساخته شده، در ابزار دیگر به‌ندرت یکسان رفتار می‌کند.

هزینه، دامنه پوشش است. آن حفاظت درون یک مرورگر، در یک نمایه، روی یک دستگاه زندگی می‌کند و وقتی کاربر به برنامه دیگری می‌رود از میان می‌رود. فیلتر DNS که روی دروازه تنظیم شده هر دستگاهی را پوشش می‌دهد که از حل‌کننده دروازه استفاده می‌کند، از جمله دستگاه‌هایی که هیچ افزونه‌ای روی آن‌ها نصب نمی‌شود.

هیچ‌کدام از این دو چیدمان به‌تنهایی کامل نیست. فیلتر DNS نمی‌تواند شناسه‌ای را که صفحه پیش‌تر فرستاده حذف کند، و افزونه مرورگر نمی‌تواند از برنامه‌ای که هرگز آن را بار نمی‌کند محافظت کند.

مسیر حل‌کننده تعیین می‌کند که آیا هیچ‌یک از این‌ها اعمال می‌شود

یک VPN می‌تواند یک سرور DNS اعلام کند و با این حال هر پرس‌وجو را دریافت نکند. مرورگری با DNS رمزنگاری‌شده تنظیم‌شده، برنامه‌ای با حل‌کننده خودش، یا دستگاهی روی مسیر شبکه‌ای که دروازه را کنار می‌گذارد، همه جای دیگری را نگاه می‌کنند. سکوهای همراه روزبه‌روز تنظیم DNS خصوصی را عرضه می‌کنند که بی‌صدا چیزی را که تونل پیشنهاد می‌کند کنار می‌گذارد.

پس مسیر را بیازمایید، نه سیاست را. از دروازه مستقیماً از حل‌کننده موردنظر بپرسید، سپس از یک کلاینت بپرسید و مقایسه کنید، و سپس ببینید آیا نامی که باید مسدود شود واقعاً در برنامه‌ای که کاربر اجرا می‌کند شکست می‌خورد.

پاسخ‌های ذخیره‌شده و سوکت‌های باز این را پر سر و صدا می‌کنند. صفحه‌ای که منابعش را پیش‌تر بار کرده پس از تغییر قاعده همچنان کار می‌کند، پس یک اتصال تازه آزمون بهتری از بارگذاری دوباره یک زبانه کهنه است.

پیش از اعلام نتیجه، هر دو جهت را بیازمایید

از یک نام مستندات که عمداً مسدود شده، یک نام عمومی مجاز و یک نام خصوصی که سرویس به آن نیاز دارد استفاده کنید:

$ dig +short metrics.example @10.40.0.53
$ dig +short example.com @10.40.0.53
$ dig +short intranet.corp.internal @10.40.0.53

پاسخ خالی برای نام مسدود، یک نشانی عادی برای نام عمومی و یک نشانی خصوصی برای نام داخلی با هم نشان می‌دهند که فیلترکردن، حل رو به بالا و رکوردهای محلی همه کار می‌کنند. اگر هر سه شکست بخورند، با مشکلی در بالادست یا در شنونده روبه‌رو هستید، نه با یک فیلتر.

ادعا را در هر چیزی که داخلی منتشر می‌کنید باریک نگه دارید. این فیلترکردن دامنه روی یک حل‌کننده است، نه بازرسی محتوا، نه فیلترکردن مسیر و نه وعده‌ای که هیچ‌کس ردیابی نمی‌شود. مالک سیاست، مسیر استثنا و دوره نگهداری پرس‌وجوها را در کنار قاعده‌ها بنویسید، چون فیلتری که هر جست‌وجو را ثبت می‌کند هزینه حریم خصوصی خودش را دارد.