Klienci hotspotu na Pi nie docierają do domowej sieci LAN przez VPN TUN

Lokalni klienci Wi-Fi i Ethernet łączą się z hotspotem Pi, pobierają adres z jego zakresu DHCP i ładują strony internetowe bez skarg. Ci sami klienci kończą potem na limicie czasu, gdy otwierają udział plików lub interfejs webowy w domowej sieci LAN, podczas gdy sam Pi dociera do tej sieci przez tunel. W warstwie bezprzewodowej nic nie jest zepsute. Brakuje kontraktu routowanego: prefiks hotspotu musi być przeniesiony do interfejsu TUN, a coś po stronie domu musi wiedzieć, jak odsyłać tam odpowiedzi. Obie połowy muszą istnieć, zanim jeden pakiet zdoła ukończyć podróż tam i z powrotem.

Trzy połączenia z trzema różnymi zadaniami

Most Ethernet Linux przekazuje ramki według docelowego adresu MAC. OpenVPN w trybie TUN przenosi pakiety IP i w ogóle nie ma warstwy MAC, więc dodanie lokalnego mostu nigdy nie rejestruje tunelu jako portu. dokumentacja jądra dotycząca TUN/TAP wyjaśnia ten podział: urządzenie TAP wygląda jak interfejs Ethernet, urządzenie TUN nie. Projekt, który łączy dwa lokalne porty, a potem routuje, jest routerem, cokolwiek mówią nazwy interfejsów.

Ta różnica rozstrzyga własność. Podsieć klientów, ich brama domyślna i uprawnienia DHCP dla tego zakresu należą do lokalnego planu Pi. Domowe rozgłoszenia DHCP nie przechodzą przez routowany tunel i żadne ustawienie mostu tego nie zmienia; kierowanie klientów do domowego serwera DHCP to osobny, celowy projekt przekaźnika z własnymi trybami awarii.

Trzymaj modem poza mostem klientów. Połączenie PPP nie jest urządzeniem Ethernet z inną etykietą, a udokumentowana logika trasy domyślnej pppd działa po negocjacji IPCP i wycofuje swoją trasę, gdy to łącze padnie. Kopiowanie szablonu DHCP i zmiana nazwy każdego usb0 na ppp0 niczego nie dowodzi w kwestii bramy, metryki ani cyklu życia.

Wybierz prefiksy, zanim edytujesz jakąkolwiek konfigurację

Nakładające się prefiksy marnują więcej wieczorów niż reguły firewalla, bo nakładanie kieruje wyszukiwanie trasy do niewłaściwego interfejsu nawet wtedy, gdy tunel jest zdrowy. Zacznij od spisania tego, co już istnieje na Pi, a potem czytaj wynik jako cztery osobne baseny.

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

Pierwszy basen to adres underlay, który operator dał modemowi; musi pozostać poza każdym planem zwróconym do klientów. Drugi to podsieć tunelu wybrana przez serwer, często jego własna prywatna /24-sieć. Trzeci to most hotspotu, a czwarty to prefiks domowy, do którego chcesz dotrzeć. W tym przejściu hotspot dostaje 172.28.90.0/24 z mostem na 172.28.90.1, a domowa sieć usług zachowuje 192.168.77.0/24, co omija domyślne 192.168.1.0/24 i 10.0.0.0/24 dostarczane przez routery konsumenckie oraz zakres operatora 100.64.0.0/10.

W zakresie DHCP hotspotu ogłaszaj jako bramę tylko adres mostu i nic więcej. Nigdy nie dawaj klientom hotspotu domowego adresu jako bramy; nie mają ścieżki na poziomie łącza do tego segmentu.

Routuj każdy kierunek po stronie, która go posiada

Pi potrzebuje trasy do prefiksu domowego przez tunel. Serwery w trybie serwera zwykle wypychają tę trasę, więc najpierw potwierdź, że przekazywanie jest włączone i że jądro rozwiązuje adres domowy z tun0.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

Jeśli ip route get nadal zgłasza interfejs underlay, zatrzymaj się tam; nic dalej na ścieżce nie naprawi błędnego wyszukiwania.

