Maršrutizatoriaus VPN veikia, bet LAN klientai neturi interneto

Maršrutizatorius pasiekia internetą per savo tunelį, o įrenginiai už jo – ne. Peradresavimas, vertimas ir grįžtamieji maršrutai yra atskiri leidimai.

Būsena rodo, kad tunelis pakeltas, naršyklė pačiame maršrutizatoriuje įkelia puslapius, o kiekvienas įrenginys už jo vis tiek baigia laiko limitą. Ši kombinacija susiaurina problemą iki sluoksnio, kurio dauguma VPN vadovų niekada nemini: maršrutizatorius nėra vienintelis hostas, kurio paketai turi išgyventi tunelyje. Vietoje sugeneruotas srautas ir perduodamas srautas eina skirtingais keliais per tą pačią dėžę. Išbandykite iš kliento – skirtumas nustoja būti teorinis.

Skaitykite gedimą iš LAN hosto

Pradėkite nuo įrenginio, kuris nepavyksta, nes maršrutizatoriuje atlikta diagnostika atsako į kitą klausimą. Patvirtinkite, kad kliento numatytasis šliuzas yra šis maršrutizatorius, užsirašykite jo šaltinio adresą ir potinklį, tada pažiūrėkite, kas išeina iš maršrutizatoriaus tunelio sąsajos.

Jei kliento adresas verčiamas, nuotolinė pusė mato tunelio adresą, ir iš ten viskas atrodo sveika, nors klientas vis tiek nepavyksta. Jei neverčiamas, nuotolinė pusė turi žinoti maršrutą atgal į kliento potinklį, o daugelis šliuzų tokio maršruto pagal nutylėjimą neturi. Bet kuriuo atveju paties maršrutizatoriaus sėkmė nesvarbi, nes jo paketai buvo sugeneruoti vietoje ir niekada neėjo per peradresavimo kelią.

Vietinis ir perduodamas srautas skiriasi

Linux ir dauguma maršrutizatorių programinės įrangos paketus, kilusius iš pačios dėžės, tvarko kitaip nei paketus, einančius per ją. Išvesties grandinė mato pirmąjį tipą, peradresavimo grandinė mato antrąjį, ir politika, pritaikyta paties maršrutizatoriaus srautui, gali palikti peradresavimą nepaliestą.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

Patikrinkite, ar peradresavimas apskritai įjungtas, tada skaitykite peradresavimo grandinę, o ne išvesties grandinę. Taisyklė, leidžianti užšifruotą išorinį ryšį, nėra taisyklė, leidžianti peradresuoti iššifruotus paketus, ir šių dviejų painiojimas sukuria būtent šį simptomą. Tai, kad tunelis pakeltas, įrodo tik pirmąjį.

Grįžtamasis kelias taip pat turi egzistuoti

Šaltinio vertimas nusprendžia, ar reikia grįžtamojo kelio. Kai tunelio sąsajoje įjungtas maskavimas, atsakymai grįžta į tunelio adresą, o maršrutizatorius juos išverčia atgal. Be jo nuotoliniam šliuzui reikia aiškaus maršruto į kliento potinklį, o jo paties politika turi leisti tą kryptį.

Prieš ką nors keisdami užsirašykite, kurią iš dviejų konstrukcijų naudoja diegimas, nes pataisymai nukreipti priešingomis kryptimis. Vertimo pridėjimas paslepia trūkstamą grįžtamąjį maršrutą ir sugriauna programas, kurioms reikia originalaus šaltinio adreso. Grįžtamojo maršruto pridėjimas be vertimo tyliai nepavyksta, kai nuotolinė ugniasienė atmeta nepažįstamą šaltinį. Pasirinkite vieną, dokumentuokite ir suderinkite kitą pusę.

Kliento DNS priklauso tai pačiai apžvalgai. Maršrutizatoriaus sprendėjas gali atsakyti, o klientas, nukreiptas į kitą serverį, negauna nieko.

Patikrinkite vieną leistiną ir vieną draudžiamą srautą

Po pataisymo išbandykite naują ryšį iš kliento, o ne esamą maršrutizatoriaus sesiją. Tada patvirtinkite, kad segmentas, kuris neturėtų naudoti tunelio, vis tiek jo nenaudoja.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

Patikrinkite stebimą šaltinio adresą kitame gale, nes tai pasako, kuri konstrukcija iš tikrųjų veikia. Patikrinkite ir vardo paiešką, ir adresą, nes sprendėjo elgsena yra atskiras kelias per tą pačią dėžę.

Laikykite taisykles apribotas kliento tinklais, kuriems reikia tunelio, ir nepasiduokite pagundai išjungti peradresavimo filtrą, kad vienas testas praeitų. Tas pakeitimas sutaiso testą ir pašalina ribą, kurią tunelis turėjo užtikrinti. Užrašykite šaltinio adresą, vertimo sprendimą ir grįžtamąjį maršrutą vienoje pastaboje su data.

Susiję straipsniai