hostapd og OpenVPN på éin Pi: kven eig standardruta?

hostapd og ein OpenVPN-klient kan dela éin Pi når brua held si eiga standardrute og tunnelen held ein veg til serveren sin. Kommandoar og tilbakerulling.

Telefonar koplar til aksesspunktet, får ei adresse og når deretter ingenting i det heile så snart tunnelen kjem opp. hostapd er vanlegvis sunn i den tilstanden, og det same er OpenVPN; det som bryt, er standardruta, som anten aldri fanst på brua eller vart erstatta av tunnelen utan å etterlata ein veg til sjølve VPN-tenaren. Denne køyreboka set ruta tilbake der ho høyrer heime og bevisar resultatet frå ein klient i staden for frå Pi-en. Kvart steg kan rullast tilbake, og ingenting her endrar konfigurasjonen av tunnelen før du veit kva trafikk du vil ha inni han.

Kartlegg grensesnitta før du redigerer noko

Det kjende oppsettet plasserer radioen og den kabelbundne porten inne i br0, startar hostapd mot brua og deler ut leiger frå dnsmasq, medan ein OpenVPN-klient opprettar tun0. Deretter ser tre separate krav ut som eitt: aksesspunktklientar treng Pi-en som gateway, Pi-en treng ei rute til internett for å nå serveren sin, og brua treng ei gatewayadresse som desse klientane kan bruke.

Les gjeldande tilstand før du endrar han, fordi desse fire kommandoane skil eit grensesnittproblem frå eit ruteproblem.

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

Viss br0 har ei adresse, men inga standardrute, når klientane Pi-en og ingenting utover han. Viss standardruta peikar på tun0 medan tunnelen er nede, har Pi-en ingen fungerande veg i det heile, og symptomet hjå klienten ser nøyaktig likt ut. Begge tilfella ser identiske ut frå ein telefon, og difor må rutetabellen lesast direkte.

Gje brua ei standardrute som høyrer til henne

Raspberry Pi OS lèt ofte brua stå utan standardrute når brua oppstod etter at grensesnittfila vart skriven. Blokka høyrer heime i /etc/dhcpcd.conf, og ho bør nemne rutaren oppstraums i staden 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 dømet er 192.168.50.1 den eksisterande rutaren, og 192.168.50.2 er bru-adressa til Pi-en i same subnett, så byt ut med din eigen plan i staden for å kopiere tala. Medlemmene av brua må heller ikkje be om rutarar, elles endar Pi-en med konkurrerande standardruter der vinnaren avheng av metrikk og tidspunkt i staden for av hensikt.

Etter systemctl restart dhcpcd skal ip route show default vise br0 éin gong og ingen duplikat frå den kabelbundne porten. Stadfest oppslaget i staden for tabellen, fordi ein utdatert oppføring kan sitje ved sida av ein vinnande: ip -4 route get 203.0.113.10 må nemne br0. Den adressa kjem frå dokumentasjonsområdet TEST-NET-3, så ho kan ikkje kollidere med ein ekte tenar medan du les dette.

Stopp tunnelen frå å kapre vegen til sin eigen tenar

Ein OpenVPN-klient som godtek redirect-gateway, tek over standardruta og peikar henne inn i tunnelen. Det er rett når kvar aksesspunktklient skal bruke VPN-en, og gale når berre nokre mål skal. Uansett må den eigne sambindinga til Pi-en til tenaren ikkje reise inne i tunnelen han framleis byggjer. OpenVPN legg til ei vertsrute til det fjerne gjennom den opphavlege gatewayen når han omdirigerer standardruta, og det er nettopp den åtferda som held transporten i live; viss ruta manglar, kollapsar tunnelen så snart han etablerer seg.

Ein rask samanlikning av den transportvegen før og etter tilkopling er dei ti sekunda verd. ip -4 route get 203.0.113.10 skal nemne underlagsseininga i begge tilstandar, berre metrikken endrar seg. Viss han nemner tun0 etter at tunnelen kjem opp, vart vertsruta aldri installert, og neste gjenoppkopling vil feile.

Når berre utvalde prefiks skal krysse tunnelen, bruk route-nopull og legg til rutene du vil ha manuelt, eller send eit smalare sett frå tenaren. Brua held standardruta i det designet, og DNS blir den neste avgjerda: vidaresending frå dnsmasq til ein heimeresolver gjev berre meining for namna som faktisk bur der.

Avgjer saka om vidaresending og NAT

Full tunnel krev vidaresending slått på i Pi-en og ein gateway på den andre sida som er villig til å rute subnettet til aksesspunktet. Sjekk vidaresending før alt anna, fordi ein null gjer kvar 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 snarevegen som fungerer når tenaren ikkje vil godta prefikset til aksesspunktet, mot at kvar klient framstår som tunneladressa til Pi-en i loggane på den andre sida. Å rute prefikset utan NAT held adressene synlege og avheng av ei returrute for 192.168.50.0/24 på heimesida.

Skriv ned valet ved sida av brannmurreglane, fordi ein NAT-regel som er usynleg i designet blir uforklarleg seks månader seinare. Hald IPv6 i same avgjerd; ein fungerande IPv4-veg ved sida av ein øydelagd IPv6-veg blir framleis lesen som halvt øydelagd i ein nettlesar.

Stadfest frå ein klient, og rull deretter reint tilbake

Test i denne rekkjefølgja frå ein telefon eller berbar PC på aksesspunktet: ei leige frå dnsmasq, ein ping til bru-adressa, deretter eit mål på den andre sida av tunnelen. Kvart steg isolerer eitt lag i staden for å produsere éin einaste ubrukeleg feil.

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

Stadfest deretter at Pi-en framleis har sin eigen veg ut: ip route get 203.0.113.10 skal nemne underlagsseininga, og ping -c 3 -I br0 203.0.113.10 skal svare viss tenaren tillèt ICMP. Viss dei to første klientstega går gjennom og det tredje feilar, ligg feilen i vidaresending eller NAT. Viss det andre steget feilar, er brua eller DHCP framleis ufullstendig.

Tilbakerulling er éin filredigering og to kommandoar: fjern blokka, start dhcpcd på nytt, og erstatt standardruta eksplisitt med ip route replace default via 192.168.50.1 dev br0. Gjer det før vedlikehaldsvindauget stenger i staden for etterpå, fordi ein Pi som har mista standardruta si er utilgjengeleg frå nettverket du ville brukt til å reparere han.

Relaterte artiklar