OpenVPN LAN prieiga sutrikusi? Patikrinkite zonas, maršrutus ir grįžimo kelią

Tunelis praneša apie sėkmingą ryšį, paties maršrutizatoriaus puslapis įkeliamas, o disko prijungimas prie už jo esančio kompiuterio vis tiek baigiasi skirtuoju laiku. Šiame derinyje nėra nieko prieštaringo: maršrutizatorius atsako kaip jis pats, o pasiekti ką nors už jo yra kitas sprendimas, priimtas kitoje vietoje. Atlikite toliau pateiktus patikrinimus iš eilės ir sustokite ties pirmuoju nesėkme, nes kiekvienas remiasi ankstesniu. Kai visi keturi praeina, gedimas yra virš tunelio, o ne jame.

Kuris filtras mato į LAN siunčiamą paketą

Maršrutizatoriui adresuotas paketas suvartojamas vietoje; už jo esančiam kompiuteriui adresuotas paketas turi būti persiunčiamas, o ugniasienės šiuos du atvejus vertina atskirai. Taigi leidimas pasiekti maršrutizatorių nieko nesako apie leidimą jį pereiti. Programinė aparatinė įranga, kuri slepia savo taisyklių rinkinius, vis tiek įgyvendina abu, paprastai kaip parinkiklis, siūlantis LAN, internetą arba abu. Jei parinkiklis praleidžia LAN, joks vėlesnis patikrinimas nebeturės reikšmės.

OpenWrt padaro šį padalijimą tikrinamą, ir skirtumas vertas vieno perskaitymo. Zona, kuri užbaigia tunelį, turi turėti persiuntimo taisyklę į LAN zoną, o įvesties taisyklė valdo tik paslaugas pačiame maršrutizatoriuje. Veikiantis administravimo puslapis šalia negyvo LAN yra įprastas tos trūkstamos persiuntimo taisyklės rezultatas.

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

Pažiūrėkite į tunelį nešančios zonos persiuntimo tikslą: accept yra tai, ko reikia kopėčioms, o reject paaiškina kiekvieną toliau esantį laiko limitą. Du gretimi nustatymai sukelia tą patį simptomą, todėl atmeskite juos, kol čia esate. Belaidis izoliavimas slepia laidinius kompiuterius nuo belaidžių klientų, o maršrutizatorius, kuris neaktyvius LAN kompiuterius laiko neprisijungusiais, gali mesti atsakymus net ir po to, kai persiuntimas pradeda veikti.

Kodėl padalintam tuneliui reikia stumiamo priešdėlio

Klientas, kuris visą srautą siunčia per tunelį, jau turi LAN priešdėlį per savo numatytąjį maršrutą, todėl nieko pridėti nereikia. Padalintas tunelis yra atvejis, kuris reikalauja aiškiai nurodyti priešdėlį, nes niekas kitas konfigūracijoje jo nemini. Pridėkite direktyvą prie serverio konfigūracijos ir iš naujo įkelkite paslaugą.

push "route 192.168.50.0 255.255.255.0"

Profiliai, kuriuose yra route-nopull nepaiso stumiamų maršrutų, todėl tas pats priešdėlis priklauso kliento failui. Bet kuriuo atveju patvirtinkite, kad įrašas atvyko, o ne manykite, nes tylus pakeitimas atrodo lygiai taip pat kaip ugniasienės problema.

ip route show | grep 192.168.50

Svetainės-svetainės partneris prašo daugiau nei pastūmimo. Serveris turi sužinoti, kokie priešdėliai yra už to partnerio, ką daro eilutė iroute jo client-config-dir faile, o jo pačio lentelėje reikia atitinkamo maršruto į tunelį.

Atsakymui reikia adreso, kurį jis gali pasiekti

Užklausos persiuntimas yra tik pusė mainų, nes LAN kompiuteris turi atsakyti į adresą tunelio telkinyje. Maži maršrutizatoriai paprastai tai sutvarko išversdami šaltinį tunelio zonoje, todėl atsakymas adresuojamas maršrutizatoriui ir nereikia konfigūracijos kitur. Pašalinkite tą vertimą, ir kompiuteriui reikės savo maršruto į telkinį, kurį jis gauna nemokamai, kai maršrutizatorius yra jo numatytasis šliuzas. Kompiuteris su rankiniu būdu nustatytu adresu ir kitu šliuzu atsako per tą šliuzą, o klientas mato sesiją atsidarant ir tada sustojant.

tcpdump -ni tun0 host 192.168.50.20

Paleiskite tai maršrutizatoriuje, kol klientas kartoja užklausą, ir skaitykite atsakymo paskirties vietą, o ne pačią užklausą. Į telkinį adresuotas atsakymas reiškia, kad grįžimo kelias veikia ir gedimas yra giliau. Visai nėra atsakymo – kompiuteris niekada nepriėmė paketo, o tai grąžina prie taisyklių rinkinio.

Kopėčios, kurios baigiasi tinkamoje vietoje

Keturi patikrinimai nustato sluoksnį, ir kiekvienas yra viena komanda, o ne sprendimas. Paleiskite juos iš eilės ir sustokite ties pirmuoju nesėkme. Eilė svarbesnė už komandas, nes vėlesnis sėkmingas žingsnis paslepia priežastį, kodėl ankstesnis nepavyko.

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

Vardai priklauso kopėčių pabaigai, niekada pradžiai. Bendrai naudojamas išteklius, kuris atsako kaip 192.168.50.20, bet ne kaip nas.local, rodo į vardų sprendimą arba paieškos priesagą, o ugniasienės pakeitimai negali pakeisti nė vieno.

Užsirašykite pirmąjį nesėkmingą žingsnį, tada duokite paslaugų prievadams atskirą ėjimą, nes klausytojas ir kompiuterio leidimas yra atskiri reikalavimai. Bylų bendrinimas, nuotolinis darbalaukis ir kamerų srautai reikalauja abiejų, o kompiuterio ugniasienė, kuri pasitiki LAN potinkliu, bet ne tunelio telkiniu, numeta klientą, nors ping dar pavyksta. Kai visi patikrinimai praeina, o programa vis tiek nepavyksta, gedimas yra virš tunelio: paslauga, susieta su vienu sąsaja, arba tarpinis serveris, sukonfigūruotas kliente.