hostapd en OpenVPN op ien Pi: wa is eigner fan de standertrûte?

Telefoanen ferbine har mei it tagongspunt, krije in adres en berikke dan hielendal neat mear sadree't de tunnel omheech komt. hostapd is yn dy tastân meastentiids sûn, en OpenVPN ek; wat brekt is de standertrûte, dy't of nea op de brêge bestien hat of troch de tunnel ferfongen waard sûnder in paad nei de VPN-tsjinner sels efter te litten. Dizze hânlieding set dy rûte wer op syn plak en bewissiget it resultaat fan in klant yn stee fan fan de Pi. Eltse stap is werom te draaien, en neat hjir feroaret de konfiguraasje fan 'e tunnel oant jo witte hokker ferkear jo der yn wolle.

Yneliste de ynterfaces foardat jo wat bewurkje

De fertroude yndieling set de draadleaze radio en de bekabelde poart yn br0, start hostapd tsjin de brêge en dielt leases út fan dnsmasq, wylst in OpenVPN-klant tun0 oanmakket. Dan lykje trije aparte easken as ien: klanten fan it tagongspunt hawwe de Pi nedich as harren gateway, de Pi hat in rûte nei it ynternet nedich om syn tsjinner te berikken, en de brêge hat in gateway-adres nedich dat dy klanten brûke kinne.

Lês de hjoeddeistige tastân foardat jo dy feroarje, want dizze fjouwer opdrachten skiede in ynterface-probleem fan in routing-probleem.

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

As br0 in adres hat mar gjin standertrûte, berikke klanten de Pi en neat dêrbûten. As de standertrûte nei tun0 wiist wylst de tunnel del is, hat de Pi hielendal gjin wurkjend paad, en it klantsymptoom liket krekt itselde. Beide gefallen likje identyk fan in telefoan, dêrom moat de rûtetabel direkt lêzen wurde.

Jou de brêge in standertrûte dy't fan har is

Raspberry Pi OS lit de brêge faak sûnder standertrûte as de brêge ûntstie neidat it ynterface-bestân skreaun wie. It blok heart yn /etc/dhcpcd.conf, en it moat de upstream-router neame yn stee fan 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

Yn dat foarbyld is 192.168.50.1 de besteande router en 192.168.50.2 is it brêge-adres fan de Pi yn itselde subnet, ferfang dat dus troch jo eigen plan yn stee fan de nûmers te kopiearjen. De brêge-leden meie ek gjin routers oanfreegje, oars einiget de Pi mei konkurrearjende standertrûtes wêrfan't de winner fan metryk en timing ôfhinget yn stee fan fan bedoeling.

Nei systemctl restart dhcpcd moat ip route show default br0 ien kear listje en gjin duplikaat fan de bekabelde poart. Befêstigje de syktocht yn stee fan de tabel, want in ferâldere ynfier kin njonken in winnende sitte: ip -4 route get 203.0.113.10 moat br0 neame. Dat adres komt út it dokumintaasjeberik TEST-NET-3, dus it kin net mei in echte tsjinner botsje wylst jo dit lêze.

Stop de tunnel om it paad nei syn eigen tsjinner te kapen

In OpenVPN-klant dy't redirect-gateway akseptearret, nimt de standertrûte oer en rjochtet dy de tunnel yn. Dat is goed as elke klant fan it tagongspunt de VPN brûke moat, en ferkeard as allinnich guon bestimmingen dat moatte. Hoe dan ek, de eigen ferbining fan de Pi nei de tsjinner mei net binnen de tunnel reizgje dy't er noch bout. OpenVPN foeget in hostrûte nei de fiere kant ta fia de oarspronklike gateway as it de standert omleit, en dat is krekt it gedrach dat it ferfier libben hâldt; as dy rûte mist, stoart de tunnel yn sadree't er him festiget.

In flugge fergeliking fan dat ferfierspaad foar en nei ferbinen is de tsien sekonden wurdich. ip -4 route get 203.0.113.10 moat de ûnderlizzende apparaat yn beide tastannen neame, allinnich de metryk ferskoot. As it nei it omheech kommen fan 'e tunnel tun0 neamt, is de hostrûte nea ynstallearre en sil de folgjende werferbining mislearje.

Wannear't allinnich selektearre foarheaksels de tunnel oerstekke moatte, brûk route-nopull en foegje de rûtes dy't jo wolle mei de hân ta, of stjoer in smeller set fan de tsjinner út. De brêge hâldt de standertrûte yn dat ûntwerp, en DNS wurdt de folgjende beslissing: trochstjoeren fan dnsmasq nei in thúsresolver hat allinnich sin foar de nammen dy't dêr echt wenje.

Beslis it ferhaal fan trochstjoeren en NAT

Fol tunnel freget om ynskeakele trochstjoeren op de Pi en in gateway oan de oare kant dy't it subnet fan it tagongspunt routsje wol. Kontrolearje trochstjoeren foar al it oare, want in nul makket elke rûteferoaring ûnbelangryk.

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 fluchste wei dy't wurket as de tsjinner it foarheaksel fan it tagongspunt net akseptearret, tsjin de priis dat elke klant as it tunneladres fan de Pi yn 'e logboeken fan 'e fiere kant ferskynt. It foarheaksel sûnder NAT routsje hâldt adressen sichtber en hinget ôf fan in weromrûte foar 192.168.50.0/24 oan 'e thúskant.

Skriuw de kar njonken de firewall-regels, want in NAT-regel dy't ûnsichtber is yn it ûntwerp wurdt seis moanne letter ûnferklearber. Hâld IPv6 yn deselde beslissing; in wurkjend IPv4-paad njonken in brutsen IPv6-paad lêst noch altyd as heal brutsen yn in browser.

Ferifiearje fan in klant en draai dan skjin werom

Test yn dizze folchoarder fan in telefoan of laptop op it tagongspunt: in lease fan dnsmasq, in ping nei it brêge-adres, dan in bestimming oan 'e fiere kant fan 'e tunnel. Eltse stap isolearret ien laach yn stee fan ien ienige nutteleaze mislearring te meitsjen.

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

Befêstigje dan dat de Pi noch syn eigen paad nei bûten hat: ip route get 203.0.113.10 moat de ûnderlizzende apparaat neame, en ping -c 3 -I br0 203.0.113.10 moat antwurdzje as de tsjinner ICMP tasteat. As de earste twa klantstappen slagje en de tredde mislearret, sit de flater yn trochstjoeren of NAT. As de twadde stap mislearret, binne de brêge of DHCP noch net kompleet.

Weromdraaie is ien bestânsbewurking en twa opdrachten: ferwiderje it blok, herstart dhcpcd en ferfang de standertrûte eksplisyt mei ip route replace default via 192.168.50.1 dev br0. Doch dat foardat it ûnderhâldsfenster slút yn stee fan dêrnei, want in Pi dy't syn standertrûte ferlern hat is ûnberikber fan it netwurk dat jo brûke soene om it te reparearjen.