Dostop do LAN prek OpenVPN ne deluje? Preverite cone, poti in povratno pot

Tunel poroča o uspešni povezavi, stran samega usmerjevalnika se naloži, preslikava diska na stroj za njim pa še vedno poteče. V tej kombinaciji ni nič protislovnega: usmerjevalnik odgovarja kot on sam, doseči karkoli za njim pa je druga odločitev, sprejeta na drugem mestu. Izvedite spodnje preglede po vrsti in ustavite se pri prvi napaki, ker vsak sloni na prejšnjem. Ko uspejo vsi štirje, je napaka nad tunelom in ne v njem.

Kateri filter vidi paket, namenjen v LAN

Paket, naslovljen na usmerjevalnik, se porabi lokalno; paket, naslovljen na gostitelja za njim, je treba posredovati, požarni zidovi pa ta dva primera presojajo ločeno. Dovoljenje, da dosežete usmerjevalnik, torej ne pove nič o dovoljenju, da ga prečkate. Programska oprema, ki skriva svoje nize pravil, vseeno izvaja oboje, običajno kot izbirnik, ki ponuja LAN, internet ali oboje. Če izbirnik izpusti LAN, noben poznejši pregled ne bo pomemben.

OpenWrt naredi to delitev pregledno in razlika je vredna enega branja. Cona, ki zaključi tunel, potrebuje pravilo posredovanja v cono LAN, medtem ko vhodno pravilo ureja le storitve na samem usmerjevalniku. Delujoča skrbniška stran ob mrtvem LAN je običajen rezultat tega manjkajočega pravila posredovanja.

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

Poglejte cilj posredovanja cone, ki nosi tunel: accept je tisto, kar lestev potrebuje, reject pa razloži vsak časovni presežek spodaj. Dve sosednji nastavitvi dajeta enak simptom, zato ju izključite, dokler ste tukaj. Brezžična izolacija skrije žične gostitelje pred brezžičnimi odjemalci, usmerjevalnik, ki nedejavne gostitelje LAN obravnava kot brez povezave, pa lahko odgovore zavrže tudi potem, ko posredovanje deluje.

Zakaj deljeni tunel potrebuje potisnjeno predpono

Odjemalec, ki vso promet pošilja skozi tunel, že ima predpono LAN prek svoje privzete poti, zato ni ničesar dodati. Deljeni tunel je primer, ki zahteva izrecno navedbo predpone, ker je nič drugega v konfiguraciji ne omenja. Dodajte direktivo v konfiguracijo strežnika in znova naložite storitev.

push "route 192.168.50.0 255.255.255.0"

Profili, ki vsebujejo route-nopull prezrejo potisnjene poti, zato ista predpona spada v odjemalčevo datoteko. V vsakem primeru potrdite, da je vnos prispel, namesto da bi to predpostavili, ker tiha prepisava izgleda enako kot težava s požarnim zidom.

ip route show | grep 192.168.50

Partner lokacija-lokacija zahteva več kot potiskanje. Strežnik se mora naučiti, katere predpone so za tem partnerjem, kar naredi vrstica iroute v njegovi datoteki client-config-dir, njegova lastna tabela pa potrebuje ustrezno pot v tunel.

Odgovor potrebuje naslov, ki ga lahko doseže

Posredovanje zahteve je le polovica izmenjave, ker mora gostitelj LAN odgovoriti na naslov iz bazena tunela. Mali usmerjevalniki to običajno uredijo s prevajanjem izvora v coni tunela, zato je odgovor naslovljen na usmerjevalnik in ne potrebuje konfiguracije drugje. Odstranite to prevajanje in gostitelj potrebuje svojo pot v bazen, ki jo dobi brezplačno, ko je usmerjevalnik njegova privzeta prehodna točka. Gostitelj z ročno nastavljenim naslovom in drugo prehodno točko odgovarja prek tiste, odjemalec pa vidi, kako se seja odpre in nato obstane.

tcpdump -ni tun0 host 192.168.50.20

Zaženite to na usmerjevalniku, medtem ko odjemalec ponavlja zahtevo, in berite cilj odgovora, ne same zahteve. Odgovor, naslovljen na bazen, pomeni, da povratna pot deluje in je napaka globlje. Popolna odsotnost odgovora pomeni, da gostitelj paketa ni nikoli sprejel, kar vas vrne k nizu pravil.

Lestev, ki se konča na pravem mestu

Štirje pregledi določijo plast in vsak je en ukaz, ne presoja. Zaženite jih po vrsti in ustavite se pri prvi napaki. Vrstni red je pomembnejši od ukazov, ker uspešen poznejši korak skrije razlog, zakaj je prejšnji spodletel.

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

Imena spadajo na konec lestve, nikoli na začetek. Deljenje, ki odgovarja kot 192.168.50.20, a ne kot nas.local, kaže na razreševanje imen ali pripono iskanja, spremembe požarnega zidu pa ne morejo spremeniti nobenega od obeh.

Zapišite prvi neuspešni korak in nato dajte vratom storitev svoj krog, ker sta poslušalec in dovoljenje gostitelja ločeni zahtevi. Deljenje datotek, namizje na daljavo in tokovi kamer potrebujejo oboje, požarni zid gostitelja, ki zaupa podomrežju LAN, a ne bazenu tunela, pa odjemalca zavrže, medtem ko ping še uspeva. Ko vsi pregledi uspejo in aplikacija še vedno ne deluje, je napaka nad tunelom: storitev, vezana na en vmesnik, ali posrednik, nastavljen na odjemalcu.