Pi-hole پس از اتصال VPN تبلیغات را مسدود نمی‌کند: پنج بررسی

تبلیغات هنوز در یک کلاینت نمایش داده می‌شوند، Pi-hole خود را سالم اعلام می‌کند و تونل برپاست، بنابراین غریزه می‌گوید ترافیک آن کلاینت را از میان Pi عبور دهیم. این چرخش اشتباهی است. فیلتر کردن به پرسش‌ها نیاز دارد، نه به بسته‌ها، و کلاینتی که پرس‌وجوهایش به resolver ارائه‌دهنده خدمات می‌رود، هر جا که ترافیکش جریان یابد، فیلترنشده می‌ماند. این فهرست را به ترتیب دنبال کنید و در نخستین گامی که شکست می‌خورد توقف کنید، زیرا گام بعدی تا زمانی که گام پیشین خراب است هیچ چیزی به شما نمی‌گوید.

1. resolverی را بخوانید که کلاینت واقعاً استفاده می‌کند

از کلاینت بپرسید، نه از روتر. در Linux دستور resolvectl status سرورهای DNS را به تفکیک پیوند و اینکه کدام پیوند برنده است چاپ می‌کند؛ /etc/resolv.conf به‌تنهایی معمولاً یک stub است که به 127.0.0.53 اشاره می‌کند. در Windows دستور ipconfig /all سرورهای ارائه‌شده از سوی DHCP را به تفکیک آداپتور فهرست می‌کند، و در macOS دستور scutil --dns همین را بر حسب دامنه نشان می‌دهد. اگر پاسخ نشانی Pi-hole نیست، مشکل تخصیص دارید و گام 2 همان جایی است که این مشکل آنجاست.

دو چیز resolver سیستم را حتی وقتی درست تنظیم شده شکست می‌دهد. مرورگرهایی که DNS امن خودشان را دارند (گزینهٔ “Use secure DNS” در Chrome و network.trr.mode در Firefox) پرس‌وجوها را از طریق HTTPS به یک resolver عمومی می‌فرستند و هرگز پورت 53 را باز نمی‌کنند. و یک کلاینت VPN روی خود کلاینت می‌تواند یک سرور DNS روی رابط تونل خود با دامنهٔ مسیریابی ~. نصب کند، که آن پیوند را برای هر نامی معتبر می‌کند.

مسیری را آزمایش کنید که برنامه‌ها طی می‌کنند، نه مسیری که ابزار اشکال‌زدایی طی می‌کند. دستور resolvectl query example.com نشان می‌دهد کدام پیوند پاسخ داده است، و getent hosts example.com از همان مسیر NSS که یک برنامه طی می‌کند می‌گذرد؛ در macOS دستور dscacheutil -q host -a name example.com همان resolverهای دامنه‌ای را می‌خواند که scutil --dns فهرست می‌کند. یک dig خالی این کار را نمی‌کند: /etc/resolv.conf را می‌خواند و انتخاب بر حسب پیوند را نادیده می‌گیرد، بنابراین ممکن است از Pi-hole پاسخ دهد در حالی که هر برنامه از resolver فشارداده‌شده استفاده می‌کند، و این همان شکستی است که این فهرست برای گرفتنش وجود دارد. dig @192.168.1.53 را برای آزمایش یک سرور مشخص نگه دارید.

2. تأیید کنید چه کسی پاسخ را توزیع می‌کند

تخصیص از هر چیزی می‌آید که به DHCP پاسخ می‌دهد. در dnsmasq این یک خط است، dhcp-option=6,192.168.1.53؛ در رابط وب روتر این فیلد DNS در بخش DHCP شبکهٔ محلی است. کلاینت‌ها باید پیش از دیدن آن تمدید کنند. دستگاهی که روزها روشن بوده هنوز اجارهٔ قدیمی را نگه می‌دارد، و دستگاهی که resolver آن دستی تایپ شده آن را برای همیشه نگه می‌دارد. به‌جای فرض کردن انتشار، روی یک کلاینت آزمایشی تمدید کنید.

IPv6 همان نیمی است که از قلم می‌افتد. آگهی‌های روتر می‌توانند سرور DNS خودشان را حمل کنند (RDNSS)، و در OpenWrt این گزینهٔ ra_dns در odhcpd است؛ کلاینتی که IPv6 را ترجیح می‌دهد از آن سرور استفاده می‌کند در حالی که گزینهٔ DHCPv4 که همین حالا تنظیم کردید بی‌استفاده می‌ماند. اگر آمادهٔ ارائهٔ DNS روی IPv6 نیستید، فقط آگهی DNS را پاک کنید: ra_dns در odhcpd، یا گزینهٔ RDNSS در هر چیزی که به آگهی‌های روتر پاسخ می‌دهد. خاموش کردن کل آگهی، نشانی‌دهی IPv6 را هم از شبکهٔ محلی حذف می‌کند، که تغییری بسیار بزرگ‌تر از آن است که در نظر داشتید، در حالی که پاک کردن فقط گزینهٔ DNS نشانی‌دهی را دست‌نخورده نگه می‌دارد و RDNSS غایب را در یک ضبط بسته مرئی می‌کند.

3. ثابت کنید پرس‌وجو به Pi-hole می‌رسد

