Maršrutētājs VPN klienta režīmā: kāpēc pazūd LAN ierīces
LAN ierīces pazūd pēc tam, kad maršrutētājs pāriet VPN klienta režīmā: vispirms pārbaudiet pārsūtīšanas ceļa inspicēšanas funkciju, pēc tam LAN diapazonu, ko firmware mainīja zem jums.
Ticība, ka klienta režīms pats nogalina LAN piekļuvi, ved cilvēkus uz nepareizo iestatījumu izvēlni, un patiesie cēloņi parasti ir divi. Tunelis nenoņem LAN tiltu un netraucē vadu un bezvadu klientiem sasniegt viens otru. Vietējo piekļuvi lauž vai nu inspicēšanas funkcija maršrutētāja pārsūtīšanas ceļā, vai LAN adrešu diapazons, kas pārvietojās, kad to darīja firmware. Abi rada vienu un to pašu sūdzību, un nevienu neizlabo VPN profila pārinstalēšana.
Mīts un ko klienta režīms patiešām maina
Klienta režīms pievieno tuneļa saskarni un noklusējuma maršrutu, kas iet caur to, un pēc tam pārsūta LAN satiksmi šajā tunelī. Tilts starp vadu portiem un bezvadu radio moduļiem paliek neskarts, tāpat kā vietējā komutācija. Mainās politika: kāda satiksme tiek pārsūtīta, kur tā tiek tulkota un kādu resolveri klienti saņem.
Šī atšķirība ir svarīga, jo bojāts LAN parasti nozīmē, ka mainījās viena no šīm trim politikām, nevis ka maršrutētājs pārstāja būt komutators. Maršrutētājs, kas joprojām atbild uz savu administrēšanas lapu, ir pierādījums, ka LAN saskarne ir dzīva. Maršrutētājam, kas neatbild ne uz ko, ir cita problēma, piemēram, mainīta LAN adrese vai klients nepareizajā apakštīklā.
Tāpēc noderīgais pirmais solis ir noskaidrot, kurš slānis sabruka, nevis mainīt to slāni, kuru jūs turat aizdomās.
Pārbaudiet trīs mērķus pirms iestatījuma aizskaršanas
No vadu klienta atsevišķi pārbaudiet trīs mērķus un pierakstiet katru rezultātu: paša maršrutētāja LAN adresi, citu ierīci tajā pašā komutatorā pēc IP un kaut ko, kas sasniedzams tikai caur tuneli. Veiciet tos šajā secībā, jo katrs rezultāts izslēdz citu slāni. Pirmajā kārtā izmantojiet adreses, nevis nosaukumus, jo nosaukuma kļūme sajauc DNS ar savienojamības jautājumu.
Atbilžu modelis ir diagnoze. Maršrutētājs, kas atbild, kamēr vietējās ierīces neatbild, norāda uz vietējo komutāciju vai filtrēšanas funkciju, nevis maršrutēšanu. Vietējās ierīces, kas atbild, kamēr tuneļa puse neatbild, norāda uz tuneļa maršrutu vai attālo ugunsmūri. Ja viss atbild pēc adreses, bet nosaukumi neizdodas, tas ir resolvera jautājums, un maršrutu rediģēšana to neizlabos.
| 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 |
Turiet tabulu blakus testu rezultātiem. Tā neskaidru sūdzību pārvērš vienā rindā, pēc kuras var rīkoties.
Drošības slānis pārsūtīšanas ceļā
Patērētāju maršrutētājos arvien biežāk ir inspicēšanas funkcija, kas uzrauga pārsūtīto satiksmi, un tā darbojas tajā pašā ceļā, kas pārvadā paketes no LAN uz tuneli. Kad šī pārbaude nevar klasificēt tuneļa satiksmi, pārsūtīšana var apstāties, kamēr pats tunelis paliek aktīvs un maršrutētājs ziņo par veselīgu savienojumu. VPN žurnālā tas nav redzams, jo VPN patiešām izveidoja savienojumu.
Diagnoze ir kontrolēts eksperiments, nevis pastāvīga izmaiņa. Pierakstiet pašreizējo iestatījumu, izslēdziet funkciju uz viena testa laiku, atkal paceliet tuneli un pārbaudiet vienu vietējo resursdatoru pēc adreses. Atgrieztā pārsūtīšana ir vajadzīgais pierādījums, un tad kompromiss kļūst par lēmumu, nevis minējumu. Ja nekas nemainās, nekavējoties ieslēdziet to atkal un pārejiet pie adresācijas cēloņa.
Atstāt apmaksātu drošības funkciju izslēgtu, lai tunelis turpinātu darboties, ir kompromiss, kas jāizdara apzināti un jāpieraksta. Ir vērts arī pajautāt, vai tunelim jābūt citā ierīcē, jo maršrutētājs, kuram viss jāinspicē, un maršrutētājs, kuram viss jāpārsūta, ir divi dažādi darbi.
Otrais cēlonis: LAN diapazons pārvietojās
Firmware atjauninājumi regulāri atgriež LAN adresi uz ražotāja noklusējumu, un dažiem maršrutētājiem ir skaidrs režīma slēdzis, kas izlemj, vai LAN saglabā privātu diapazonu vai manto to no augšupējās ierīces. Klients, kas gaida 192.168.8.x, var nonākt uz 10.64.0.x, un tad SSH sesija uz resursdatoru beidzas, lai gan tunelis ir pilnīgi vesels.
ipconfig /all
ip addr show
ip route get 192.168.8.20Izlasiet prefiksu un vārteju no nomojas pirms maršrutētāja lapas atvēršanas. Pirmās divas komandas parāda, ko klients patiešām saņēma, un trešā parāda, kuru saskarni klients izmantotu vietējai adresei, un tā atklājas atlikušais maršruts vai novecojis apakštīkls. Pēc tam salīdziniet to ar LAN lapu un režīmu, kurā atrodas maršrutētājs.
Ja diapazons nevar atgriezties, atjauniniet katru objektu, kas to nosauc: DHCP rezervācijas, jebkuru statisko maršrutu uz veco apakštīklu un katru ugunsmūra noteikumu, kas nes iepriekšējo prefiksu. Diapazons, kas saduras ar tuneļa attālo apakštīklu, ir sliktākais variants, jo vietējās ierīces paliek sasniedzamas, kamēr attālie galamērķi klusi tiek maršrutēti uz LAN.
Piesakieties no jauna un pārbaudiet vēlreiz pakešu secībā
Pēc jebkuras no divām izmaiņām no jauna pievienojiet tuneli un atkārtojiet testus pakešu secībā: maršrutētājs, vietējais resursdators, attālais resursdators, tad nosaukumi, tad lietojumprogramma. Lietojumprogrammas pārbaude vispirms slēpj, kurš slānis vēl ir bojāts, un pārlūka atkārtotais mēģinājums ar kešatmiņā saglabātu nosaukumu var izskatīties kā maršrutēšanas kļūme.
Pierakstiet firmware versiju, LAN prefiksu un inspicēšanas funkcijas stāvokli blakus VPN profilam. Visi trīs ir konfigurācija, ko nākamais atjauninājums var pārrakstīt, un divas rindas piezīmju ietaupa tikko pavadīto stundu.