hostapd i OpenVPN na jednom Pi računalu: čiji je zadani put?

hostapd i OpenVPN klijent mogu dijeliti jedan Pi kada most zadrži svoj zadani put, a tunel zadrži put do svog poslužitelja. Naredbe i vraćanje.

Telefoni se povezuju s pristupnom točkom, dobivaju adresu, a zatim ne stižu nikamo čim se tunel podigne. hostapd je u tom stanju obično zdrav, a i OpenVPN; ono što se kvari jest zadani put, koji ili nikada nije postojao na mostu ili ga je tunel zamijenio ne ostavljajući put do samog VPN poslužitelja. Ovaj priručnik vraća taj put na njegovo mjesto i dokazuje rezultat s klijenta, a ne s Pi računala. Svaki je korak reverzibilan i ništa ovdje ne mijenja konfiguraciju tunela dok ne znate koji promet želite unutar njega.

Popišite sučelja prije nego što bilo što uredite

Uobičajeni raspored stavlja bežični radio i žičani port unutar br0, pokreće hostapd prema mostu i dijeli zakupnine iz dnsmasq-a, dok OpenVPN klijent stvara tun0. Tada tri odvojena zahtjeva izgledaju kao jedan: klijentima pristupne točke treba Pi kao njihov prolaz, Pi računalu treba put do interneta da bi dosegnuo svoj poslužitelj, a mostu treba adresa prolaza koju ti klijenti mogu koristiti.

Pročitajte trenutno stanje prije nego što ga promijenite, jer ove četiri naredbe razdvajaju problem sučelja od problema usmjeravanja.

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

Ako br0 nosi adresu ali nema zadani put, klijenti stižu do Pi računala i ničega iza njega. Ako zadani put pokazuje na tun0 dok je tunel isključen, Pi računalo uopće nema radni put, a simptom klijenta izgleda posve isto. Oba slučaja izgledaju identično s telefona, zato se tablica usmjeravanja mora čitati izravno.

Dajte mostu zadani put koji mu pripada

Raspberry Pi OS često ostavlja most bez zadanog puta kada je most nastao nakon što je datoteka sučelja napisana. Blok pripada u /etc/dhcpcd.conf i trebao bi imenovati uzvodni usmjerivač, a ne Pi računalo.

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

U tom primjeru 192.168.50.1 je postojeći usmjerivač, a 192.168.50.2 je adresa mosta Pi računala u istoj podmreži, zato ubacite svoj plan umjesto da kopirate brojeve. Članovi mosta također ne smiju tražiti usmjerivače, inače Pi računalo završi s konkurentskim zadanim putevima čiji pobjednik ovisi o metrici i vremenu, a ne o namjeri.

Nakon systemctl restart dhcpcd ip route show default treba jednom navesti br0 i bez duplikata sa žičanog porta. Potvrdite pretragu, a ne tablicu, jer zastarjeli unos može stajati pokraj pobjedničkog: ip -4 route get 203.0.113.10 mora imenovati br0. Ta adresa dolazi iz dokumentacijskog raspona TEST-NET-3, pa se ne može sudariti s pravim poslužiteljem dok ovo čitate.

Zaustavite tunel da ne otme put do vlastitog poslužitelja

OpenVPN klijent koji prihvati redirect-gateway preuzima zadani put i usmjerava ga u tunel. To je ispravno kada svaki klijent pristupne točke treba koristiti VPN, a pogrešno kada treba samo neka odredišta. U svakom slučaju, vlastita veza Pi računala s poslužiteljem ne smije putovati unutar tunela koji se još gradi. OpenVPN dodaje rutu do hosta preko izvornog prolaza kada preusmjeri zadani put, i to je upravo ponašanje koje održava prijevoz živim; ako ta ruta nedostaje, tunel se urušava čim se uspostavi.

Brza usporedba tog transportnog puta prije i poslije povezivanja vrijedi deset sekundi. ip -4 route get 203.0.113.10 treba imenovati uređaj donjeg sloja u oba stanja, mijenja se samo metrika. Ako imenuje tun0 nakon podizanja tunela, ruta do hosta nikada nije instalirana i sljedeće ponovno povezivanje će propasti.

Kada samo odabrani prefiksi trebaju prijeći tunel, koristite route-nopull i dodajte željene rute ručno, ili pošaljite uži skup s poslužitelja. Most zadržava zadani put u tom rasporedu, a DNS postaje sljedeća odluka: prosljeđivanje dnsmasq-a kućnom razrješivaču ima smisla samo za imena koja tamo zaista žive.

Odlučite o prosljeđivanju i NAT-u

Puni tunel zahtijeva omogućeno prosljeđivanje na Pi računalu i prolaz na dalekoj strani spreman za usmjeravanje podmreže pristupne točke. Provjerite prosljeđivanje prije svega ostalog, jer nula čini svaku promjenu rute nevažnom.

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 pravilo je prečac koji radi kada poslužitelj ne prihvati prefiks pristupne točke, po cijeni da svaki klijent izgleda kao tunelska adresa Pi računala u zapisima daleke strane. Usmjeravanje prefiksa bez NAT-a zadržava adrese vidljivima i ovisi o povratnoj ruti za 192.168.50.0/24 na kućnoj strani.

Zapišite izbor pokraj pravila vatrozida, jer NAT pravilo nevidljivo u rasporedu postaje neobjašnjivo šest mjeseci kasnije. Držite IPv6 u istoj odluci; radni put IPv4 pokraj pokvarenog puta IPv6 i dalje se čita kao napola pokvaren u pregledniku.

Provjerite s klijenta, zatim se čisto vratite

Testirajte ovim redom s telefona ili prijenosnog računala na pristupnoj točki: zakupnina iz dnsmasq-a, ping na adresu mosta, zatim odredište na dalekoj strani tunela. Svaki korak izolira jedan sloj umjesto da proizvede jedan beskoristan neuspjeh.

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

Zatim potvrdite da Pi računalo još ima vlastiti izlaz: ip route get 203.0.113.10 treba imenovati uređaj donjeg sloja, a ping -c 3 -I br0 203.0.113.10 treba odgovoriti ako poslužitelj dopušta ICMP. Ako prva dva klijentska koraka prođu, a treći ne uspije, kvar je u prosljeđivanju ili NAT-u. Ako drugi korak ne uspije, most ili DHCP još nisu potpuni.

Vraćanje je jedno uređivanje datoteke i dvije naredbe: uklonite blok, ponovno pokrenite dhcpcd i zamijenite zadani put izričito s ip route replace default via 192.168.50.1 dev br0. Učinite to prije nego što se zatvori prozor za održavanje, a ne poslije, jer Pi računalo koje je izgubilo zadani put nije dostupno s mreže koju biste koristili da ga popravite.

Povezani članci