پرس‌وجو از Pi هیچ چیزی دربارهٔ مسیر شبکه ثابت نمی‌کند. آن را از کلاینت اجرا کنید و کد پاسخ را بخوانید:

dig @192.168.1.53 example.com
dig @192.168.1.53 doubleclick.net

پایان مهلت به فیلتر کردن یا به یک مسیر اشاره می‌کند؛ REFUSED به یک قاعدهٔ دسترسی؛ SERVFAIL به resolver بالادستی پشت Pi-hole؛ پاسخ درستی که هرگز در گزارش پرس‌وجو ظاهر نمی‌شود یعنی کلاینت چیز دیگری پرسیده است. UDP و TCP 53 را بررسی کنید، زیرا پاسخ‌های بزرگ و برخی resolverها به TCP بازمی‌گردند، و وقتی Pi-hole در یک کانتینر اجرا می‌شود هر دو را منتشر کنید. نقشه‌ای که فقط UDP را پوشش می‌دهد، شکست‌های گاه‌به‌گاه تولید می‌کند که شبیه افت بسته است.

سپس حالت شنود Pi-hole تعیین می‌کند که آیا اصلاً پاسخ می‌دهد یا نه. در حالت فقط محلی، dnsmasq پرس‌وجوهای منابعی را که در یک زیرشبکهٔ مستقیماً متصل نیستند نادیده می‌گیرد، و این دقیقاً همان چیزی است که یک کلاینت پشت روتر دیگر یا کلاینتی که از تونل می‌آید شبیه آن است: مهلت کلاینت تمام می‌شود و پرس‌وجو هرگز به گزارش نمی‌رسد. پرس‌وجویی که به‌صورت REFUSED ظاهر می‌شود به‌جای آن توسط یک فهرست دسترسی یا قاعدهٔ فایروال رد شده است. اجازه دادن به همهٔ مبدأها اصلاح معمول است، همراه با قاعدهٔ فایروال که پورت 53 را به زیرشبکه‌های خودتان محدود می‌کند.

4. بررسی کنید که تونل پاسخ را جایگزین کرده یا آن را بلعیده است

این همان حالتی است که هر دو نشانه در آن پنهان‌اند. وقتی روتر خودش یک کلاینت VPN است، یک گزینهٔ DNS فشارداده‌شده می‌تواند در همان لحظه‌ای که تونل بالا می‌آید تنظیم شبکهٔ محلی را بازنویسی کند: سرورهای OpenVPN گزینهٔ dhcp-option DNS را فشار می‌دهند، و پروفایل‌های WireGuard ورودی DNS خودشان را دارند. resolver مؤثر روتر را با تونل فعال بخوانید، نه پیش از آن، و آنچه صفحهٔ شبکهٔ محلی ادعا می‌کند را نادیده بگیرید.

نقص دیگر دسترس‌پذیری است، نه جایگزینی. اگر پیشوندهای مجاز تونل زیرشبکهٔ محلی شما را در بر بگیرد، روتر مسیری دارد که پرس‌وجوهای 192.168.1.53 را به داخل تونل می‌فرستد، و طرف مقابل مسیر بازگشتی ندارد: پرس‌وجوها با اینکه تونل سالم است به پایان مهلت می‌خورند. عکس آن وقتی رخ می‌دهد که Pi-hole در زیرشبکه‌ای باشد که تونل آن را حمل نمی‌کند. پیش از دست زدن دوباره به DNS، نشانی را با پیشوندهای مجاز تونل و جدول مسیریابی روتر مقایسه کنید.

یک اصلاح را انتخاب کنید، نه هر دو را. یا تونل را از DNS دور نگه دارید — با pull-filter ignore “dhcp-option DNS” در OpenVPN و بدون پیشوند محلی در AllowedIPs در WireGuard —، یا resolver فشارداده‌شده را بپذیرید و فیلتر محلی را برای کلاینت‌های پشت آن روتر رها کنید. هر کدام را انتخاب کردید، آن را کنار پروفایل بنویسید، چون فرد بعدی که آن را ویرایش می‌کند در غیر این صورت به‌طور تصادفی تصمیم را برعکس می‌کند.

5. آزمایش را پس از اتصال دوباره تکرار کنید

از یک کلاینت پرس‌وجو کنید، تأیید کنید که آن کلاینت در گزارش Pi-hole ظاهر می‌شود، سپس دامنه‌ای را که باید مسدود شود تجزیه کنید و بررسی کنید که پاسخ مسدودسازی را به‌جای پاسخ واقعی می‌گیرید. تونل را دوباره متصل کنید و همان دو پرس‌وجو را اجرا کنید، زیرا تنظیم resolverی که فقط تا اتصال بعدی دوام می‌آورد نتیجهٔ معمول اصلاحی است که در لایهٔ اشتباه اعمال شده است.

یک مسیر resolver ثانویه باقی بگذارید که به تونل وابسته نیست، تا قطعی Pi-hole به مرور بدون فیلتر تنزل یابد نه به هیچ مروری. مقادیر پیشین DHCP و resolver را تا وقتی آزمایش دو بار موفق شود نگه دارید؛ تغییری که اینترنت خانه را سر شام قطع می‌کند بسیار سخت‌تر از تغییری است که می‌توانید در یک دقیقه برگردانید.