Urządzenia domowe nie mają trasy do 172.28.90.0/24, więc ich odpowiedzi podążają za bramą domyślną i giną na routerze. Istnieją dwie obsługiwane naprawy. Albo dodaj statyczną trasę na domowym routerze, która kieruje prefiks hotspotu na adres LAN serwera VPN, albo, gdy serwer sam jest bramą, zarejestruj prefiks klienta we własnej tabeli routingu serwera. W trybie wielu klientów OpenVPN katalog specyficzny dla klienta niesie to powiązanie: plik nazwany od nazwy wspólnej certyfikatu klienta, zawierający iroute 172.28.90.0 255.255.255.0 oraz pasującą linię route, która instaluje go w jądrze serwera. Zgadywana trasa jądra na serwerze to nie to samo stwierdzenie, co powiedzenie serwerowi, który klient posiada prefiks.

Nie przenoś usługi DHCP sieci domowej na serwer VPN, aby to działało. Zastąpienie bramy domyślnej całego domu to znacznie większa zmiana niż dodanie jednej prywatnej trasy powrotnej, a wciąga DNS, rezerwacje adresów i każde urządzenie ignorujące nowy leasing w awarię.

Otwórz przekazywanie, nie zgadując firewalla

Włączone przekazywanie nie oznacza, że pakiet może przejść. Ruch z mostu do tunelu nadal trafia na reguły filtrowania, a domyślna polityka przekazywania drop odrzuca ruch hotspotu, podczas gdy własny ruch Pi nadal działa, co daje dokładnie opisany powyżej objaw podziału.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

Szukaj reguły akceptacji od br0 do tun0 i pasującego kierunku odpowiedzi oraz reguły postrouting, która może przepisać źródło. Jeśli polityka łańcucha to drop i żadna reguła nie pasuje, dodaj wąskie akceptacje i przetestuj ponownie, zamiast odwracać politykę na accept.

Tłumaczenie to wybór polityki, nie wymóg. Source NAT w stronę domowej sieci LAN sprawia, że każdy klient hotspotu wygląda jak adres tunelu Pi, co traci przypisanie na klienta w logach domu i psuje usługi oczekujące oryginalnego źródła. Routing bez NAT utrzymuje adresy klientów widoczne, ale zależy od trasy powrotnej powyżej. Wybierz jedno i traktuj DNS oraz IPv6 tak samo, bo działająca ścieżka IPv4 obok zepsutej ścieżki IPv6 nadal czyta się w przeglądarce jako na wpół zepsuta.

Zweryfikuj podróż tam i z powrotem, a potem celowo ją zepsuj

Testuj z klienta hotspotu, nigdy z Pi, bo własny ruch Pi omija zarówno ścieżkę do przodu, jak i powrotną. Obserwuj oba interfejsy, gdy jeden klient próbuje dotrzeć do domowej usługi.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

Czytaj oba przechwycenia razem. Żądania na br0, które nigdy nie pojawiają się na tun0, oznaczają, że Pi nie przekazuje albo trasa wskazuje gdzie indziej. Żądania na tun0 bez odpowiedzi oznaczają, że strona domowa nie ma trasy powrotnej albo serwer odfiltrował pakiet. Odpowiedzi na tun0, które nigdy nie wracają na br0, oznaczają, że brakuje odwrotnej reguły filtrowania, gdzie tunel wygląda perfekcyjnie, a klient nadal nic nie widzi.

Potem celowo zepsuj ścieżkę. Wyłącz połączenie modemu i włącz je ponownie oraz uruchom ponownie kontrole trasy i przechwytywania; trasa, która przetrwa tunel, ale zniknie przy ponownym połączeniu, należy do profilu połączenia, a nie do jednorazowego polecenia. Potwierdź, że transport tunelu nadal wychodzi przez underlay, a nie przez siebie, klasyczna pętla, gdy wypchnięta trasa domyślna jest akceptowana bez trasy do hosta peera.

Zaakceptuj projekt tylko wtedy, gdy klient hotspotu potrafi rozwiązać nazwę domową, otworzyć usługę TCP i utrzymać sesję przy jednym ponownym połączeniu modemu. Jeśli aplikacja naprawdę wymaga wykrywania na poziomie Ethernet w segmencie domowym, wybierz obsługiwany projekt Layer 2, zamiast opisywać lokalny most jako zbrydgowany i czekać na rozgłoszenie.