Ruter i VPN-klientmodus: hvorfor LAN-enheter forsvinner

Troen på at klientmodusen i seg selv dreper LAN-tilgang, sender folk inn i feil innstillingsmeny, og de egentlige årsakene er vanligvis to. Tunnelen fjerner ikke LAN-broen og hindrer ikke kablede og trådløse klienter i å nå hverandre. Det som bryter lokal tilgang, er enten en inspeksjonsfunksjon i ruterens videresendingsvei eller et LAN-adresseområde som flyttet seg da fastvaren gjorde det. Begge gir samme klage, og ingen av dem løses ved å installere VPN-profilen på nytt.

Myten, og hva klientmodusen virkelig endrer

Klientmodusen legger til et tunellgrensesnitt og en standardrute som peker gjennom det, og videresender deretter LAN-trafikk inn i den tunnelen. Broen mellom de kablede portene og de trådløse radioene er urørt, og det samme er lokal svitsjing. Det som endres, er policy: hvilken trafikk som videresendes, hvor den oversettes og hvilken resolver klientene får.

Den forskjellen betyr noe fordi et ødelagt LAN vanligvis betyr at en av de tre policyene endret seg, ikke at ruteren sluttet å være en svitsj. En ruter som fortsatt svarer på sin egen administrasjonsside, er bevis på at LAN-grensesnittet lever. En ruter som ikke svarer i det hele tatt, har et annet problem, for eksempel en endret LAN-adresse eller en klient på feil subnett.

Så det nyttige første steget er å finne ut hvilket lag som ble brutt, ikke å endre laget du mistenker.

Test tre mål før du rører en innstilling

Fra en kablet klient tester du tre mål hver for seg og skriver ned hvert resultat: ruterens egen LAN-adresse, en annen enhet på samme svitsj etter IP, og noe som bare er tilgjengelig gjennom tunnelen. Gjør det i den rekkefølgen, fordi hvert resultat utelukker et forskjellig lag. Bruk adresser i stedet for navn i første runde, siden en navnefeil blander DNS inn i et tilkoblingsspørsmål.

Mønsteret i svarene er diagnosen. En ruter som svarer mens lokale enheter ikke gjør det, peker på lokal svitsjing eller en filtreringsfunksjon snarere enn ruting. Lokale enheter som svarer mens tunnelsiden ikke gjør det, peker på tunellruten eller den eksterne brannmuren. Alt svarer på adresse mens navn feiler, er et resolver-spørsmål, og ingen ruteendring vil rette det.

Hold tabellen ved siden av testresultatene. Den gjør en vag klage om til én linje du kan handle på.

Sikkerhetslaget inne i videresendingsveien

Forbrukerrutere leveres stadig oftere med en inspeksjonsfunksjon som overvåker videresendt trafikk, og den kjører i samme vei som bærer pakker fra LAN til tunnelen. Når den inspeksjonen ikke kan klassifisere tunelltrafikken, kan videresendingen stoppe mens selve tunnelen blir stående og ruteren rapporterer en sunn tilkobling. Ingenting i VPN-loggen viser dette, fordi VPN-en faktisk koblet til.

Diagnosen er et kontrollert eksperiment, ikke en permanent endring. Noter den gjeldende innstillingen, slå av funksjonen i løpet av én test, hent tunnelen opp igjen og test én lokal vert etter adresse. Videresendingen som kommer tilbake, er beviset du trengte, og avveiningen blir da en beslutning i stedet for en gjetning. Hvis ingenting endres, slår du den på igjen med en gang og går videre til adresseringsårsaken.

Å la en betalt sikkerhetsfunksjon være avslått slik at en tunell fortsetter å virke, er en avveining som må gjøres bevisst og skrives ned. Det er også verdt å spørre om tunnelen hører hjemme på en annen enhet, fordi en ruter som må inspisere alt, og en ruter som må videresende alt, er to forskjellige jobber.

Den andre årsaken: LAN-området flyttet seg

Fastvareoppdateringer tilbakestiller rutinemessig LAN-adressen til produsentens standardverdi, og noen rutere har en eksplisitt modusbryter som avgjør om LAN beholder et privat område eller arver ett fra enheten ovenfor. En klient som forventer 192.168.8.x, kan ende på 10.64.0.x, og da utløper en SSH-økt til en vert selv om tunnelen er helt sunn.

ipconfig /all
ip addr show
ip route get 192.168.8.20

Les prefikset og gatewayen fra leien før du åpner ruterenes side. De to første kommandoene viser hva klienten faktisk mottok, og den tredje viser hvilket grensesnitt klienten ville brukt for en lokal adresse, og slik avslører en gjenværende rute eller et utdatert subnett seg. Sammenlign deretter med LAN-siden og modusen ruteren er i.

Hvis området ikke kan gå tilbake, oppdaterer du hvert objekt som navngir det: DHCP-reservasjoner, enhver statisk rute inn i det gamle subnettet og hver brannmurregel som bærer det forrige prefikset. Et område som kolliderer med tunellens eksterne subnett, er den verre varianten, fordi lokale enheter forblir tilgjengelige mens eksterne destinasjoner stille sendes feil inn i LAN-et.

Koble til på nytt og test på nytt i pakkerekkefølge

Etter en av de to endringene kobler du til tunnelen på nytt og gjentar testene i pakkerekkefølge: ruter, lokal vert, ekstern vert, deretter navn, deretter applikasjonen. Å teste applikasjonen først skjuler hvilket lag som fortsatt er brutt, og et nytt forsøk i nettleseren mot et bufret navn kan se ut som en rutingfeil.

Noter fastvareversjonen, LAN-prefikset og tilstanden til inspeksjonsfunksjonen ved siden av VPN-profilen. Alle tre er konfigurasjon som den neste oppdateringen kan overskrive, og to linjer med notater sparer timen du nettopp brukte.