hostapd i OpenVPN na jednym Pi: czyja jest trasa domyślna?

hostapd i klient OpenVPN mogą dzielić jeden Pi, gdy most zachowuje własną trasę domyślną, a tunel zachowuje ścieżkę do swojego serwera. Polecenia i wycofanie.

Telefony łączą się z punktem dostępowym, otrzymują adres, a potem nie docierają donikąd, gdy tylko tunel wstanie. hostapd jest w tym stanie zwykle zdrowy, podobnie OpenVPN; psuje się trasa domyślna, która albo nigdy nie istniała na moście, albo została zastąpiona przez tunel bez pozostawienia ścieżki do samego serwera VPN. Ten poradnik przywraca tę trasę na miejsce i dowodzi wyniku z klienta, a nie z Pi. Każdy krok jest odwracalny, a nic tutaj nie zmienia konfiguracji tunelu, dopóki nie wiesz, jaki ruch chcesz w nim mieć.

Zinwentaryzuj interfejsy, zanim cokolwiek zmienisz

Znany układ umieszcza radio bezprzewodowe i port przewodowy wewnątrz br0, uruchamia hostapd przeciw mostowi i rozdaje dzierżawy z dnsmasq, podczas gdy klient OpenVPN tworzy tun0. Wtedy trzy osobne wymagania wyglądają jak jedno: klienci punktu dostępowego potrzebują Pi jako bramy, Pi potrzebuje trasy do internetu, aby dotrzeć do swojego serwera, a most potrzebuje adresu bramy, którego ci klienci mogą użyć.

Przeczytaj bieżący stan, zanim go zmienisz, ponieważ te cztery polecenia oddzielają problem interfejsu od problemu routingu.

ip -br addr
ip route show
ip link show master br0
bridge link show

Jeśli br0 ma adres, ale nie ma trasy domyślnej, klienci docierają do Pi i niczego poza nim. Jeśli trasa domyślna wskazuje na tun0, gdy tunel jest wyłączony, Pi nie ma żadnej działającej ścieżki, a objaw klienta wygląda dokładnie tak samo. Oba przypadki wyglądają z telefonu identycznie, dlatego tabelę tras trzeba czytać bezpośrednio.

Daj mostowi trasę domyślną, która należy do niego

Raspberry Pi OS często zostawia most bez trasy domyślnej, gdy most powstał po zapisaniu pliku interfejsu. Blok należy do /etc/dhcpcd.conf i powinien wskazywać router nadrzędny, a nie Pi.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

W tym przykładzie 192.168.50.1 to istniejący router, a 192.168.50.2 to adres mostu Pi w tej samej podsieci, więc podstaw własny plan zamiast kopiować liczby. Członkowie mostu również nie mogą żądać routerów, inaczej Pi zostaje ze konkurencyjnymi trasami domyślnymi, których zwycięzca zależy od metryki i czasu, a nie od zamiaru.

Po systemctl restart dhcpcd ip route show default powinien pokazać br0 raz i bez duplikatu z portu przewodowego. Potwierdź wyszukiwanie, a nie tabelę, ponieważ nieaktualny wpis może siedzieć obok zwycięskiego: ip -4 route get 203.0.113.10 musi wskazywać br0. Ten adres pochodzi z zakresu dokumentacyjnego TEST-NET-3, więc nie może kolidować z prawdziwym serwerem, gdy to czytasz.

Powstrzymaj tunel przed porwaniem ścieżki do własnego serwera

Klient OpenVPN, który akceptuje redirect-gateway, przejmuje trasę domyślną i kieruje ją do tunelu. To jest słuszne, gdy każdy klient punktu dostępowego powinien używać VPN, i błędne, gdy tylko niektóre cele powinny. Tak czy inaczej, własne połączenie Pi z serwerem nie może podróżować wewnątrz tunelu, który dopiero buduje. OpenVPN dodaje trasę do hosta przez pierwotną bramę, gdy przekierowuje trasę domyślną, i to jest dokładnie to zachowanie, które utrzymuje transport przy życiu; jeśli tej trasy brakuje, tunel zawala się, gdy tylko się ustali.

Szybkie porównanie tej ścieżki transportowej przed połączeniem i po nim jest warte tych dziesięciu sekund. ip -4 route get 203.0.113.10 powinien wskazywać urządzenie podkładowe w obu stanach, zmienia się tylko metryka. Jeśli po wstaniu tunelu wskazuje tun0, trasa do hosta nigdy nie została zainstalowana i następne ponowne połączenie się nie powiedzie.

Gdy przez tunel mają przechodzić tylko wybrane prefiksy, użyj route-nopull i dodaj żądane trasy ręcznie albo wyślij węższy zestaw z serwera. Most zachowuje wtedy trasę domyślną, a DNS staje się następną decyzją: przekazywanie dnsmasq do domowego resolvera ma sens tylko dla nazw, które naprawdę tam mieszkają.

Zdecyduj o przekazywaniu i NAT

Pełny tunel wymaga włączonego przekazywania na Pi i bramy po drugiej stronie gotowej routować podsieć punktu dostępowego. Sprawdź przekazywanie przed wszystkim innym, ponieważ zero czyni każdą zmianę trasy nieistotną.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Reguła NAT jest skrótem, który działa, gdy serwer nie zaakceptuje prefiksu punktu dostępowego, za cenę tego, że każdy klient pojawia się w logach drugiej strony jako adres tunelu Pi. Routowanie prefiksu bez NAT utrzymuje adresy widoczne i zależy od trasy powrotnej dla 192.168.50.0/24 po stronie domu.

Zapisz wybór obok reguł zapory, ponieważ reguła NAT niewidoczna w projekcie staje się niewyjaśnialna po sześciu miesiącach. Utrzymaj IPv6 w tej samej decyzji; działająca ścieżka IPv4 obok zepsutej ścieżki IPv6 nadal czyta się jako w połowie zepsuta w przeglądarce.

Zweryfikuj z klienta, a potem czysto wycofaj

Testuj w tej kolejności z telefonu lub laptopa w punkcie dostępowym: dzierżawa z dnsmasq, ping do adresu mostu, potem cel po drugiej stronie tunelu. Każdy krok izoluje jedną warstwę zamiast dawać jedną bezużyteczną awarię.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

Potem potwierdź, że Pi nadal ma własne wyjście: ip route get 203.0.113.10 powinien wskazywać urządzenie podkładowe, a ping -c 3 -I br0 203.0.113.10 powinien odpowiedzieć, jeśli serwer pozwala na ICMP. Jeśli pierwsze dwa kroki klienta przejdą, a trzeci zawiedzie, błąd leży w przekazywaniu lub NAT. Jeśli drugi krok zawiedzie, most lub DHCP są nadal niekompletne.

Wycofanie to jedna edycja pliku i dwa polecenia: usuń blok, zrestartuj dhcpcd i zamień trasę domyślną jawnie na ip route replace default via 192.168.50.1 dev br0. Zrób to przed zamknięciem okna serwisowego, a nie po nim, ponieważ Pi, który stracił trasę domyślną, jest nieosiągalny z sieci, której użyłbyś do jego naprawy.

Powiązane artykuły