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

Telefoner opretter forbindelse til adgangspunktet, får en adresse og når derefter slet ingenting, så snart tunnelen kommer op. hostapd er normalt sund i den tilstand, og det samme er OpenVPN; det, der brækker, er standardruten, som enten aldrig har været på broen eller blev erstattet af tunnelen uden at efterlade en vej til selve VPN-serveren. Denne kørebog sætter ruten tilbage, hvor den hører til, og beviser resultatet fra en klient frem for fra Pi'en. Hvert trin kan rulles tilbage, og intet her ændrer tunnelens konfiguration, før du ved, hvilken trafik du vil have indeni den.

Kortlæg grænsefladerne, før du redigerer noget

Det velkendte layout placerer radioen og den kablede port inde i br0, starter hostapd mod broen og uddeler leases fra dnsmasq, mens en OpenVPN-klient opretter tun0. Derefter ser tre separate krav ud som ét: adgangspunktets klienter har brug for Pi'en som deres gateway, Pi'en har brug for en rute til internettet for at nå sin server, og broen har brug for en gatewayadresse, som disse klienter kan bruge.

Læs den aktuelle tilstand, før du ændrer den, fordi disse fire kommandoer skiller et grænsefladeproblem 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 klienterne Pi'en og intet ud over den. Hvis standardruten peger på tun0, mens tunnelen er nede, har Pi'en slet ingen fungerende vej, og klientens symptom ser præcis ens ud. Begge tilfælde ser identiske ud fra en telefon, og derfor skal rutetabellen læses direkte.

Giv broen en standardrute, der tilhører den

Raspberry Pi OS efterlader ofte broen uden en standardrute, når broen opstod, efter at grænsefladefilen blev skrevet. Blokken hører til i /etc/dhcpcd.conf, og den skal navngive den opstrøms router frem 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 eksempel er 192.168.50.1 den eksisterende router, og 192.168.50.2 er Pi'ens bro-adresse i samme undernet, så indsæt din egen plan i stedet for at kopiere tallene. Broens medlemmer må heller ikke anmode om routere, ellers ender Pi'en med konkurrerende standardruter, hvis vinder afhænger af metrik og timing frem for af hensigt.

Efter systemctl restart dhcpcd skal ip route show default vise br0 én gang og ingen dublet fra den kablede port. Bekræft opslaget frem for tabellen, fordi en forældet post kan sidde ved siden af en vindende: ip -4 route get 203.0.113.10 skal navngive br0. Den adresse kommer fra dokumentationsområdet TEST-NET-3, så den kan ikke kollidere med en rigtig server, mens du læser dette.

Stop tunnelen med at kapre vejen til sin egen server

En OpenVPN-klient, der accepterer redirect-gateway, overtager standardruten og peger den ind i tunnelen. Det er rigtigt, når hver adgangspunktklient skal bruge VPN'en, og forkert, når kun nogle destinationer skal. Under alle omstændigheder må Pi'ens egen forbindelse til serveren ikke rejse inde i den tunnel, den stadig bygger. OpenVPN tilføjer en værtsrute til det fjerne gennem den oprindelige gateway, når den omdirigerer standardruten, og det er netop den adfærd, der holder transporten i live; hvis ruten mangler, kollapser tunnelen, så snart den etableres.

En hurtig sammenligning af den transportvej før og efter tilslutning er de ti sekunder værd. ip -4 route get 203.0.113.10 skal navngive underlagsenheden i begge tilstande, hvor kun metrikken ændrer sig. Hvis den navngiver tun0, efter tunnelen kommer op, blev værtsruten aldrig installeret, og den næste gentilslutning vil fejle.

Når kun udvalgte præfikser skal krydse tunnelen, brug route-nopull og tilføj de ruter, du vil have, manuelt, eller skub et smallere sæt fra serveren. Broen beholder standardruten i det design, og DNS bliver den næste beslutning: videresendelse fra dnsmasq til en hjemme-resolver giver kun mening for de navne, der faktisk bor der.

Beslut historien om videresendelse og NAT

Fuld tunnel kræver videresendelse aktiveret på Pi'en og en gateway på den anden side, der vil rute adgangspunktets undernet. Kontroller videresendelse før alt andet, fordi et nul gør enhver ruteæ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-reglen er genvejen, der virker, når serveren ikke vil acceptere adgangspunktets præfiks, til prisen af at hver klient optræder som Pi'ens tunneladresse i logfilerne på den anden side. Rutning af præfikset uden NAT holder adresserne synlige og afhænger af en returrute for 192.168.50.0/24 på hjemmesiden.

Skriv valget ned ved siden af firewall-reglerne, fordi en NAT-regel, der er usynlig i designet, bliver uforklarlig seks måneder senere. Hold IPv6 i samme beslutning; en fungerende IPv4-vej ved siden af en brudt IPv6-vej læses stadig som halvt brudt i en browser.

Bekræft fra en klient, og rul derefter rent tilbage

Test i denne rækkefølge fra en telefon eller laptop på adgangspunktet: en lease fra dnsmasq, en ping til bro-adressen, derefter en destination på den anden side af tunnelen. Hvert trin isolerer ét lag i stedet for at producere én enkelt ubrugelig fejl.

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

Bekræft derefter, at Pi'en stadig har sin egen vej ud: ip route get 203.0.113.10 skal navngive underlagsenheden, og ping -c 3 -I br0 203.0.113.10 skal svare, hvis serveren tillader ICMP. Hvis de to første klienttrin består, og det tredje fejler, ligger fejlen i videresendelse eller NAT. Hvis det andet trin fejler, er broen eller DHCP stadig ufuldstændig.

Tilbagerulning er én filredigering og to kommandoer: fjern blokken, genstart dhcpcd, og erstat standardruten eksplicit med ip route replace default via 192.168.50.1 dev br0. Gør det, før vedligeholdelsesvinduet lukker, frem for efter, fordi en Pi, der har mistet sin standardrute, er utilgængelig fra det netværk, du ville bruge til at reparere den.