Hotspot Pi z Pi-hole i VPN: przydziel każdej usłudze własne zadanie

Telefon dołącza do hotspotu Pi, otrzymuje adres, a strona nadal nie działa. Pi uruchamia pomocnika hotspotu, Pi-hole i klienta VPN, a każdy z nich sądzi, że posiada część ścieżki. Większość takich konfiguracji zawodzi nie dlatego, że komponent jest zepsuty, lecz dlatego, że dwa komponenty wykonują tę samą pracę. Przydziel jednego właściciela na funkcję, zanim dostroisz którykolwiek z nich.

Przydziel jednego właściciela na funkcję

Znaczenie mają tu cztery funkcje i każda potrzebuje dokładnie jednego właściciela. Poniższa tabela podaje funkcję, możliwego właściciela i to, co idzie nie tak, gdy roszczą sobie do niej dwie usługi.

Nakładanie się zwykle przychodzi po jednym pakiecie. Pomocnik hotspotu instaluje własną instancję dnsmasq, Pi-hole chce portu 53, a klient VPN dodaje trasy. Każdy krok z osobna wygląda rozsądnie, a razem dają maszynę, w której druga uruchomiona usługa po cichu zmienia zachowanie pierwszej.

Zapisz właścicieli, zanim włączysz cokolwiek innego. Krótka tabela w notatkach budowy zapobiega temu, by późniejsza instalacja przejęła funkcję, która już miała właściciela.

Wybierz jeden zakres i trzymaj go z dala od tunelu

Wybierz zakres hotspotu, adres Pi w nim, pulę DHCP i resolver, który otrzymują klienci. Trzymaj ten zakres z dala od nadrzędnego LAN-u i od zakresu tunelu VPN, ponieważ nakładające się podsieci zamieniają problem routingu w projekt tłumaczenia adresów. Zakres nakładający się na tunel czyni z Pi przypadkowy router między dwoma identycznymi prefiksami. Zapisz zakres i pulę w konfiguracji hotspotu, zamiast zostawiać je wartości domyślnej.

Jeśli hotspotem zarządza tryb współdzielony NetworkManagera, sprawdź efektywne połączenie przed dodaniem serwera DHCP. Tryb współdzielony uruchamia własne pomocniki i włącza przekazywanie, więc jest już właścicielem planu adresów dla tego interfejsu. Dodanie drugiego serwera, bo jest dostępny, tworzy konkurujące oferty zamiast nadmiarowości.

Zdecyduj o IPv6 świadomie. Rozgłaszanie routerów i DHCPv6 w wielu konfiguracjach pochodzą od innego pomocnika niż DHCPv4, a pozostawienie IPv6 włączonego, gdy polityka VPN obejmuje tylko IPv4, daje klientom ścieżkę omijającą tunel. Albo zaplanuj stronę IPv6, albo wyłącz ją na interfejsie hotspotu z zapisanym uzasadnieniem.

Kto naprawdę odpowiada na porcie 53

Przed zmianą konfiguracji wypisz każdy proces nasłuchujący na porcie 53. Na Pi, który uruchamia lokalny stub resolvera, Pi-hole i pomocnika udostępniania, lista nasłuchujących jest jedyną wiarygodną mapą tego, kto odpowiada na zapytania:

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

Przewodnik po interfejsach Pi-hole wyjaśnia, że tryb odbioru ograniczony do jednego interfejsu nadal może używać gniazda wildcard i odrzucać przychodzące pakiety gdzie indziej. To nie to samo co wiązanie tylko wybranych interfejsów, czyli układ zamierzony wtedy, gdy inna usługa DNS musi współdzielić maszynę.

Dwa procesy zwykle nie mogą powiązać tego samego adresu i portu, choć SO_REUSEPORT może sprawić, że współdzielone powiązanie się powiedzie; nawet wtedy nasłuchujący wildcard może przejąć pakiety przeznaczone dla węższej usługi. Wybierz udokumentowany tryb dla roli, której chcesz, i uruchom usługi ponownie w zamierzonej kolejności.

Trzymaj stronę administracyjną Pi-hole poza siecią hotspotu. Klienci potrzebują resolvera, a nie interfejsu webowego lub API, które może zmienić konfigurację resolvera.

Dwie odnogi DNS, każda z własną polityką

Zapytanie klienta podróżuje z telefonu do Pi, a osobne zapytanie podróżuje z Pi do jego nadrzędnego resolvera. Reguła routingu pasująca do przekazywanego ruchu hotspotu nie stosuje się automatycznie do drugiej odnogi, ponieważ Pi generuje ten ruch lokalnie. Jeśli VPN ma przenosić DNS, lokalna ścieżka potrzebuje własnej polityki.

Uważaj na pętlę. Skierowanie nadrzędnego resolvera Pi-hole na adres obsługiwany przez samo Pi, bezpośrednio lub przez port-forward, tworzy zapytania, które krążą, aż wygasną. Daj mu prawdziwy nadrzędny resolver lub warunkowy forwarder dla domen, na które nie potrafi odpowiedzieć.

Zdecyduj, co się dzieje, gdy tunel padnie. Powrót do lokalnego resolvera utrzymuje przeglądanie przy życiu, ale może wyciekać nazwy poza VPN; blokowanie zachowuje politykę nietkniętą i zamienia awarię w widoczny błąd. Oba wybory są obronne, ale trzeba je wybrać, a nie odziedziczyć z wartości domyślnej.

Udowodnij ścieżkę i zachowanie przy awarii

Testuj warstwami: klient dostaje adres, klient rozwiązuje nazwę przez Pi, Pi rozwiązuje przez zamierzony nadrzędny resolver, a aplikacja kończy żądanie. Udany ping nic nie mówi o DNS, a udane wyszukanie nic nie mówi o przekazywaniu.

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

Następnie zatrzymaj tunel i powtórz. Zamierzone zachowanie powinno pojawić się w ciągu kilku sekund, a nie po ręcznym restarcie Pi-hole lub usługi hotspotu. Sprawdź ustawienie resolvera klienta podczas awarii, ponieważ pomocniczy publiczny resolver będzie nadal odpowiadał, nawet gdy polityka oczekiwała błędu.

Utrzymaj jednego właściciela przekazywania i NAT i zweryfikuj go z klienta, nie z samego Pi. Żądanie, które pomyślnie opuszcza Pi, nadal może zostać odrzucone w drodze powrotnej, a klient jest jedynym miejscem, w którym widać całą ścieżkę.