Router në modalitetin klient VPN: pse zhduken pajisjet LAN
Pajisjet LAN zhduken pasi routeri kalon në modalitetin klient VPN: provoni së pari funksionin e inspektimit në rrugën e përcjelljes, pastaj intervalin LAN që firmware-i ndryshoi nën ju.
Besimi se vetë modaliteti klient vret aksesin në LAN i çon njerëzit në menunë e gabuar të cilësimeve, dhe shkaqet e vërteta zakonisht janë dy. Tuneli nuk e heq urën LAN dhe nuk i pengon klientët me tela dhe pa tela të arrijnë njëri-tjetrin. Ajo që thyen aksesin lokal është ose një funksion inspektimi në rrugën e përcjelljes së routerit ose një interval adresash LAN që u zhvendos kur firmware-i e bëri atë. Të dyja prodhojnë të njëjtën ankesë, dhe asnjëra nuk rregullohet duke reinstaluar profilin VPN.
Miti dhe çfarë ndryshon vërtet modaliteti klient
Modaliteti klient shton një ndërfaqe tuneli dhe një rrugë të parazgjedhur që kalon nëpër të, dhe më pas përcjell trafikun LAN në atë tunel. Ura midis porteve me tela dhe radiove pa tela mbetet e paprekur, si dhe komutimi lokal. Ajo që ndryshon është politika: cili trafik përcillet, ku përkthehet dhe cilin zgjidhës marrin klientët.
Ky dallim ka rëndësi sepse një LAN i prishur zakonisht do të thotë që një nga ato tre politika ndryshoi, jo se routeri pushoi së qeni një switç. Një router që ende përgjigjet në faqen e vet të administrimit është provë që ndërfaqja LAN është gjallë. Një router që nuk përgjigjet fare ka një problem tjetër, si një adresë LAN e ndryshuar ose një klient në nënrrjetin e gabuar.
Pra hapi i parë i dobishëm është të zbuloni cila shtresë u thye, jo të ndryshoni shtresën që dyshoni.
Provoni tre objektiva para se të prekni një cilësim
Nga një klient me tela, provoni tre objektiva veçmas dhe shkruani çdo rezultat: adresën LAN të vetë routerit, një pajisje tjetër në të njëjtin switç sipas IP-së, dhe diçka që arrihet vetëm përmes tunelit. Bëjini në atë rend, sepse çdo rezultat përjashton një shtresë tjetër. Në raundin e parë përdorni adresa në vend të emrave, pasi dështimi i emrit përzien DNS-në në një çështje lidhshmërie.
Modeli i përgjigjeve është diagnoza. Një router që përgjigjet ndërsa pajisjet lokale nuk përgjigjen tregon komutim lokal ose një funksion filtrimi, jo routing. Pajisjet lokale që përgjigjen ndërsa ana e tunelit nuk përgjigjet tregojnë rrugën e tunelit ose firewall-in e largët. Nëse gjithçka përgjigjet sipas adresës por emrat dështojnë, është çështje zgjidhësi, dhe asnjë redaktim i rrugëve nuk e rregullon.
| 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 |
Mbajeni tabelën pranë rezultateve të testit. Ajo e kthen një ankesë të paqartë në një rresht mbi të cilin mund të veproni.
Shtresa e sigurisë brenda rrugës së përcjelljes
Routerët e konsumatorit vijnë gjithnjë e më shpesh me një funksion inspektimi që mbikëqyr trafikun e përcjellë, dhe ai punon në të njëjtën rrugë që mbart paketat nga LAN në tunel. Kur ai inspektim nuk mund ta klasifikojë trafikun e tunelit, përcjellja mund të ngecë ndërsa vetë tuneli mbetet aktiv dhe routeri raporton një lidhje të shëndetshme. Asgjë në regjistrin VPN nuk e tregon këtë, sepse VPN-ja vërtet u lidh.
Diagnoza është një eksperiment i kontrolluar, jo një ndryshim i përhershëm. Shënoni cilësimin aktual, fikni funksionin për kohëzgjatjen e një testi, ngrijeni përsëri tunelin dhe provoni një host lokal sipas adresës. Përcjellja që kthehet është prova që ju nevojitej, dhe kompromisi atëherë bëhet vendim në vend të hamendjes. Nëse asgjë nuk ndryshon, riaktivizojeni menjëherë dhe kaloni te shkaku i adresimit.
Të lësh një funksion sigurie me pagesë të fikur që tuneli të vazhdojë të punojë është një kompromis që duhet bërë me qëllim dhe duhet shkruar. Vlen gjithashtu të pyesni nëse tuneli duhet të jetë në një pajisje tjetër, sepse një router që duhet të inspektojë gjithçka dhe një router që duhet të përcjellë gjithçka janë dy punë të ndryshme.
Shkaku i dytë: intervali LAN u zhvendos
Përditësimet e firmware-it zakonisht e kthejnë adresën LAN në vlerën e parazgjedhur të prodhuesit, dhe disa routerë kanë një çelës modaliteti të qartë që vendos nëse LAN mban një interval privat ose trashëgon një nga pajisja sipër. Një klient që pret 192.168.8.x mund të përfundojë në 10.64.0.x, dhe atëherë një sesion SSH drejt një hosti skadon edhe pse tuneli është plotësisht i shëndetshëm.
ipconfig /all
ip addr show
ip route get 192.168.8.20
Lexoni prefiksin dhe portën e hyrjes nga qiraja para se të hapni faqen e routerit. Dy komandat e para tregojnë çfarë mori vërtet klienti, dhe e treta tregon cilën ndërfaqe do të përdorte klienti për një adresë lokale, dhe kështu zbulohet një rrugë e mbetur ose një nënrrjet i vjetëruar. Pastaj krahasojeni me faqen LAN dhe modalitetin në të cilin ndodhet routeri.
Nëse intervali nuk mund të kthehet, përditësoni çdo objekt që e emërton: rezervime DHCP, çdo rrugë statike në nënrrjetin e vjetër dhe çdo rregull firewall që mban prefiksin e mëparshëm. Një interval që përplaset me nënrrjetin e largët të tunelit është varianti më i keq, sepse pajisjet lokale mbeten të arritshme ndërsa destinacionet e largëta drejtohen në heshtje gabimisht në LAN.
Rilidhuni dhe ritestoni sipas rendit të paketave
Pas njërit prej dy ndryshimeve, rilidhni tunelin dhe përsëritni testet sipas rendit të paketave: router, host lokal, host i largët, pastaj emrat, pastaj aplikacioni. Testimi i aplikacionit së pari fsheh cilën shtresë është ende e prishur, dhe një përpjekje e re e shfletuesit ndaj një emri të ruajtur në cache mund të duket si dështim routing-u.
Shënoni versionin e firmware-it, prefiksin LAN dhe gjendjen e funksionit të inspektimit pranë profilit VPN. Të trejanë konfigurim që përditësimi i radhës mund ta mbishkruajë, dhe dy rreshta shënimesh kursejnë orën që sapo kaluat.