hostapd og OpenVPN på én Pi: hvem eier standardruten?

Telefoner kobler til aksesspunktet, får en adresse og når deretter ingenting i det hele tatt så snart tunnelen kommer opp. hostapd er vanligvis sunn i den tilstanden, og det samme er OpenVPN; det som bryter, er standardruten, som enten aldri fantes på broen eller ble erstattet av tunnelen uten å etterlate en vei til selve VPN-serveren. Denne kjøreboken setter ruten tilbake der den hører hjemme og beviser resultatet fra en klient i stedet for fra Pi-en. Hvert trinn kan rulles tilbake, og ingenting her endrer tunnelens konfigurasjon før du vet hvilken trafikk du vil ha inni den.

Kartlegg grensesnittene før du redigerer noe

Det kjente oppsettet plasserer radioen og den kablede porten inne i br0, starter hostapd mot broen og deler ut leier fra dnsmasq, mens en OpenVPN-klient oppretter tun0. Deretter ser tre separate krav ut som ett: aksesspunktklienter trenger Pi-en som gateway, Pi-en trenger en rute til internett for å nå serveren sin, og broen trenger en gatewayadresse som disse klientene kan bruke.

Les gjeldende tilstand før du endrer den, fordi disse fire kommandoene skiller et grensesnittproblem fra et ruteproblem.

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

Hvis br0 har en adresse, men ingen standardrute, når klientene Pi-en og ingenting utover den. Hvis standardruten peker på tun0 mens tunnelen er nede, har Pi-en ingen fungerende vei i det hele tatt, og klientens symptom ser nøyaktig likt ut. Begge tilfellene ser identiske ut fra en telefon, og derfor må rutetabellen leses direkte.

Gi broen en standardrute som tilhører den

Raspberry Pi OS lar ofte broen stå uten standardrute når broen oppsto etter at grensesnittfilen ble skrevet. Blokken hører hjemme i /etc/dhcpcd.conf, og den bør navngi ruteren oppstrøms i stedet for Pi-en.

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 eksemplet er 192.168.50.1 den eksisterende ruteren, og 192.168.50.2 er Pi-ens bro-adresse i samme subnett, så bytt ut med din egen plan i stedet for å kopiere tallene. Broens medlemmer må heller ikke be om rutere, ellers ender Pi-en med konkurrerende standardruter der vinneren avhenger av metrikk og timing i stedet for av hensikt.

Etter systemctl restart dhcpcd skal ip route show default vise br0 én gang og ingen duplikat fra den kablede porten. Bekreft oppslaget i stedet for tabellen, fordi en utdatert oppføring kan sitte ved siden av en vinnende: ip -4 route get 203.0.113.10 må navngi br0. Den adressen kommer fra dokumentasjonsområdet TEST-NET-3, så den kan ikke kollidere med en ekte server mens du leser dette.

Stopp tunnelen fra å kapre veien til sin egen server

En OpenVPN-klient som godtar redirect-gateway, tar over standardruten og peker den inn i tunnelen. Det er riktig når hver aksesspunktklient skal bruke VPN-en, og galt når bare noen destinasjoner skal. Uansett må Pi-ens egen forbindelse til serveren ikke reise inne i tunnelen den fortsatt bygger. OpenVPN legger til en vertsrute til det fjerne gjennom den opprinnelige gatewayen når den omdirigerer standardruten, og det er nettopp den oppførselen som holder transporten i live; hvis ruten mangler, kollapser tunnelen så snart den etableres.

En rask sammenligning av den transportveien før og etter tilkobling er de ti sekundene verdt. ip -4 route get 203.0.113.10 skal navngi underlagsenheten i begge tilstander, bare metrikken endrer seg. Hvis den navngir tun0 etter at tunnelen kommer opp, ble vertsruten aldri installert, og neste gjenoppkobling vil feile.

Når bare utvalgte prefikser skal krysse tunnelen, bruk route-nopull og legg til rutene du vil ha manuelt, eller send et smalere sett fra serveren. Broen beholder standardruten i det designet, og DNS blir den neste beslutningen: videresending fra dnsmasq til en hjemmeresolver gir bare mening for navnene som faktisk bor der.

Bestem historien om videresending og NAT

Full tunnel krever videresending aktivert på Pi-en og en gateway på den andre siden som er villig til å rute aksesspunktets subnett. Sjekk videresending før alt annet, fordi en null gjør enhver ruteendring 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-regelen er snarveien som fungerer når serveren ikke vil godta aksesspunktets prefiks, mot at hver klient fremstår som Pi-ens tunneladresse i loggene på den andre siden. Å rute prefikset uten NAT holder adressene synlige og avhenger av en returrute for 192.168.50.0/24 på hjemmesiden.

Skriv ned valget ved siden av brannmurreglene, fordi en NAT-regel som er usynlig i designet blir uforklarlig seks måneder senere. Hold IPv6 i samme beslutning; en fungerende IPv4-vei ved siden av en ødelagt IPv6-vei leses fortsatt som halvveis ødelagt i en nettleser.

Verifiser fra en klient, og rull deretter rent tilbake

Test i denne rekkefølgen fra en telefon eller bærbar PC på aksesspunktet: en leie fra dnsmasq, en ping til bro-adressen, deretter en destinasjon på den andre siden av tunnelen. Hvert trinn isolerer ett lag i stedet for å produsere én enkelt ubrukelig feil.

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

Bekreft deretter at Pi-en fortsatt har sin egen vei ut: ip route get 203.0.113.10 skal navngi underlagsenheten, og ping -c 3 -I br0 203.0.113.10 skal svare hvis serveren tillater ICMP. Hvis de to første klienttrinnene består og det tredje feiler, ligger feilen i videresending eller NAT. Hvis det andre trinnet feiler, er broen eller DHCP fortsatt ufullstendig.

Tilbakerulling er én filredigering og to kommandoer: fjern blokken, start dhcpcd på nytt, og erstatt standardruten eksplisitt med ip route replace default via 192.168.50.1 dev br0. Gjør det før vedlikeholdsvinduet stenger i stedet for etterpå, fordi en Pi som har mistet standardruten sin er utilgjengelig fra nettverket du ville brukt til å reparere den.