Pristup LAN mreži preko OpenVPN-a je pokvaren? Provjerite zone, rute i povratni put

Ruter odgovara jer je lokalni. Za mašinu iza njega potrebno je pravilo prosljeđivanja, prefiks na klijentu i povratni put za odgovor.

Tunel prijavljuje uspješnu vezu, ruterova vlastita stranica se učitava, a mapiranje diska na mašinu iza njega i dalje istječe. Ništa u toj kombinaciji nije proturječno: ruter odgovara kao on sam, a dosezanje bilo čega iza njega druga je odluka donesena na drugom mjestu. Prođite provjere ispod redom i stanite na prvom neuspjehu, jer se svaka oslanja na prethodnu. Kada sve četiri prođu, kvar je iznad tunela, a ne u njemu.

Koji filter vidi paket namijenjen LAN mreži

Paket adresiran na ruter troši se lokalno; paket adresiran na host iza njega mora se proslijediti, a vatrozidi te dvije situacije sude odvojeno. Dopuštenje da dosegnete ruter stoga ne govori ništa o dopuštenju da ga prijeđete. Firmver koji skriva svoje skupove pravila ipak provodi oba, obično kao birač koji nudi LAN, internet ili oboje. Ako birač izostavi LAN, nijedna kasnija provjera neće biti važna.

OpenWrt tu podjelu čini preglednom i razliku vrijedi pročitati jednom. Zona koja završava tunel treba pravilo prosljeđivanja prema LAN zoni, dok ulazno pravilo uređuje samo usluge na samom ruteru. Ispravna administratorska stranica uz mrtav LAN uobičajen je rezultat tog nedostajućeg pravila prosljeđivanja.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

Pogledajte odredište prosljeđivanja zone koja nosi tunel: accept je ono što ljestvica treba, a reject objašnjava svaki istek ispod. Dvije susjedne postavke daju isti simptom, pa ih isključite dok ste ovdje. Bežična izolacija skriva žičane hostove od bežičnih klijenata, a ruter koji neaktivne LAN hostove smatra izvan mreže može odbaciti odgovore i nakon što prosljeđivanje proradi.

Zašto podijeljeni tunel treba gurnuti prefiks

Klijent koji sav promet šalje kroz tunel već ima LAN prefiks kroz svoju zadanu rutu, pa nema što dodati. Podijeljeni tunel je slučaj koji zahtijeva izričito navođenje prefiksa, jer ga ništa drugo u konfiguraciji ne spominje. Dodajte direktivu u konfiguraciju poslužitelja i ponovno učitajte uslugu.

push "route 192.168.50.0 255.255.255.0"

Profili koji sadrže route-nopull zanemaruju gurnute rute, pa isti prefiks pripada u datoteku klijenta. U svakom slučaju potvrdite da je unos stigao umjesto da to pretpostavite, jer tiha zamjena izgleda isto kao problem s vatrozidom.

ip route show | grep 192.168.50

Partner od lokacije do lokacije traži više od guranja. Poslužitelj mora naučiti koji prefiksi stoje iza tog partnera, što čini redak iroute u njegovoj datoteci client-config-dir, a njegova vlastita tablica treba odgovarajuću rutu u tunel.

Odgovor treba adresu koju može dosegnuti

Prosljeđivanje zahtjeva samo je pola razmjene, jer LAN host mora odgovoriti na adresu iz skupa tunela. Mali ruteri to obično rješavaju prevođenjem izvora na zoni tunela, pa je odgovor adresiran na ruter i ne treba konfiguraciju drugdje. Uklonite to prevođenje i hostu treba vlastita ruta do skupa, koju dobiva besplatno kada je ruter njegov zadani pristupnik. Host s ručno postavljenom adresom i drugim pristupnikom odgovara kroz taj pristupnik, a klijent gleda kako se sesija otvara i zatim zapinje.

tcpdump -ni tun0 host 192.168.50.20

Pokrenite to na ruteru dok klijent ponavlja zahtjev i čitajte odredište odgovora, a ne sam zahtjev. Odgovor adresiran na skup znači da povratni put radi i da je kvar dublje. Nikakav odgovor znači da host nikada nije prihvatio paket, što vas vraća na skup pravila.

Ljestvica koja završava na pravom mjestu

Četiri provjere lociraju sloj i svaka je jedna naredba, a ne procjena. Pokrenite ih redom i stanite na prvom neuspjehu. Redoslijed je važniji od naredbi, jer uspješan kasniji korak skriva razlog neuspjeha ranijeg.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

Imena pripadaju na kraj ljestvice, nikada na početak. Dijeljeni resurs koji odgovara kao 192.168.50.20, ali ne kao nas.local, upućuje na razrješavanje imena ili na sufiks pretraživanja, a izmjene vatrozida ne mogu promijeniti ni jedno.

Zabilježite prvi neuspjeli korak, zatim dajte portovima usluga zaseban prolaz, jer su slušatelj i dopuštenje hosta odvojeni uvjeti. Dijeljenje datoteka, udaljena radna površina i prijenosi s kamera trebaju oboje, a vatrozid hosta koji vjeruje LAN podmreži ali ne skupu tunela odbacuje klijenta dok ping još prolazi. Kada sve provjere prođu, a aplikacija i dalje ne radi, kvar je iznad tunela: usluga vezana na jedno sučelje ili proxy konfiguriran na klijentu.

Povezani članci