Hotspot Pi cu Pi-hole și VPN: atribuie fiecărui serviciu o sarcină

Un telefon se conectează la hotspotul Pi, primește o adresă, iar pagina tot nu se încarcă. Pi rulează un ajutor pentru hotspot, Pi-hole și un client VPN, iar fiecare crede că deține o parte a traseului. Majoritatea acestor instalări eșuează nu pentru că o componentă este defectă, ci pentru că două componente fac aceeași treabă. Stabilește un proprietar pentru fiecare funcție înainte de a regla oricare dintre ele.

Stabilește un proprietar pentru fiecare funcție

Aici contează patru funcții, iar fiecare are nevoie de exact un proprietar. Tabelul de mai jos indică funcția, un proprietar viabil și ce merge prost când două servicii o revendică.

Suprapunerea apare de obicei un pachet pe rând. Ajutorul pentru hotspot instalează propria instanță dnsmasq, Pi-hole vrea portul 53, iar clientul VPN adaugă rute. Fiecare pas pare rezonabil luat separat, iar împreună produc o mașină în care al doilea serviciu pornit schimbă în tăcere comportamentul primului.

Notează proprietarii înainte de a activa orice altceva. Un tabel scurt în notele instalării împiedică o instalare ulterioară să preia o funcție care avea deja un proprietar.

Alege un singur interval și ține-l departe de tunel

Alege intervalul hotspotului, adresa Pi-ului în el, pool-ul DHCP și resolverul pe care îl primesc clienții. Ține acel interval separat de LAN-ul din amonte și de intervalul tunelului VPN, pentru că subrețelele suprapuse transformă o problemă de rutare într-un proiect de traducere de adrese. Un interval care se suprapune cu tunelul face din Pi un router accidental între două prefixe identice. Scrie intervalul și pool-ul în configurația hotspotului în loc să le lași pe o valoare implicită.

Dacă modul shared al NetworkManager deține hotspotul, inspectează conexiunea efectivă înainte de a adăuga un server DHCP. Modul shared pornește propriile ajutoare și activează forwarding-ul, deci este deja proprietarul planului de adrese pentru acea interfață. Adăugarea unui al doilea server pentru că este disponibil creează oferte concurente în loc de redundanță.

Decide IPv6 în mod deliberat. Anunțurile routerului și DHCPv6 provin, în multe configurații, de la un ajutor diferit de cel pentru DHCPv4, iar lăsarea IPv6 activ în timp ce politica VPN acoperă doar IPv4 le oferă clienților o cale care ocolește tunelul. Fie planifici partea IPv6, fie o dezactivezi pe interfața hotspotului cu un motiv scris.

Cine răspunde de fapt pe portul 53

Listează fiecare proces care ascultă pe portul 53 înainte de a schimba o configurație. Pe un Pi care rulează un stub de resolver local, Pi-hole și un ajutor de partajare, lista ascultătorilor este singura hartă fiabilă a cine răspunde la interogări:

sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip route

Ghidul de interfețe al Pi-hole explică faptul că un mod de recepție limitat la o singură interfață poate folosi totuși un socket wildcard și poate elimina sosirile în altă parte. Aceasta nu este același lucru cu legarea doar la interfețele selectate, care este aranjamentul prevăzut atunci când un alt serviciu DNS trebuie să partajeze mașina.

În mod normal, două procese nu pot lega aceeași adresă și același port, deși SO_REUSEPORT poate face ca un bind partajat să reușească; chiar și atunci, un listener wildcard poate prelua sosirile destinate serviciului mai îngust. Alege modul documentat pentru rolul dorit și repornește serviciile în ordinea prevăzută.

Ține pagina de administrare a Pi-hole în afara rețelei hotspotului. Clienții au nevoie de un resolver, nu de interfața web sau de API-ul care poate schimba configurația resolverului.

Două segmente DNS, câte o politică pentru fiecare

O interogare a unui client călătorește de la telefon la Pi, iar o interogare separată călătorește de la Pi la resolverul său din amonte. O regulă de rutare care corespunde traficului redirecționat al hotspotului nu se aplică automat celui de-al doilea segment, pentru că Pi-ul generează acel trafic local. Dacă VPN-ul ar trebui să transporte DNS, calea locală are nevoie de propria politică.

Ai grijă la bucle. Îndreptarea upstream-ului Pi-hole către o adresă servită chiar de Pi, direct sau printr-un port-forward, produce interogări care se învârt până expiră. Dă-i un upstream real sau un forwarder condiționat pentru domeniile la care nu poate răspunde.

Decide ce se întâmplă când tunelul cade. Revenirea la resolverul local menține navigarea activă, dar poate scurge nume în afara VPN-ului; blocarea menține politica intactă și transformă căderea într-o eroare vizibilă. Ambele alegeri sunt justificabile, dar trebuie alese, nu moștenite dintr-o valoare implicită.

Demonstrează traseul și comportamentul la cădere

Testează pe straturi: clientul primește o adresă, clientul rezolvă un nume prin Pi, Pi-ul rezolvă prin upstream-ul dorit, iar o aplicație finalizează o cerere. Un ping reușit nu spune nimic despre DNS, iar o rezolvare reușită nu spune nimic despre forwarding.

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

Apoi oprește tunelul și repetă. Comportamentul dorit ar trebui să apară în câteva secunde, nu după o repornire manuală a Pi-hole sau a serviciului de hotspot. Verifică setarea resolverului clientului în timpul căderii, pentru că un resolver public secundar va continua să răspundă chiar și când politica aștepta o eroare.

Păstrează un singur proprietar pentru forwarding și NAT și verifică-l dintr-un client, nu de pe Pi. O cerere care iese cu succes din Pi poate fi totuși aruncată la întoarcere, iar clientul este singurul loc unde întregul traseu este vizibil.