Maršrutizatorius VPN kliento režimu: kodėl dingsta LAN įrenginiai
LAN įrenginiai dingsta po to, kai maršrutizatorius pereina į VPN kliento režimą: pirmiausia patikrinkite persiuntimo kelio tikrinimo funkciją, paskui LAN diapazoną, kurį firmware pakeitė po jumis.
Tikėjimas, kad kliento režimas pats savaime užmuša LAN prieigą, veda žmones į netinkamą nustatymų meniu, o tikrosios priežastys paprastai yra dvi. Tunelis nepašalina LAN tilto ir netrukdo laidiniams bei belaidžiams klientams pasiekti vienas kito. Vietinę prieigą sulaužo arba tikrinimo funkcija maršrutizatoriaus persiuntimo kelyje, arba LAN adresų diapazonas, kuris pasislinko, kai tai padarė firmware. Abi sukelia tą patį skundą, ir nė vienos neišsprendžia VPN profilio perdiegimas.
Mitas ir ką kliento režimas iš tikrųjų keičia
Kliento režimas prideda tunelio sąsają ir numatytąjį maršrutą, einantį per ją, o tada persiunčia LAN srautą į tą tunelį. Tiltas tarp laidinių prievadų ir belaidžių radijo modulių lieka nepaliestas, kaip ir vietinis perjungimas. Keičiasi politika: koks srautas persiunčiamas, kur jis verčiamas ir kokį resolverį gauna klientai.
Šis skirtumas svarbus, nes sugedęs LAN paprastai reiškia, kad pasikeitė viena iš tų trijų politikų, o ne kad maršrutizatorius nustojo būti komutatoriumi. Maršrutizatorius, kuris vis dar atsako į savo administravimo puslapį, įrodo, kad LAN sąsaja gyva. Maršrutizatorius, kuris visai nieko neatsako, turi kitą problemą, pavyzdžiui, pakeistą LAN adresą arba klientą netinkamame potinklyje.
Taigi naudingas pirmas žingsnis yra išsiaiškinti, kuris sluoksnis sugedo, o ne keisti tą sluoksnį, kurį įtariate.
Išbandykite tris taikinius prieš liesdami nustatymą
Iš laidinio kliento atskirai išbandykite tris taikinius ir užrašykite kiekvieną rezultatą: paties maršrutizatoriaus LAN adresą, kitą įrenginį tame pačiame komutatoriuje pagal IP ir kažką, pasiekiamą tik per tunelį. Atlikite tokia tvarka, nes kiekvienas rezultatas atmeta skirtingą sluoksnį. Pirmame etape naudokite adresus, o ne vardus, nes vardo gedimas įtraukia DNS į ryšio klausimą.
Atsakymų modelis yra diagnozė. Maršrutizatorius, kuris atsako, o vietiniai įrenginiai ne, rodo vietinį perjungimą arba filtravimo funkciją, o ne maršrutizavimą. Vietiniai įrenginiai, kurie atsako, o tunelio pusė ne, rodo tunelio maršrutą arba nuotolinę užkardą. Jei viskas atsako pagal adresą, o vardai nepavyksta, tai resolverio klausimas, ir joks maršrutų redagavimas to neištaisys.
| What answers | What it points at |
|---|---|
| Router only | LAN-side filtering or a broken bridge |
| Router and local hosts, not remote | Tunnel route, NAT or remote firewall |
| Addresses yes, names no | DNS handed to clients by the router |
| Nothing at all | Client subnet or router LAN address changed |
Laikykite lentelę šalia bandymų rezultatų. Ji neaiškų skundą paverčia viena eilute, pagal kurią galima veikti.
Saugos sluoksnis persiuntimo kelio viduje
Vartotojiški maršrutizatoriai vis dažniau turi tikrinimo funkciją, kuri stebi persiunčiamą srautą, ir ji veikia tame pačiame kelyje, kuriuo paketai keliauja iš LAN į tunelį. Kai ta patikra negali klasifikuoti tunelio srauto, persiuntimas gali sustoti, nors pats tunelis lieka veikti ir maršrutizatorius praneša apie sveiką ryšį. VPN žurnale to nesimato, nes VPN iš tikrųjų prisijungė.
Diagnozė yra kontroliuojamas eksperimentas, o ne nuolatinis pakeitimas. Užsirašykite dabartinį nustatymą, vieno bandymo trukmei išjunkite funkciją, vėl pakelkite tunelį ir patikrinkite vieną vietinį hostą pagal adresą. Grįžtantis persiuntimas yra reikalingas įrodymas, ir tada kompromisas tampa sprendimu, o ne spėjimu. Jei niekas nepasikeitė, iš karto vėl įjunkite ir pereikite prie adresavimo priežasties.
Palikti mokamą saugos funkciją išjungtą, kad tunelis toliau veiktų, yra kompromisas, kurį reikia daryti sąmoningai ir užrašyti. Taip pat verta paklausti, ar tunelis priklauso kitam įrenginiui, nes maršrutizatorius, kuris turi viską tikrinti, ir maršrutizatorius, kuris turi viską persiųsti, yra du skirtingi darbai.
Antroji priežastis: LAN diapazonas pasislinko
Firmware atnaujinimai reguliariai grąžina LAN adresą į gamintojo numatytąją reikšmę, o kai kurie maršrutizatoriai turi aiškų režimo jungiklį, kuris nusprendžia, ar LAN išlaiko privatų diapazoną, ar paveldi jį iš aukščiau esančio įrenginio. Klientas, kuris tikisi 192.168.8.x, gali atsidurti 10.64.0.x, ir tada SSH sesija į hostą baigiasi, nors tunelis visiškai sveikas.
ipconfig /all
ip addr show
ip route get 192.168.8.20Perskaitykite prefiksą ir šliuzą iš nuomos prieš atidarydami maršrutizatoriaus puslapį. Pirmos dvi komandos rodo, ką klientas iš tikrųjų gavo, o trečioji rodo, kurią sąsają klientas naudotų vietiniam adresui, ir taip atsiskleidžia likęs maršrutas ar pasenęs potinklis. Tada palyginkite tai su LAN puslapiu ir režimu, kuriame yra maršrutizatorius.
Jei diapazonas negali grįžti, atnaujinkite kiekvieną objektą, kuris jį įvardija: DHCP rezervacijas, bet kokį statinį maršrutą į seną potinklį ir kiekvieną užkardos taisyklę, turinčią ankstesnį prefiksą. Diapazonas, kuris susiduria su nuotoliniu tunelio potinkliu, yra blogesnis variantas, nes vietiniai įrenginiai lieka pasiekiami, o nuotoliniai tikslai tyliai nukreipiami į LAN.
Prisijunkite iš naujo ir bandykite iš naujo paketų tvarka
Po bet kurio iš dviejų pakeitimų vėl prijunkite tunelį ir pakartokite bandymus paketų tvarka: maršrutizatorius, vietinis hostas, nuotolinis hostas, tada vardai, tada programa. Bandant programą pirmiausia paslepiama, kuris sluoksnis dar sugedęs, o naršyklės bandymas iš naujo su podėlyje esančiu vardu gali atrodyti kaip maršrutizavimo gedimas.
Užsirašykite firmware versiją, LAN prefiksą ir tikrinimo funkcijos būseną šalia VPN profilio. Visi trys yra konfigūracija, kurią kitas atnaujinimas gali perrašyti, ir dvi eilutės pastabų sutaupo ką tik praleistą valandą.