هات‌اسپات Pi با Pi-hole و VPN: به هر سرویس یک وظیفه بدهید
پیش از فعال کردن سه کمک‌کننده روی یک Pi، تصمیم بگیرید DHCP، DNS و ارسال بسته‌ها متعلق به کیست. مالکیت تکراری، اجاره‌های رقیب و حلقه‌های مفسر تولید می‌کند.
تلفن به هات‌اسپات Pi می‌پیوندد، نشانی می‌گیرد و صفحه باز هم بارگذاری نمی‌شود. روی Pi یک کمک‌کننده هات‌اسپات، Pi-hole و یک کلاینت VPN در حال اجراست و هر یک گمان می‌کند بخشی از مسیر را در اختیار دارد. بیشتر این پیکربندی‌ها نه به این دلیل شکست می‌خورند که مؤلفه‌ای خراب است، بلکه به این دلیل که دو مؤلفه یک کار را انجام می‌دهند. پیش از تنظیم هر یک از آن‌ها، برای هر کارکرد یک مالک تعیین کنید.
برای هر کارکرد یک مالک تعیین کنید
چهار کارکرد در اینجا مهم است و هر یک دقیقاً به یک مالک نیاز دارد. جدول زیر کارکرد، مالک عملی و آنچه را که وقتی دو سرویس آن را ادعا می‌کنند خراب می‌شود نشان می‌دهد.
| Function | Workable owner | Duplicate-owner symptom |
|---|---|---|
| Client addresses | One DHCP server, such as the hotspot helper | Competing offers and changing leases |
| DNS reception | Pi-hole on port 53 | Bind failure or queries answered by the wrong process |
| Forwarding and NAT | One firewall manager | Double translation and broken return paths |
| VPN routing | One client configuration | Route flapping and traffic escaping outside the tunnel |
همپوشانی معمولاً هر بار با یک بسته می‌رسد. کمک‌کننده هات‌اسپات نسخه dnsmasq خود را نصب می‌کند، Pi-hole پورت 53 را می‌خواهد و کلاینت VPN مسیرها را اضافه می‌کند. هر گام به‌تنهایی معقول به نظر می‌رسد، اما با هم ماشینی می‌سازند که در آن دومین سرویسی که شروع می‌شود، بی‌صدا رفتار سرویس اول را تغییر می‌دهد.
پیش از فعال کردن هر چیز دیگری مالکان را بنویسید. یک جدول کوتاه در یادداشت‌های ساخت مانع از آن می‌شود که نصب بعدی کارکردی را که از قبل مالک داشته تصاحب کند.
یک بازه انتخاب کنید و آن را از تونل دور نگه دارید
بازه هات‌اسپات، نشانی Pi در آن، مجموعه DHCP و مفسری که کلاینت‌ها دریافت می‌کنند را انتخاب کنید. آن بازه را از LAN بالادست و از بازه تونل VPN جدا نگه دارید، زیرا زیرشبکه‌های همپوشان یک مشکل مسیریابی را به پروژه ترجمه نشانی تبدیل می‌کنند. بازه‌ای که با تونل همپوشانی دارد، Pi را به مسیریاب تصادفی میان دو پیشوند یکسان تبدیل می‌کند. بازه و مجموعه را در پیکربندی هات‌اسپات بنویسید، نه اینکه آن‌ها را به مقدار پیش‌فرض بسپارید.
اگر حالت اشتراکی NetworkManager مالک هات‌اسپات است، پیش از افزودن سرور DHCP اتصال مؤثر را بررسی کنید. حالت اشتراکی کمک‌کننده‌های خود را راه می‌اندازد و ارسال را فعال می‌کند، پس از قبل مالک طرح نشانی برای آن واسط است. افزودن سرور دوم فقط به این دلیل که در دسترس است، پیشنهادهای رقیب می‌سازد نه افزونگی.
درباره IPv6 آگاهانه تصمیم بگیرید. در بسیاری از پیکربندی‌ها اعلان‌های مسیریاب و DHCPv6 از کمک‌کننده‌ای متفاوت از DHCPv4 می‌آید، و روشن گذاشتن IPv6 در حالی که سیاست VPN فقط IPv4 را پوشش می‌دهد، به کلاینت‌ها مسیری می‌دهد که تونل را دور می‌زند. یا سمت IPv6 را برنامه‌ریزی کنید یا آن را با دلیل نوشته‌شده روی واسط هات‌اسپات غیرفعال کنید.
چه کسی واقعاً روی پورت 53 پاسخ می‌دهد
پیش از تغییر پیکربندی، همه فرایندهایی را که به پورت 53 گوش می‌دهند فهرست کنید. روی Pi که یک stub مفسر محلی، Pi-hole و کمک‌کننده اشتراک اجرا می‌کند، فهرست شنوندگان تنها نقشه مطمئن از این است که چه کسی به پرس‌وجوها پاسخ می‌دهد:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routeراهنمای واسط‌های Pi-hole توضیح می‌دهد که حالت دریافت محدود به یک واسط هنوز می‌تواند از سوکت عام استفاده کند و ورودی‌های جاهای دیگر را دور بریزد. این با اتصال فقط به واسط‌های انتخاب‌شده یکی نیست، و همان ترتیبی است که وقتی سرویس DNS دیگری باید ماشین را شریک شود در نظر گرفته شده است.
دو فرایند معمولاً نمی‌توانند یک نشانی و پورت را به هم متصل کنند، هرچند SO_REUSEPORT می‌تواند اتصال مشترک را موفق کند؛ حتی در آن صورت یک شنونده عام می‌تواند ورودی‌های مربوط به سرویس باریک‌تر را بردارد. حالت مستند مربوط به نقشی را که می‌خواهید انتخاب کنید و سرویس‌ها را به ترتیب در نظر گرفته‌شده دوباره راه‌اندازی کنید.
صفحه مدیریت Pi-hole را خارج از شبکه هات‌اسپات نگه دارید. کلاینت‌ها به مفسر نیاز دارند، نه به واسط وب یا API که می‌تواند پیکربندی مفسر را تغییر دهد.
دو پای DNS، برای هر یک یک سیاست
پرس‌وجوی کلاینت از تلفن به Pi می‌رود و پرس‌وجویی جداگانه از Pi به مفسر بالادست آن می‌رود. قاعده مسیریابی که با ترافیک ارسال‌شده هات‌اسپات مطابقت دارد، به‌طور خودکار بر پای دوم اعمال نمی‌شود، زیرا Pi آن ترافیک را به‌صورت محلی تولید می‌کند. اگر قرار است VPN ترافیک DNS را حمل کند، مسیر محلی به سیاست خودش نیاز دارد.
مراقب حلقه باشید. تنظیم مفسر بالادست Pi-hole روی نشانی‌ای که خود Pi ارائه می‌دهد، مستقیم یا از طریق ارسال پورت، پرس‌وجوهایی می‌سازد که تا پایان مهلت دور می‌زنند. به آن یک مفسر بالادست واقعی یا ارسال‌کننده شرطی برای دامنه‌هایی که نمی‌تواند پاسخ دهد بدهید.
تصمیم بگیرید وقتی تونل قطع می‌شود چه اتفاقی می‌افتد. بازگشت به مفسر محلی مرور را زنده نگه می‌دارد اما می‌تواند نام‌ها را بیرون از VPN نشت دهد؛ مسدود کردن سیاست را دست‌نخورده نگه می‌دارد و قطعی را به خطای دیدنی تبدیل می‌کند. هر دو گزینه قابل دفاع است، اما باید انتخاب شود نه اینکه از یک مقدار پیش‌فرض به ارث برسد.
مسیر و رفتار هنگام قطعی را اثبات کنید
لایه‌به‌لایه آزمایش کنید: کلاینت نشانی می‌گیرد، کلاینت نامی را از طریق Pi حل می‌کند، Pi را از طریق مفسر بالادست در نظر گرفته‌شده حل می‌کند و یک برنامه درخواستی را کامل می‌کند. ping موفق هیچ چیزی درباره DNS نمی‌گوید و جست‌وجوی موفق هیچ چیزی درباره ارسال نمی‌گوید.
dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1سپس تونل را متوقف کنید و تکرار کنید. رفتار در نظر گرفته‌شده باید در چند ثانیه ظاهر شود، نه پس از راه‌اندازی دستی دوباره Pi-hole یا سرویس هات‌اسپات. در طول قطعی تنظیم مفسر کلاینت را بررسی کنید، زیرا یک مفسر عمومی ثانویه حتی وقتی سیاست انتظار شکست داشت به پاسخ دادن ادامه می‌دهد.
یک مالک برای ارسال و NAT نگه دارید و آن را از کلاینت بررسی کنید، نه از خود Pi. درخواستی که با موفقیت از Pi خارج می‌شود باز هم می‌تواند در راه بازگشت حذف شود و کلاینت تنها جایی است که تمام مسیر در آن دیده می‌شود.