Ruuter VPN-i kliendirežiimis: miks LAN-seadmed kaovad
LAN-seadmed kaovad pärast seda, kui ruuter läheb VPN-i kliendirežiimi: testige esmalt edastustee kontrollfunktsiooni, seejärel LAN-vahemikku, mille püsivara teie all muutis.
Usk, et kliendirežiim ise tapab LAN-juurdepääsu, viib inimesed valesse seadete menüüsse, ja tegelikud põhjused on tavaliselt kaks. Tunnel ei eemalda LAN-silda ega takista juhtmega ja juhtmevabadel klientidel üksteiseni jõudmast. Kohalikku juurdepääsu rikub kas ruuteri edastustee kontrollfunktsioon või LAN-i aadressivahemik, mis püsivara muutmise ajal liikus. Mõlemad tekitavad sama kaebuse ja kumbagi ei paranda VPN-profiili uuesti paigaldamine.
Müüt ja mida kliendirežiim tegelikult muudab
Kliendirežiim lisab tunneliliidese ja vaikimisi marsruudi, mis selle kaudu läheb, ning edastab seejärel LAN-liikluse sellesse tunnelisse. Sild juhtmega portide ja juhtmevabade raadiote vahel jääb puutumatuks, samuti kohalik kommuteerimine. Muutub poliitika: milline liiklus edastatakse, kus seda tõlgitakse ja millise resolveri kliendid saavad.
See erinevus on oluline, sest katkine LAN tähendab tavaliselt, et üks neist kolmest poliitikast muutus, mitte et ruuter lakkas olemast kommutaator. Ruuter, mis vastab endiselt oma halduslehele, tõestab, et LAN-liides on elus. Ruuter, mis ei vasta üldse mitte millelegi, on teise probleemiga, näiteks muutunud LAN-aadressi või vale alamvõrgu klientiga.
Seega on kasulik esimene samm leida, milline kiht katki läks, mitte muuta kihti, mida kahtlustate.
Testige kolme sihtmärki enne seade puudutamist
Juhtmega kliendist testige kolme sihtmärki eraldi ja kirjutage iga tulemus üles: ruuteri enda LAN-aadress, teine seade samas kommutaatoris IP järgi ja midagi, mis on kättesaadav ainult tunneli kaudu. Tehke neid selles järjekorras, sest iga tulemus välistab erineva kihi. Esimesel korral kasutage nimede asemel aadresse, sest nime tõrge segab DNS-i ühenduvusküsimusega.
Vastuste muster on diagnoos. Ruuter, mis vastab, samal ajal kui kohalikud seadmed ei vasta, osutab kohalikule kommuteerimisele või filtreerimisfunktsioonile, mitte marsruutimisele. Kohalikud seadmed, mis vastavad, samal ajal kui tunneli pool ei vasta, osutavad tunnelimarsruudile või kaugtulemüürile. Kui kõik vastab aadressi järgi, aga nimed ei tööta, on see resolveri küsimus ja ükski marsruudi muutmine seda ei paranda.
| 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 |
Hoidke tabelit testitulemuste kõrval. See muudab ebamäärase kaebuse üheks reaks, mille alusel saab tegutseda.
Turvakiht edastustee sees
Tarbija-ruuteritel on üha sagedamini kontrollfunktsioon, mis jälgib edastatavat liiklust, ja see töötab samas tees, mis kannab pakette LAN-ist tunnelisse. Kui see kontroll ei suuda tunneliliiklust liigitada, võib edastamine takerduda, samal ajal kui tunnel ise jääb püsti ja ruuter teatab tervest ühendusest. VPN-i logis ei ole seda näha, sest VPN ühendus ikkagi loodi.
Diagnoos on kontrollitud katse, mitte alaline muudatus. Märkige praegune seade, lülitage funktsioon ühe testi ajaks välja, tõstke tunnel uuesti üles ja testige üht kohalikku hosti aadressi järgi. Tagasi tulev edastamine on tõend, mida vajasite, ja seejärel muutub kompromiss otsuseks, mitte oletuseks. Kui miski ei muutu, lülitage see kohe uuesti sisse ja liikuge aadressimise põhjuse juurde.
Makstud turvafunktsiooni väljalülitatuks jätmine, et tunnel töötaks edasi, on kompromiss, mille tuleb teha teadlikult ja üles kirjutada. Tasub ka küsida, kas tunnel kuulub teise seadmesse, sest ruuter, mis peab kõike kontrollima, ja ruuter, mis peab kõike edastama, on kaks erinevat tööd.
Teine põhjus: LAN-vahemik liikus
Püsivara uuendused lähtestavad LAN-aadressi rutiinselt tootja vaikeväärtusele ja mõnel ruuteril on selgesõnaline režiimüliti, mis otsustab, kas LAN hoiab privaatset vahemikku või pärib selle ülalpool asuvalt seadmelt. Klient, kes ootab 192.168.8.x, võib sattuda 10.64.0.x peale ja siis aegub SSH-seanss hostiga, kuigi tunnel on täiesti terve.
ipconfig /all
ip addr show
ip route get 192.168.8.20Lugege prefiks ja lüüs rendilepingust enne ruuteri lehe avamist. Kaks esimest käsku näitavad, mida klient tegelikult sai, ja kolmas näitab, millist liidest klient kohaliku aadressi jaoks kasutaks, ning nii paljastab end ülejäänud marsruut või aegunud alamvõrk. Seejärel võrrelge seda LAN-lehe ja ruuteri režiimiga.
Kui vahemik ei saa tagasi pöörduda, värskendage iga objekti, mis seda nimetab: DHCP-reserveeringud, iga staatiline marsruut vanasse alamvõrku ja iga tulemüürireegel, mis kannab eelmist prefiksit. Vahemik, mis põrkub tunneli kaugema alamvõrguga, on hullem variant, sest kohalikud seadmed jäävad kättesaadavaks, samal ajal kui kaugsihtkohad suunatakse vaikselt LAN-i.
Ühendage uuesti ja testige paketi järjekorras
Pärast kumbagi muudatust ühendage tunnel uuesti ja korrake teste paketi järjekorras: ruuter, kohalik host, kaugem host, seejärel nimed, seejärel rakendus. Rakenduse esimesena testimine varjab, milline kiht on veel katki, ja brauseri korduskatse vahemällu salvestatud nime vastu võib näida marsruutimistõrkena.
Kirjutage püsivara versioon, LAN-prefiks ja kontrollfunktsiooni olek VPN-profiili kõrvale. Kõik kolm on konfiguratsioon, mille järgmine uuendus võib üle kirjutada, ja kaks rida märkmeid säästab tunni, mille just veetsite.