هدایت کارخواهان OpenVPN به یک حل‌کننده Pi-hole روی میزبان دیگر

گذاشتن یک نشانی Pi-hole در نمایه OpenVPN مسیری به آن نمی‌سازد، اجازه پرس‌وجو نمی‌دهد و تضمین نمی‌کند که کارخواه از آن استفاده کند. وقتی Pi-hole روی ماشین جداگانه‌ای در LAN است، چهار چیز باید هم‌راستا شوند: مسیر از کارخواه، هدایت از دروازه، مسیر بازگشت به استخر و سیاست پذیرش روی خود Pi-hole. هر شکست در گزارش متفاوت دیده می‌شود. رسیدگی به آن‌ها به همین ترتیب سریع‌تر از درست‌کردن آخری به‌عنوان اولی است. میان‌بر معمول، بازکردن بازگشت برای هر مبدأ، مشکل کوچک را با مشکل دائمی عوض می‌کند.

گزینه DNS هل‌داده‌شده چه می‌کند و چه نمی‌کند

سرور با دستور زیر یک حل‌کننده را اعلام می‌کند، با فرض اینکه 192.168.50.53 میزبان Pi-hole است. کارخواه گزینه را دریافت می‌کند و، بسته به سکو و یکپارچگی حل‌کننده ، آن را روی رابط تونل اعمال می‌کند یا به سود یک stub محلی نادیده می‌گیرد. خط مسیر به‌اندازه خط DNS مهم است، چون حل‌کننده‌ای که کارخواه به آن نمی‌رسد اصلاً حل‌کننده نیست. هیچ‌یک از این‌ها از سمت سرور دیده نمی‌شود.

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

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

گزینه درباره سمت سرور هم چیزی نمی‌گوید. ترافیک DNS هنوز باید از کارخواه به دروازه و از دروازه به Pi-hole برسد تا هر گزینه‌ای معنا پیدا کند. مسیر گم‌شده و پرس‌وجوی ردشده از دید کارخواه یکسان دیده می‌شوند، پس نخست هدایت را روی دروازه تأیید کنید.

مسیر بازگشت از Pi-hole به استخر

اگر نشانی مبدأ کارخواه حفظ شود، Pi-hole به نشانی درون استخر VPN پاسخ می‌دهد. جدول مسیریابی خودش احتمالاً چیزی از این استخر نمی‌داند، پس پاسخ به دروازه پیش‌فرضش می‌رود و ناپدید می‌شود. گزارش پرس‌وجو درخواستی بدون پاسخ متناظر نشان می‌دهد، که به‌راحتی با مشکل دیوار آتش اشتباه گرفته می‌شود.

به مسیریاب LAN یک مسیر ایستا برای استخر با دروازه OpenVPN به‌عنوان پرش بعدی بدهید، یا مبدأ را روی دروازه پیش از هدایت به Pi-hole ترجمه کنید. اولی نشانی هر کارخواه را در گزارش پرس‌وجوی Pi-hole دیدنی نگه می‌دارد. دومی شرط مسیر بازگشت را برمی‌دارد اما هر پرس‌وجو را طوری نشان می‌دهد که گویی از دروازه آمده است. هیچ‌کدام غلط نیست؛ آن‌ها به پرسش‌های متفاوتی پاسخ می‌دهند.

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

حالت شنود Pi-hole برای کارخواهان مسیریابی‌شده

فهرست کشویی رفتار شنود رابط‌ها، در صفحه تنظیمات زیر DNS، تعیین می‌کند Pi-hole به کدام مبدأها پاسخ دهد. سخت‌گیرانه‌ترین گزینه فقط کارخواهان شبکه‌های مستقیماً متصل را می‌پذیرد؛ گزینه‌ای که دستگاه‌ها را حداکثر یک پرش دورتر اجازه می‌دهد آن را به زیرشبکه‌های پشت مسیریاب مجاور گسترش می‌دهد، و کارخواه VPN مسیریابی‌شده دقیقاً همین‌طور دیده می‌شود. بسته واقعاً به رابط LAN می‌رسد، اما نشانی مبدأ آن به زیرشبکه دیگری تعلق دارد. این رد سیاست است نه شکست مسیریابی، و تفاوتش هنگام خواندن گزارش‌ها مهم است.

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

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

پاسخ را با گزارش پرس‌وجو تطبیق دهید

از کارخواه بپرسید، سپس سرور را بررسی کنید و دو را مقایسه کنید. روی کارخواه systemd-resolved دستورهای زیر گزارش می‌دهند کدام حل‌کننده پاسخ تولید کرده و کدام سرورها برای هر پیوند پیکربندی شده‌اند. از نامی استفاده کنید که فقط Pi-hole می‌داند، چون پرس‌وجوی مستقیم به نشانی Pi-hole دسترس‌پذیری را ثابت می‌کند نه پیکربندی را.

resolvectl query intranet.example.lan
resolvectl dns

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

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

قاعده هدایت دروازه را بررسی کنید

دروازه باید بسته‌های DNS کارخواه را به‌سوی Pi-hole هدایت کند، و قاعده‌ای که این کار را می‌کند ارزش خواندن دارد نه فرض‌کردن. دستورهای زیر قاعده‌هایی را که به درگاه 53 دست می‌زنند با شمارنده فهرست می‌کنند، روی میزبان nftables و روی میزبان iptables. قاعده‌ای که وجود دارد اما صفر تطابق نشان می‌دهد، نشانه آن است که ترافیک پیش از ترجمه دور ریخته می‌شود.

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

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

هر ابزاری که میزبان به کار می‌برد، بررسی را تنگ نگه دارید: استخر به‌عنوان مبدأ، درگاه 53 به‌عنوان مقصد و Pi-hole به‌عنوان تنها هدف مجاز. قاعده هدایت گسترده‌ای که درگاه 80 را هم مجاز می‌کند، مشکل دیگری است که در انتظار رخ دادن است.