hostapd ir OpenVPN viename Pi: kam priklauso numatytasis maršrutas?

hostapd ir OpenVPN klientas gali dalytis vienu Pi, kai tiltas išlaiko savo numatytąjį maršrutą, o tunelis išlaiko kelią į savo serverį. Komandos ir atšaukimas.

Telefonai prisijungia prie prieigos taško, gauna adresą ir tada nieko nepasiekia, kai tik tunelis pakyla. hostapd toje būsenoje paprastai sveikas, ir OpenVPN taip pat; lūžta numatytasis maršrutas, kuris arba niekada neegzistavo tilte, arba tunelis jį pakeitė nepalikęs kelio į patį VPN serverį. Šis vadovas grąžina tą maršrutą į jo vietą ir įrodo rezultatą iš kliento, o ne iš Pi. Kiekvienas žingsnis grįžtamas, ir niekas čia nekeičia tunelio konfigūracijos, kol nežinote, kokio srauto norite jo viduje.

Surašykite sąsajas prieš ką nors redaguodami

Įprastas išdėstymas įdeda belaidį radiją ir laidinį prievadą į br0, paleidžia hostapd prieš tiltą ir dalija nuomas iš dnsmasq, o OpenVPN klientas sukuria tun0. Tada trys atskiri reikalavimai atrodo kaip vienas: prieigos taško klientams reikia Pi kaip jų šliuzo, Pi reikia maršruto į internetą, kad pasiektų savo serverį, o tiltui reikia šliuzo adreso, kurį tie klientai galėtų naudoti.

Perskaitykite dabartinę būseną prieš ją keisdami, nes šios keturios komandos atskiria sąsajos problemą nuo maršrutizavimo problemos.

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

Jei br0 turi adresą, bet neturi numatytojo maršruto, klientai pasiekia Pi ir nieko už jo. Jei numatytasis maršrutas rodo į tun0, kol tunelis išjungtas, Pi iš viso neturi veikiančio kelio, o kliento simptomas atrodo lygiai taip pat. Abu atvejai iš telefono atrodo vienodai, todėl maršrutų lentelę reikia skaityti tiesiogiai.

Duokite tiltui numatytąjį maršrutą, kuris jam priklauso

Raspberry Pi OS dažnai palieka tiltą be numatytojo maršruto, kai tiltas atsirado po to, kai buvo parašytas sąsajos failas. Blokas priklauso /etc/dhcpcd.conf, ir jis turėtų nurodyti aukštesnį maršrutizatorių, o ne 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

Tame pavyzdyje 192.168.50.1 yra esamas maršrutizatorius, o 192.168.50.2 yra Pi tilto adresas toje pačioje potinklyje, todėl pakeiskite savo planu, o ne kopijuokite skaičius. Tilto nariai taip pat neturi prašyti maršrutizatorių, kitaip Pi liks konkuruojantys numatytieji maršrutai, kurių nugalėtojas priklauso nuo metrikos ir laiko, o ne nuo ketinimo.

Po systemctl restart dhcpcd ip route show default turėtų vieną kartą parodyti br0 ir be dublikato iš laidinio prievado. Patvirtinkite paiešką, o ne lentelę, nes pasenęs įrašas gali sėdėti šalia laimėjusio: ip -4 route get 203.0.113.10 turi nurodyti br0. Tas adresas yra iš TEST-NET-3 dokumentacijos diapazono, todėl jis negali susidurti su tikru serveriu, kol tai skaitote.

Sustabdykite tunelį, kad jis negrobtų kelio į savo paties serverį

OpenVPN klientas, priimantis redirect-gateway, perima numatytąjį maršrutą ir nukreipia jį į tunelį. Tai teisinga, kai kiekvienas prieigos taško klientas turėtų naudoti VPN, ir neteisinga, kai turėtų tik kai kurie tikslai. Bet kuriuo atveju Pi ryšys su serveriu neturi keliauti tunelio, kurį jis dar stato, viduje. OpenVPN prideda maršrutą į prieglobos tašką per pradinį šliuzą, kai nukreipia numatytąjį maršrutą, ir būtent šis elgesys palaiko transportą gyvą; jei šio maršruto nėra, tunelis sugriūva vos tik susikuria.

Greitas to transporto kelio palyginimas prieš prisijungiant ir po to vertas tų dešimties sekundžių. ip -4 route get 203.0.113.10 turėtų nurodyti apatinio sluoksnio įrenginį abiem būsenomis, keičiasi tik metrika. Jei po tunelio pakilimo jis nurodo tun0, prieglobos maršrutas niekada nebuvo įdiegtas ir kitas prisijungimas nepavyks.

Kai tunelį turi kirsti tik pasirinkti prefiksai, naudokite route-nopull ir įtraukite norimus maršrutus rankiniu būdu, arba iš serverio stumkite siauresnį rinkinį. Tame projekte tiltas išlaiko numatytąjį maršrutą, o DNS tampa kitu sprendimu: dnsmasq persiuntimas į namų sprendėją turi prasmę tik tiems vardams, kurie ten iš tikrųjų gyvena.

Nuspręskite dėl persiuntimo ir NAT

Pilnam tuneliui reikia įjungto persiuntimo Pi ir priešingoje pusėje esančio šliuzo, pasirengusio maršrutizuoti prieigos taško potinklį. Patikrinkite persiuntimą prieš visa kita, nes nulis daro kiekvieną maršruto pakeitimą nereikšmingą.

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 taisyklė yra trumpiausias kelias, kuris veikia, kai serveris nepriims prieigos taško prefikso, už kainą, kad kiekvienas klientas tolimosios pusės žurnaluose atrodys kaip Pi tunelio adresas. Prefikso maršrutizavimas be NAT išlaiko adresus matomus ir priklauso nuo grįžimo maršruto 192.168.50.0/24 namų pusėje.

Užrašykite pasirinkimą šalia ugniasienės taisyklių, nes projekte nematoma NAT taisyklė po šešių mėnesių tampa nepaaiškinama. Laikykite IPv6 tame pačiame sprendime; veikiantis IPv4 kelias šalia sugedusio IPv6 kelio naršyklėje vis dar skaitomas kaip pusiau sugedęs.

Patikrinkite iš kliento, tada švariai atšaukite

Išbandykite šia tvarka iš telefono ar nešiojamojo kompiuterio prieigos taške: nuoma iš dnsmasq, ping į tilto adresą, tada tikslas kitoje tunelio pusėje. Kiekvienas žingsnis izoliuoja vieną sluoksnį, o ne sukuria vieną nenaudingą gedimą.

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

Tada patvirtinkite, kad Pi vis dar turi savo išėjimą: ip route get 203.0.113.10 turėtų nurodyti apatinio sluoksnio įrenginį, o ping -c 3 -I br0 203.0.113.10 turėtų atsakyti, jei serveris leidžia ICMP. Jei pirmieji du kliento žingsniai praeina, o trečiasis nepavyksta, klaida yra persiuntime arba NAT. Jei antrasis žingsnis nepavyksta, tiltas arba DHCP vis dar nepilni.

Atšaukimas yra vienas failo redagavimas ir dvi komandos: pašalinkite bloką, paleiskite dhcpcd iš naujo ir pakeiskite numatytąjį maršrutą aiškiai ip route replace default via 192.168.50.1 dev br0. Darykite tai prieš uždarant priežiūros langą, o ne po to, nes Pi, praradęs numatytąjį maršrutą, nepasiekiamas iš tinklo, kurį naudotumėte jam taisyti.

Susiję straipsniai