hostapd ja OpenVPN ühel Pi-l: kellele kuulub vaikimisi marsruut?

hostapd ja OpenVPN klient saavad ühte Pi-d jagada, kui sild hoiab oma vaikimisi marsruuti ja tunnel hoiab tee oma serverini. Käsud ja tagasipööramine.

Telefonid ühenduvad juurdepääsupunktiga, saavad aadressi ja ei jõua seejärel enam kuhugi, kui tunnel tõuseb. hostapd on selles olekus tavaliselt terve, nagu ka OpenVPN; katki läheb vaikimisi marsruut, mis kas ei ole sillal kunagi eksisteerinud või asendati tunneliga, jätmata teed VPN-serveri endani. See juhend paneb marsruudi tagasi sinna, kuhu see kuulub, ja tõestab tulemust kliendist, mitte Pi-st. Iga samm on tagasipööratav ja miski siin ei muuda tunneli seadistust enne, kui teate, millist liiklust selles soovite.

Loetlege liidesed enne, kui midagi muudate

Tavaline paigutus paneb juhtmevaba raadio ja kaabli pordi br0 sisse, käivitab hostapd-i silla vastu ja jagab dnsmasq-ist rendilepinguid, samal ajal kui OpenVPN klient loob tun0. Siis näivad kolm eraldi nõuet ühena: juurdepääsupunkti kliendid vajavad Pi-d oma lüüsina, Pi vajab marsruuti internetti, et oma serverini jõuda, ja sild vajab lüüsi aadressi, mida need kliendid saavad kasutada.

Lugege praegust olekut enne selle muutmist, sest need neli käsku eristavad liidese probleemi marsruutimise probleemist.

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

Kui br0 kannab aadressi, kuid vaikimisi marsruuti pole, jõuavad kliendid Pi-ni ja mitte kaugemale. Kui vaikimisi marsruut osutab tun0-le, kui tunnel on maas, pole Pi-l üldse töötavat teed ja kliendi sümptom näeb täpselt sama välja. Mõlemad juhtumid näevad telefonist identsed välja, mistõttu tuleb marsruutide tabelit otse lugeda.

Andke sillale vaikimisi marsruut, mis kuulub talle

Raspberry Pi OS jätab silla sageli vaikimisi marsruudita, kui sild tekkis pärast liidese faili kirjutamist. Plokk kuulub /etc/dhcpcd.conf-i ja peaks nimetama ülemist ruuterit, mitte Pi-d.

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

Selles näites on 192.168.50.1 olemasolev ruuter ja 192.168.50.2 on Pi silla aadress samas alamvõrgus, seega asendage see oma plaaniga, mitte ärge kopeerige numbreid. Silla liikmed ei tohi samuti ruutereid küsida, muidu jääb Pi-le võistlevad vaikimisi marsruudid, mille võitja sõltub metrikast ja ajastusest, mitte kavatsusest.

Pärast systemctl restart dhcpcd peaks ip route show default loetlema br0 ühe korra ja ilma kaabli pordi duplikaadita. Kinnitage otsing, mitte tabel, sest aegunud kirje võib seista võitva kõrval: ip -4 route get 203.0.113.10 peab nimetama br0. See aadress pärineb dokumentatsiooni vahemikust TEST-NET-3, seega ei saa see selle lugemise ajal päris serveriga kokku põrgata.

Takistage tunnelil oma serveri teed kaaperdada

OpenVPN klient, mis võtab vastu redirect-gateway, võtab vaikimisi marsruudi üle ja suunab selle tunnelisse. See on õige, kui iga juurdepääsupunkti klient peaks VPN-i kasutama, ja vale, kui ainult mõned sihtkohad peaksid. Mõlemal juhul ei tohi Pi enda ühendus serveriga liikuda selle tunneli sees, mida ta alles ehitab. OpenVPN lisab vaikimisi marsruudi ümbersuunamisel hosti marsruudi kaugema poole algse lüüsi kaudu ja see on täpselt see käitumine, mis hoiab transpori elus; kui see marsruut puudub, variseb tunnel kokku niipea, kui see püstitub.

Selle transporitee kiire võrdlus enne ja pärast ühendamist on neid kümmet sekundit väärt. ip -4 route get 203.0.113.10 peaks mõlemas olekus nimetama aluskihi seadet, muutub ainult metrika. Kui see nimetab pärast tunneli tõusmist tun0-i, ei paigaldatud hosti marsruuti kunagi ja järgmine uuesti ühendamine ebaõnnestub.

Kui tunnelit peaksid ületama ainult valitud eesliited, kasutage route-nopull ja lisage soovitud marsruudid käsitsi või saatke serverist kitsam komplekt. Sild hoiab selles lahenduses vaikimisi marsruudi ja DNS muutub järgmiseks otsuseks: dnsmasq-i edastamine kodu-resolverile on mõttekas ainult nende nimede jaoks, mis seal tegelikult elavad.

Otsustage edastamise ja NAT-i lugu

Täistunnel nõuab Pi-l lubatud edastamist ja kaugpoolset lüüsi, mis on valmis juurdepääsupunkti alamvõrku marsruutima. Kontrollige edastamist enne kõike muud, sest null muudab iga marsruudimuudatuse tähtsusetuks.

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-reegel on otsetee, mis töötab siis, kui server ei nõustu juurdepääsupunkti eesliitega, hinnaga, et iga klient ilmub kaugpoolsetes logides Pi tunneli aadressina. Eesliite marsruutimine ilma NAT-ita hoiab aadressid nähtavana ja sõltub kodupoolel tagasimarsruudist 192.168.50.0/24 jaoks.

Kirjutage valik tulemüüri reeglite kõrvale, sest kujunduses nähtamatu NAT-reegel muutub kuus kuud hiljem seletamatuks. Hoidke IPv6 samas otsuses; töötav IPv4 tee katkise IPv6 tee kõrval loetakse brauseris ikka poolkatki.

Kontrollige kliendist ja seejärel pöörake puhtalt tagasi

Testige selles järjekorras telefonist või sülearvutist juurdepääsupunktis: rendileping dnsmasq-ist, ping silla aadressile, seejärel sihtkoht tunneli kaugemal poolel. Iga samm isoleerib ühe kihi, selle asemel et tekitada üks kasutu tõrge.

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

Seejärel kinnitage, et Pi-l on endiselt oma väljapääs: ip route get 203.0.113.10 peaks nimetama aluskihi seadet ja ping -c 3 -I br0 203.0.113.10 peaks vastama, kui server lubab ICMP-d. Kui kaks esimest kliendisammu läbivad ja kolmas ebaõnnestub, on viga edastamises või NAT-is. Kui teine samm ebaõnnestub, on sild või DHCP endiselt puudulik.

Tagasipööramine on üks faili muudatus ja kaks käsku: eemaldage plokk, taaskäivitage dhcpcd ja asendage vaikimisi marsruut selgesõnaliselt käsuga ip route replace default via 192.168.50.1 dev br0. Tehke seda enne hooldusakna sulgemist, mitte pärast, sest vaikimisi marsruudi kaotanud Pi on kättesaamatu võrgust, mida te parandamiseks kasutaksite.

Seotud artiklid