hostapd och OpenVPN på en enda Pi: vems är standardrutten?

Telefoner ansluter till åtkomstpunkten, får en adress och når sedan ingenting alls så snart tunneln kommer upp. hostapd är vanligtvis frisk i det läget, och detsamma gäller OpenVPN; det som går sönder är standardrutten, som antingen aldrig fanns på bron eller ersattes av tunneln utan att lämna en väg till VPN-servern själv. Den här handboken sätter tillbaka rutten där den hör hemma och bevisar resultatet från en klient i stället för från Pi:n. Varje steg går att ångra, och ingenting här ändrar tunnelns konfiguration förrän du vet vilken trafik du vill ha inuti den.

Inventera gränssnitten innan du redigerar något

Den vanliga layouten placerar radion och den trådbundna porten i br0, startar hostapd mot bron och delar ut leasingavtal från dnsmasq, medan en OpenVPN-klient skapar tun0. Då ser tre separata krav ut som ett: åtkomstpunktens klienter behöver Pi:n som sin gateway, Pi:n behöver en rutt till internet för att nå sin server, och bron behöver en gatewayadress som dessa klienter kan använda.

Läs det aktuella läget innan du ändrar det, eftersom dessa fyra kommandon skiljer ett gränssnittsproblem från ett routingproblem.

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

Om br0 har en adress men ingen standardrutt når klienterna Pi:n och ingenting bortom den. Om standardrutten pekar på tun0 medan tunneln är nere har Pi:n ingen fungerande väg alls, och klientens symptom ser exakt likadant ut. Båda fallen ser identiska ut från en telefon, och därför måste routtabellen läsas direkt.

Ge bron en standardrutt som tillhör den

Raspberry Pi OS lämnar ofta bron utan standardrutt när bron uppstod efter att gränssnittsfilen skrevs. Blocket hör hemma i /etc/dhcpcd.conf, och det bör namnge routern uppströms i stället för Pi:n.

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

I det exemplet är 192.168.50.1 den befintliga routern och 192.168.50.2 är Pi:ns bro-adress i samma subnät, så byt ut mot din egen plan i stället för att kopiera siffrorna. Brons medlemmar får inte heller begära routrar, annars hamnar Pi:n med konkurrerande standardrutter vars vinnare beror på metrik och timing i stället för på avsikt.

Efter systemctl restart dhcpcd bör ip route show default visa br0 en gång och ingen dubblett från den trådbundna porten. Bekräfta uppslaget i stället för tabellen, eftersom en gammal post kan sitta bredvid en vinnande: ip -4 route get 203.0.113.10 måste namnge br0. Den adressen kommer från dokumentationsområdet TEST-NET-3, så den kan inte kollidera med en riktig server medan du läser detta.

Stoppa tunneln från att kapa vägen till sin egen server

En OpenVPN-klient som accepterar redirect-gateway tar över standardrutten och pekar den in i tunneln. Det är rätt när varje åtkomstpunktsklient ska använda VPN:en, och fel när bara vissa destinationer ska. Hur som helst får Pi:ns egen anslutning till servern inte färdas inuti tunneln som den fortfarande bygger. OpenVPN lägger till en värdrutt till fjärrsidan via den ursprungliga gatewayen när den omdirigerar standardrutten, och det är precis det beteende som håller transporten vid liv; om den rutten saknas kollapsar tunneln så snart den etableras.

En snabb jämförelse av den transportvägen före och efter anslutning är de tio sekunderna värd. ip -4 route get 203.0.113.10 bör namnge underliggande enhet i båda lägena, bara metrik ändras. Om den namnger tun0 efter att tunneln kommit upp installerades värdrutten aldrig och nästa återanslutning kommer att misslyckas.

När bara utvalda prefix ska korsa tunneln, använd route-nopull och lägg till de rutter du vill ha för hand, eller skicka en snävare uppsättning från servern. Bron behåller standardrutten i den designen, och DNS blir nästa beslut: vidarebefordran från dnsmasq till en hemresolver är bara meningsfull för de namn som faktiskt bor där.

Bestäm historien om vidarebefordran och NAT

Full tunnel kräver vidarebefordran aktiverad på Pi:n och en gateway på andra sidan som är villig att routa åtkomstpunktens subnät. Kontrollera vidarebefordran före allt annat, eftersom en nolla gör varje ruttändring 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

NAT-regeln är genvägen som fungerar när servern inte accepterar åtkomstpunktens prefix, till priset att varje klient syns som Pi:ns tunneladress i loggarna på andra sidan. Att routa prefixet utan NAT håller adresserna synliga och beror på en returrutt för 192.168.50.0/24 på hemsidan.

Skriv ned valet bredvid brandväggsreglerna, eftersom en NAT-regel som är osynlig i designen blir oförklarlig sex månader senare. Behåll IPv6 i samma beslut; en fungerande IPv4-väg bredvid en trasig IPv6-väg läses fortfarande som halvt trasig i en webbläsare.

Verifiera från en klient och rulla sedan tillbaka rent

Testa i den här ordningen från en telefon eller bärbar dator på åtkomstpunkten: ett leasingavtal från dnsmasq, en ping till bro-adressen, sedan en destination på andra sidan tunneln. Varje steg isolerar ett lager i stället för att producera ett enda oanvändbart fel.

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

Bekräfta sedan att Pi:n fortfarande har sin egen väg ut: ip route get 203.0.113.10 bör namnge underliggande enhet, och ping -c 3 -I br0 203.0.113.10 bör svara om servern tillåter ICMP. Om de två första klientstegen går igenom och det tredje misslyckas ligger felet i vidarebefordran eller NAT. Om det andra steget misslyckas är bron eller DHCP fortfarande ofullständig.

Återställning är en filändring och två kommandon: ta bort blocket, starta om dhcpcd och ersätt standardrutten uttryckligen med ip route replace default via 192.168.50.1 dev br0. Gör det innan underhållsfönstret stänger och inte efteråt, eftersom en Pi som förlorat sin standardrutt inte går att nå från nätverket du skulle använda för att reparera den.