چرا Pi-hole v6 پرس‌وجوهای DNS کلاینت‌های WireGuard را نادیده می‌گیرد

Pi-hole v6 یک پرس‌وجوی DNS روی پورت 53 دریافت می‌کند و سپس تصمیم می‌گیرد آیا بسته‌ای که رسیده اجازه دارد پاسخ بگیرد. روی میزبان WireGuard، این تصمیم دوم معمولاً دلیل آن است که کلاینت دچار تایم‌اوت می‌شود، در حالی که تحلیلگر از دید LAN سالم به نظر می‌رسد. پورت باز است، FTL در حال اجراست، با این حال چیزی از 10.90.0.1 برنمی‌گردد. سه چیز پیش از خروج پاسخ بر هم اثر می‌گذارند: dns.interface، dns.listeningMode و دیوار آتش پیش از هر دو.

سوکت شنود تعیین نمی‌کند چه کسی پاسخ می‌گیرد

FTL شنودگرهای UDP و TCP را روی پورت 53 باز می‌کند. در پیکربندی پیش‌فرض سوکت غالباً wildcard است، بنابراین ss -lunp | grep :53 نشانی‌های 0.0.0.0:53 و [::]:53 را نشان می‌دهد، چه کلاینت‌های VPN سرویس بگیرند چه نگیرند. سوکت wildcard بسته را می‌پذیرد، سپس FTL پیش از پاسخ دادن قواعد رابط و مبدأ را اعمال می‌کند. به همین دلیل جمله «پورت گوش می‌دهد» چیز بسیار کمی درباره یک کلاینت تونل اثبات می‌کند.

پیکربندی در حال اجرا را بخوانید، نه فایلی که فکر می‌کنید فعال است. pihole-FTL --config dns.interface و pihole-FTL --config dns.listeningMode مقادیر مؤثر را چاپ می‌کنند و می‌توانند با فایل میزبان تفاوت داشته باشند، وقتی یک کانتینر، متغیر محیطی یا مدیر استقرار صاحب آن تنظیم است. مرجع پیکربندی Pi-hole FTL حالت‌ها و اینکه کدام‌یک به رابط وابسته است را فهرست می‌کند.

LOCAL می‌پرسد کدام زیرشبکه، SINGLE می‌پرسد کدام رابط

LOCAL، حالت پیش‌فرض، به پرس‌وجوهایی پاسخ می‌دهد که نشانی مبدأ آن‌ها به زیرشبکه‌ای تعلق دارد که روی یکی از رابط‌های میزبان پیکربندی شده است. یک wg0 ساده با 10.90.0.1/24 این آزمون را می‌گذراند، چون کلاینت روی 10.90.0.2 درون زیرشبکه تونل قرار دارد. کلاینت مسیریابی‌شده در آن سوی یک همتا، یا کلاینتی پنهان پشت NAT در پیشوندی دیگر، آن را نمی‌گذراند، هرچند بسته روی wg0 رسیده است، و هیچ پرس‌وجویی در گزارش دیده نمی‌شود.

SINGLE پرسش را تغییر می‌دهد. پرس‌وجوهایی را می‌پذیرد که روی رابط نام‌برده‌شده در dns.interface می‌رسند، با احتساب loopback، و زیرشبکه مبدأ را نادیده می‌گیرد. این همان حالتی است که از یک توپولوژی VPN زنجیره‌ای یا مسیریابی‌شده جان سالم به در می‌برد. هر دو کلید را با هم تنظیم کنید، چون حالتی بدون رابط نام‌برده‌شده دستور کامل نیست:

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

BIND سوکت را تغییر می‌دهد و این هزینه‌ای دارد

BIND سوکت wildcard را فیلتر نمی‌کند؛ پورت 53 را فقط به نشانی‌هایی می‌بندد که روی رابط نام‌برده‌شده وجود دارند، بنابراین کرنل بسته‌هایی را که جای دیگری می‌رسند رد می‌کند. سخت‌گیرانه‌تر از SINGLE است و مترادف آن نیست. هزینه در زمان راه‌اندازی پیدا می‌شود: اگر wg0 هنگام شروع FTL بالا نباشد، ممکن است نشانی‌ای برای بستن نباشد و تحلیلگر تا زمانی که رابط پدیدار شود و FTL دوباره راه‌اندازی شود، بدون شنودگر کار کند.

BIND را انتخاب کنید وقتی ترتیب راه‌اندازی را کنترل می‌کنید، مثلاً واحدی در systemd که پس از رابط WireGuard مرتب شده است، و وقتی می‌خواهید کرنل بسته‌های سرگردان را پیش از دیدن آن‌ها توسط FTL دور بریزد. SINGLE را انتخاب کنید وقتی تونل می‌آید و می‌رود، یا وقتی رابط را ابزاری می‌سازد که پس از FTL شروع می‌شود.

دیوار آتش دروازه دوم است

حالت درست FTL هم اگر دیوار آتش میزبان پورت 53 را روی wg0 دور بریزد شکست می‌خورد. بازه مبدأ VPN را برای هر دو پروتکل مجاز کنید و سمت اینترنت را بسته نگه دارید. در nftables، با زنجیره input موجود در جدول inet filter، قواعد چنین‌اند:

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

اگر تونل IPv6 حمل می‌کند قواعد IPv6 متناظر را اضافه کنید و آن‌ها را پیش از سیاست drop زنجیره بگذارید. اگر میزبان از ufw یا firewalld استفاده می‌کند، همان انطباق را در آن مدیر بیان کنید، نه اینکه ابزارها را قاطی کنید. پورت 53 را از مسیریاب اینترنت به جلو نفرستید؛ کلاینت‌ها باید نشانی VPN تحلیلگر را از طریق تونل برسند.

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

پاسخ و رد را بررسی کنید

از یک کلاینت VPN، نشانی تحلیلگر را با هر دو پروتکل بپرسید: dig @10.90.0.1 example.com و dig +tcp @10.90.0.1 example.com. سپس گزارش پرس‌وجو را در رابط مدیریت بررسی کنید تا تأیید شود FTL پرس‌وجو را ثبت کرده است. تایم‌اوت کلاینت بدون ورودی در گزارش به دیوار آتش یا فیلتر رابط اشاره دارد؛ ورودی گزارش بدون پاسخ به حل بالادستی اشاره دارد.

مسیر منفی را از میزبانی بیرون از VPN آزمایش کنید. dig @10.90.0.1 example.com باید تایم‌اوت شود، و ss -lunp روی تحلیلگر نباید پورت 53 را بسته‌شده به یک نشانی عمومی نشان دهد. سرویس را یک بار دوباره راه‌اندازی کنید، سپس میزبان را دوباره راه‌اندازی کنید و تأیید کنید تحلیلگر پس از بازگشت wg0 همچنان پاسخ می‌دهد. پرس‌وجویی که فقط تا راه‌اندازی مجدد بعدی کار می‌کند، تغییری تمام‌شده نیست.