Router i VPN-klienttilstand: hvorfor LAN-enheder forsvinder

Troen på, at klienttilstanden i sig selv dræber LAN-adgang, sender folk ind i den forkerte indstillingsmenu, og de egentlige årsager er normalt to. Tunnelen fjerner ikke LAN-broen og forhindrer ikke kablede og trådløse klienter i at nå hinanden. Det, der bryder lokal adgang, er enten en inspektionsfunktion i routerens videresendelsesvej eller et LAN-adresseinterval, der flyttede sig, da firmwaren gjorde det. Begge giver samme klage, og ingen af dem løses ved at geninstallere VPN-profilen.

Myten, og hvad klienttilstanden virkelig ændrer

Klienttilstand tilføjer en tunnelgrænseflade og en standardrute, der peger gennem den, og videresender derefter LAN-trafik ind i den tunnel. Broen mellem de kablede porte og de trådløse radioer er urørt, og det samme er lokal switching. Det, der ændres, er politik: hvilken trafik der videresendes, hvor den oversættes, og hvilken resolver klienterne får.

Den forskel betyder noget, fordi et brudt LAN normalt betyder, at en af de tre politikker ændrede sig, ikke at routeren holdt op med at være en switch. En router, der stadig svarer på sin egen administrationsside, er bevis på, at LAN-grænsefladen er i live. En router, der slet ikke svarer, har et andet problem, såsom en ændret LAN-adresse eller en klient på det forkerte subnet.

Så det nyttige første skridt er at finde ud af, hvilket lag der brød, ikke at ændre det lag, du mistænker.

Test tre mål, før du rører en indstilling

Fra en kablet klient testes tre mål hver for sig, og hvert resultat skrives ned: routerens egen LAN-adresse, en anden enhed på samme switch via IP og noget, der kun kan nås gennem tunnelen. Gør det i den rækkefølge, fordi hvert resultat udelukker et forskelligt lag. Brug adresser i stedet for navne i første runde, da en navnefejl blander DNS ind i et forbindelsesspørgsmål.

Mønstret af svar er diagnosen. En router, der svarer, mens lokale enheder ikke gør, peger på lokal switching eller en filtreringsfunktion snarere end routing. Lokale enheder, der svarer, mens tunnelsiden ikke gør, peger på tunnelruten eller den eksterne firewall. Alt, der svarer på adresse, mens navne fejler, er et resolver-spørgsmål, og ingen mængde ruterredigering vil rette det.

Hold tabellen ved siden af testresultaterne. Den gør en vag klage til én linje, du kan handle på.

Sikkerhedslaget inde i videresendelsesvejen

Forbrugerroutere leveres i stigende grad med en inspektionsfunktion, der overvåger videresendt trafik, og den kører i samme vej, som bærer pakker fra LAN til tunnel. Når den inspektion ikke kan klassificere tunneltrafikken, kan videresendelsen gå i stå, mens selve tunnelen forbliver oppe, og routeren rapporterer en sund forbindelse. Intet i VPN-loggen viser dette, fordi VPN'en faktisk oprettede forbindelsen.

Diagnosen er et kontrolleret eksperiment, ikke en permanent ændring. Notér den aktuelle indstilling, slå funktionen fra i varigheden af én test, bring tunnelen op igen, og test en enkelt lokal vært via adresse. Videresendelse, der kommer tilbage, er det bevis, du havde brug for, og afvejningen bliver derefter en beslutning i stedet for et gæt. Hvis intet ændrer sig, skal du straks aktivere den igen og gå videre til adresseringsårsagen.

At lade en betalt sikkerhedsfunktion være deaktiveret, så en tunnel fortsætter med at virke, er en afvejning, der skal foretages bevidst og skrives ned. Det er også værd at spørge, om tunnelen hører på en anden enhed, fordi en router, der skal inspicere alt, og en router, der skal videresende alt, er to forskellige jobs.

Den anden årsag: LAN-intervallet flyttede sig

Firmwareopdateringer nulstiller rutinemæssigt LAN-adressen til producentens standard, og nogle routere har en eksplicit tilstandskontakt, der afgør, om LAN beholder et privat interval eller arver et fra enheden ovenfor. En klient, der forventer 192.168.8.x, kan ende på 10.64.0.x, og så udløber en SSH-session til en vært, selvom tunnelen er helt sund.

ipconfig /all
ip addr show
ip route get 192.168.8.20

Læs præfikset og gatewayen fra lejen, før du åbner routersiden. De første to kommandoer viser, hvad klienten faktisk modtog, og den tredje viser, hvilken grænseflade klienten ville bruge til en lokal adresse, og det er sådan en efterladt rute eller et forældet subnet afslører sig. Sammenlign derefter med LAN-siden og den tilstand, routeren er i.

Hvis intervallet ikke kan vende tilbage, skal du opdatere hvert objekt, der navngiver det: DHCP-reservationer, enhver statisk rute ind i det gamle subnet og hver firewallregel, der bærer det tidligere præfiks. Et interval, der støder sammen med tunnelens eksterne subnet, er den værre variant, fordi lokale enheder forbliver tilgængelige, mens eksterne destinationer stille sendes forkert ind i LAN'et.

Genopret forbindelsen, og test igen i pakkerækkefølge

Efter en af de to ændringer skal du genoprette tunnelen og gentage testene i pakkerækkefølge: router, lokal vært, ekstern vært, derefter navne, derefter applikationen. At teste applikationen først skjuler, hvilket lag der stadig er brudt, og en browser, der prøver igen mod et cachelagret navn, kan se ud som en routingfejl.

Notér firmwareversionen, LAN-præfikset og inspektionsfunktionens tilstand ved siden af VPN-profilen. Alle tre er konfiguration, som den næste opdatering kan overskrive, og to linjers noter sparer den time, du lige har brugt.