hostapd i OpenVPN na jednom Pi računaru: čiji je podrazumijevani put?

hostapd i OpenVPN klijent mogu dijeliti jedan Pi kada most zadrži svoj podrazumijevani put, a tunel zadrži put do svog servera. Komande i vraćanje.

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

Popišite interfejse prije nego što bilo šta 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čunaru treba put do interneta da bi dosegao svoj server, a mostu treba adresa prolaza koju ti klijenti mogu koristiti.

Pročitajte trenutno stanje prije nego što ga promijenite, jer ove četiri komande razdvajaju problem interfejsa od problema rutiranja.

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

Ako br0 nosi adresu ali nema podrazumijevani put, klijenti stižu do Pi računara i ničega iza njega. Ako podrazumijevani put pokazuje na tun0 dok je tunel isključen, Pi računar uopće nema radni put, a simptom klijenta izgleda potpuno isto. Oba slučaja izgledaju identično s telefona, zbog čega se tabela ruta mora čitati direktno.

Dajte mostu podrazumijevani put koji mu pripada

Raspberry Pi OS često ostavlja most bez podrazumijevanog puta kada je most nastao nakon što je datoteka interfejsa napisana. Blok pripada u /etc/dhcpcd.conf i treba da imenuje uzvodni ruter, a ne Pi računar.

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 ruter, a 192.168.50.2 je adresa mosta Pi računara u istoj podmreži, zato ubacite svoj plan umjesto da kopirate brojeve. Članovi mosta također ne smiju tražiti rutere, inače Pi računar završi s konkurentskim podrazumijevanim putevima čiji pobjednik zavisi od metrike i vremena, a ne od namjere.

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

Zaustavite tunel da ne otme put do sopstvenog servera

OpenVPN klijent koji prihvati redirect-gateway preuzima podrazumijevani put i usmjerava ga u tunel. To je ispravno kada svaki klijent pristupne točke treba koristiti VPN, a pogrešno kada treba samo neke destinacije. U svakom slučaju, vlastita veza Pi računara sa serverom ne smije putovati unutar tunela koji se još gradi. OpenVPN dodaje rutu do hosta preko originalnog prolaza kada preusmjeri podrazumijevani put, i to je upravo ponašanje koje održava transport živim; ako ta ruta nedostaje, tunel se ruši čim se uspostavi.

Brzo poređenje 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 treba da pređu tunel, koristite route-nopull i dodajte željene rute ručno, ili pošaljite uži skup sa servera. Most zadržava podrazumijevani put u tom rasporedu, a DNS postaje sljedeća odluka: prosljeđivanje dnsmasq-a kućnom resolveru 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čunaru i prolaz na dalekoj strani spreman da rutira podmrežu 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čica koja radi kada server ne prihvati prefiks pristupne točke, po cijeni da svaki klijent izgleda kao tunelska adresa Pi računara u zapisima daleke strane. Rutiranje prefiksa bez NAT-a zadržava adrese vidljivim i zavisi od povratne rute za 192.168.50.0/24 na kućnoj strani.

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

Provjerite s klijenta, zatim se čisto vratite

Testirajte ovim redom sa telefona ili laptopa na pristupnoj točki: zakupnina iz dnsmasq-a, ping na adresu mosta, zatim odredište na dalekoj strani tunela. Svaki korak izoluje jedan sloj umjesto da proizvede jedan beskorisni neuspjeh.

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

Zatim potvrdite da Pi računar 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 server dozvoljava 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 komande: uklonite blok, ponovo pokrenite dhcpcd i zamijenite podrazumijevani put izričito s ip route replace default via 192.168.50.1 dev br0. Učinite to prije nego što se prozor za održavanje zatvori, a ne poslije, jer Pi računar koji je izgubio podrazumijevani put nije dostupan s mreže koju biste koristili da ga popravite.

Povezani članci