hostapd en OpenVPN op één Pi: van wie is de standaardroute?

Telefoons koppelen aan het toegangspunt, krijgen een adres en bereiken daarna helemaal niets zodra de tunnel omhoog komt. hostapd is in die toestand meestal gezond, en OpenVPN ook; wat breekt is de standaardroute, die of nooit op de bridge heeft bestaan of door de tunnel is vervangen zonder een pad naar de VPN-server zelf achter te laten. Deze runbook zet die route terug waar hij hoort en bewijst het resultaat vanaf een client in plaats van vanaf de Pi. Elke stap is omkeerbaar, en niets hier verandert de configuratie van de tunnel tot je weet welk verkeer je erin wilt.

Inventariseer de interfaces voordat je iets bewerkt

De bekende opstelling plaatst de radio en de bekabelde poort in br0, start hostapd tegen de bridge en deelt leases uit van dnsmasq, terwijl een OpenVPN-client tun0 aanmaakt. Dan lijken drie afzonderlijke eisen op één: clients van het toegangspunt hebben de Pi nodig als hun gateway, de Pi heeft een route naar internet nodig om zijn server te bereiken, en de bridge heeft een gatewayadres nodig dat die clients kunnen gebruiken.

Lees de huidige toestand voordat je die wijzigt, want deze vier commando's scheiden een interfaceprobleem van een routingprobleem.

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

Als br0 een adres draagt maar geen standaardroute heeft, bereiken clients de Pi en niets daarbuiten. Als de standaardroute naar tun0 wijst terwijl de tunnel omlaag is, heeft de Pi helemaal geen werkend pad, en het clientsymptoom ziet er precies hetzelfde uit. Beide gevallen zien er vanaf een telefoon identiek uit, daarom moet de routetabel rechtstreeks worden gelezen.

Geef de bridge een standaardroute die bij haar hoort

Raspberry Pi OS laat de bridge vaak zonder standaardroute wanneer de bridge is ontstaan nadat het interfacebestand is geschreven. Het blok hoort in /etc/dhcpcd.conf, en het moet de upstream-router noemen in plaats van de 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

In dat voorbeeld is 192.168.50.1 de bestaande router en 192.168.50.2 is het bridgeadres van de Pi in hetzelfde subnet, dus vervang dat door je eigen plan in plaats van de nummers te kopiëren. De bridgeleden mogen ook geen routers aanvragen, anders houdt de Pi concurrerende standaardroutes over waarvan de winnaar van metriek en timing afhangt en niet van bedoeling.

Na systemctl restart dhcpcd moet ip route show default br0 één keer tonen en geen duplicaat vanaf de bekabelde poort. Bevestig de opzoeking in plaats van de tabel, want een verouderde vermelding kan naast een winnende zitten: ip -4 route get 203.0.113.10 moet br0 noemen. Dat adres komt uit het documentatiebereik TEST-NET-3, dus het kan niet botsen met een echte server terwijl je dit leest.

Voorkom dat de tunnel het pad naar zijn eigen server kaapt

Een OpenVPN-client die redirect-gateway accepteert, neemt de standaardroute over en stuurt die de tunnel in. Dat is juist wanneer elke client van het toegangspunt de VPN moet gebruiken, en onjuist wanneer alleen sommige bestemmingen dat moeten. Hoe dan ook mag de eigen verbinding van de Pi met de server niet binnen de tunnel reizen die hij nog bouwt. OpenVPN voegt een hostroute naar de tegenkant toe via de oorspronkelijke gateway wanneer het de standaardroute omleidt, en dat is precies het gedrag dat het transport in leven houdt; als die route ontbreekt, stort de tunnel in zodra hij zich vestigt.

Een snelle vergelijking van dat transportpad voor en na het verbinden is die tien seconden waard. ip -4 route get 203.0.113.10 moet in beide toestanden het onderliggende apparaat noemen, waarbij alleen de metriek verschuift. Als het na het omhoog komen van de tunnel tun0 noemt, is de hostroute nooit geïnstalleerd en zal de volgende herverbinding mislukken.

Wanneer alleen geselecteerde prefixen de tunnel moeten passeren, gebruik route-nopull en voeg de gewenste routes handmatig toe, of stuur een smaller set vanaf de server. De bridge houdt in dat ontwerp de standaardroute, en DNS wordt de volgende beslissing: doorsturen van dnsmasq naar een thuisresolver heeft alleen zin voor de namen die daar echt leven.

Bepaal het verhaal van doorsturen en NAT

Een volledige tunnel vereist doorsturen dat op de Pi is ingeschakeld en een gateway aan de andere kant die bereid is het subnet van het toegangspunt te routeren. Controleer doorsturen voor al het andere, want een nul maakt elke routewijziging irrelevant.

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

De NAT-regel is de snelkoppeling die werkt wanneer de server het prefix van het toegangspunt niet accepteert, tegen de prijs dat elke client in de logboeken aan de andere kant als het tunneladres van de Pi verschijnt. Het prefix zonder NAT routeren houdt adressen zichtbaar en hangt af van een terugroute voor 192.168.50.0/24 aan de thuiszijde.

Schrijf de keuze naast de firewallregels, want een NAT-regel die onzichtbaar is in het ontwerp wordt zes maanden later onverklaarbaar. Houd IPv6 in dezelfde beslissing; een werkend IPv4-pad naast een kapot IPv6-pad leest in een browser nog steeds als half kapot.

Verifieer vanaf een client en draai dan netjes terug

Test in deze volgorde vanaf een telefoon of laptop op het toegangspunt: een lease van dnsmasq, een ping naar het bridgeadres, dan een bestemming aan de andere kant van de tunnel. Elke stap isoleert één laag in plaats van één enkele nutteloze fout te produceren.

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

Bevestig daarna dat de Pi nog zijn eigen uitgang heeft: ip route get 203.0.113.10 moet het onderliggende apparaat noemen, en ping -c 3 -I br0 203.0.113.10 moet antwoorden als de server ICMP toestaat. Als de eerste twee clientstappen slagen en de derde faalt, zit de fout in doorsturen of NAT. Als de tweede stap faalt, zijn de bridge of DHCP nog onvolledig.

Terugdraaien is één bestandswijziging en twee commando's: verwijder het blok, herstart dhcpcd en vervang de standaardroute expliciet door ip route replace default via 192.168.50.1 dev br0. Doe dat voordat het onderhoudsvenster sluit en niet erna, want een Pi die zijn standaardroute kwijt is, is onbereikbaar vanaf het netwerk dat je zou gebruiken om hem te repareren.