hostapd in OpenVPN na enem Pi: čigava je privzeta pot?

hostapd in odjemalec OpenVPN si lahko delita en Pi, ko most obdrži svojo privzeto pot, tunel pa obdrži pot do svojega strežnika. Ukazi in razveljavitev.

Telefoni se povežejo z dostopno točko, prejmejo naslov in nato ne dosežejo ničesar, takoj ko se tunel dvigne. hostapd je v tem stanju običajno zdrav, prav tako OpenVPN; zlomi se privzeta pot, ki na mostu bodisi ni nikoli obstajala bodisi jo je tunel zamenjal, ne da bi pustil pot do samega strežnika VPN. Ta priročnik vrne pot na svoje mesto in dokaže rezultat z odjemalca, ne s Pi. Vsak korak je povraten in nič tukaj ne spremeni konfiguracije tunela, dokler ne veste, kateri promet želite v njem.

Preden karkoli uredite, popišite vmesnike

Znana postavitev postavi brezžični radio in žična vrata v br0, zažene hostapd proti mostu in deli najeme iz dnsmasq, medtem ko odjemalec OpenVPN ustvari tun0. Takrat tri ločene zahteve izgledajo kot ena: odjemalci dostopne točke potrebujejo Pi kot svojo prehodno postajo, Pi potrebuje pot v internet, da doseže svoj strežnik, most pa potrebuje naslov prehoda, ki ga ti odjemalci lahko uporabijo.

Preberite trenutno stanje, preden ga spremenite, ker ti štirje ukazi ločijo težavo vmesnika od težave usmerjanja.

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

Če br0 nosi naslov, a nima privzete poti, odjemalci dosežejo Pi in ničesar za njim. Če privzeta pot kaže na tun0, medtem ko je tunel spuščen, Pi sploh nima delujoče poti, simptom odjemalca pa je videti popolnoma enako. Oba primera sta s telefona videti enako, zato je treba usmerjevalno tabelo brati neposredno.

Dajte mostu privzeto pot, ki mu pripada

Raspberry Pi OS pogosto pusti most brez privzete poti, ko je most nastal po tem, ko je bila zapisana datoteka vmesnika. Blok spada v /etc/dhcpcd.conf in bi moral navesti nadrejeni usmerjevalnik, 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

V tem primeru je 192.168.50.1 obstoječi usmerjevalnik, 192.168.50.2 pa naslov mostu Pi v istem podomrežju, zato vstavite svoj načrt, namesto da kopirate številke. Člani mostu tudi ne smejo zahtevati usmerjevalnikov, sicer Pi ostane s konkurenčnimi privzetimi potmi, katerih zmagovalec je odvisen od metrike in časa, ne od namere.

Po systemctl restart dhcpcd bi moral ip route show default enkrat navesti br0 in brez dvojnika z žičnih vrat. Potrdite iskanje, ne tabele, ker je zastarel vnos lahko poleg zmagovalnega: ip -4 route get 203.0.113.10 mora navesti br0. Ta naslov prihaja iz dokumentacijskega obsega TEST-NET-3, zato ne more trčiti v pravi strežnik, medtem ko to berete.

Preprečite, da bi tunel ugrabil pot do svojega strežnika

Odjemalec OpenVPN, ki sprejme redirect-gateway, prevzame privzeto pot in jo usmeri v tunel. To je pravilno, kadar mora VPN uporabljati vsak odjemalec dostopne točke, in napačno, kadar le nekatere cilje. Kakor koli, lastna povezava Pi s strežnikom ne sme potovati znotraj tunela, ki ga še gradi. OpenVPN doda pot do gostitelja na oddaljeno stran prek prvotne prehodne postaje, ko preusmeri privzeto pot, in prav to vedenje ohranja transport živ; če te poti ni, se tunel poruši, takoj ko se vzpostavi.

Hitra primerjava te transportne poti pred povezavo in po njej je vredna tistih desetih sekund. ip -4 route get 203.0.113.10 bi moral v obeh stanjih navesti napravo spodnjega sloja, spreminja se le metrika. Če po dvigu tunela navaja tun0, pot do gostitelja ni bila nikoli nameščena in naslednja ponovna povezava bo spodletela.

Ko naj bi tunel prečkale le izbrane predpone, uporabite route-nopull in ročno dodajte želene poti ali s strežnika pošljite ožji nabor. Most v tej zasnovi obdrži privzeto pot, DNS pa postane naslednja odločitev: posredovanje dnsmasq v domači razreševalnik ima smisel le za imena, ki tam resnično živijo.

Odločite se o posredovanju in NAT

Polni tunel potrebuje omogočeno posredovanje na Pi in prehodno postajo na drugi strani, pripravljeno usmerjati podomrežje dostopne točke. Posredovanje preverite pred vsem drugim, ker ničla naredi vsako spremembo poti nepomembno.

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

Pravilo NAT je bližnjica, ki deluje, ko strežnik ne bo sprejel predpone dostopne točke, za ceno, da se vsak odjemalec v dnevnikih oddaljene strani pojavi kot naslov tunela Pi. Usmerjanje predpone brez NAT ohranja naslove vidne in je odvisno od povratne poti za 192.168.50.0/24 na domači strani.

Izbiro zapišite poleg pravil požarnega zidu, ker pravilo NAT, nevidno v zasnovi, šest mesecev pozneje postane nerazložljivo. Ohranite IPv6 v isti odločitvi; delujoča pot IPv4 poleg pokvarjene poti IPv6 se v brskalniku še vedno bere kot napol pokvarjena.

Preverite z odjemalca, nato se čisto vrnite

Preizkusite v tem vrstnem redu s telefona ali prenosnika na dostopni točki: najem iz dnsmasq, ping na naslov mostu, nato cilj na oddaljeni strani tunela. Vsak korak izolira en sloj, namesto da bi ustvaril eno samo neuporabno napako.

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

Nato potrdite, da ima Pi še vedno svoj izhod: ip route get 203.0.113.10 bi moral navesti napravo spodnjega sloja, ping -c 3 -I br0 203.0.113.10 pa bi moral odgovoriti, če strežnik dovoljuje ICMP. Če prva dva koraka odjemalca uspeta in tretji spodleti, je napaka v posredovanju ali NAT. Če drugi korak spodleti, most ali DHCP še nista popolna.

Razveljavitev je eno urejanje datoteke in dva ukaza: odstranite blok, znova zaženite dhcpcd in zamenjajte privzeto pot izrecno z ip route replace default via 192.168.50.1 dev br0. To storite pred zaprtjem vzdrževalnega okna in ne po njem, ker Pi, ki je izgubil privzeto pot, ni dosegljiv iz omrežja, ki bi ga uporabili za njegovo popravilo.

Sorodni članki