Ruter i VPN-klientmodus: kvifor LAN-einingar forsvinn

Trua på at klientmodusen i seg sjølv drep LAN-tilgang, sendar folk inn i feil innstillingsmeny, og dei eigentlege årsakene er vanlegvis to. Tunnelen fjernar ikkje LAN-brua og hindrar ikkje kabel- og trådlause klientar i å nå kvarandre. Det som bryt lokal tilgang, er anten ein inspeksjonsfunksjon i videresendingsvegen til ruteren eller eit LAN-adresseområde som flytta seg då fastvaren gjorde det. Begge gir same klage, og ingen av dei blir løyste ved å installere VPN-profilen på nytt.

Myten, og kva klientmodusen verkeleg endrar

Klientmodusen legg til eit tunellgrensesnitt og ei standardrute som peikar gjennom det, og videresendar deretter LAN-trafikk inn i den tunellen. Brua mellom dei kabelbundne portane og dei trådlause radioane er urørt, og det same er lokal svitsjing. Det som endrar seg, er policy: kva trafikk som blir videresend, kvar han blir omsett og kva resolver klientane får.

Den skilnaden betyr noko fordi eit øydelagt LAN vanlegvis betyr at ein av dei tre policyane endra seg, ikkje at ruteren slutta å vere ein svitsj. Ein ruter som framleis svarar på si eiga administrasjonsside, er prov på at LAN-grensesnittet lever. Ein ruter som ikkje svarar i det heile, har eit anna problem, til dømes ei endra LAN-adresse eller ein klient på feil subnett.

Så det nyttige første steget er å finne ut kva lag som vart brote, ikkje å endre laget du mistenkjer.

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

Få ein kabelbunden klient testar du tre mål kvar for seg og skriv ned kvar resultat: rutaren si eiga LAN-adresse, ei anna eining på same svitsj etter IP, og noko som berre er tilgjengeleg gjennom tunellen. Gjer det i den rekkjefølgja, fordi kvart resultat utelukkar eit ulikt lag. Bruk adresser i staden for namn i første runde, sidan ein namnefeil blandar DNS inn i eit tilkoplingsspørsmål.

Mønsteret i svara er diagnosen. Ein ruter som svarar medan lokale einingar ikkje gjer det, peikar på lokal svitsjing eller ein filtreringsfunksjon snarare enn ruting. Lokale einingar som svarar medan tunellsida ikkje gjer det, peikar på tunellruta eller den eksterne brannmuren. Alt svarar på adresse medan namn feilar, er eit resolver-spørsmål, og inga ruteendring vil rette det.

Hald tabellen ved sida av testresultata. Han gjer ei vag klage om til éi linje du kan handle på.

Tryggleikslaget inne i videresendingsvegen

Forbrukarrutarar blir stadig oftare leverte med ein inspeksjonsfunksjon som overvakar videresend trafikk, og han køyrer i same veg som ber pakkar frå LAN til tunellen. Når den inspeksjonen ikkje kan klassifisere tunelltrafikken, kan videresendinga stoppe medan sjølve tunellen blir ståande og ruteren rapporterer ei sunn tilkopling. Ingenting i VPN-loggen viser dette, fordi VPN-en faktisk kopla til.

Diagnosen er eit kontrollert eksperiment, ikkje ei permanent endring. Noter den gjeldande innstillinga, slå av funksjonen i løpet av éin test, hent tunellen opp igjen og test éin lokal vert etter adresse. Videresendinga som kjem tilbake, er provet du trong, og avveginga blir då ei avgjerd i staden for ei gissing. Viss ingenting endrar seg, slår du han på igjen med ein gong og går vidare til adresseringsårsaka.

Å la ein betalt tryggleiksfunksjon vere avslått slik at ein tunell held fram med å verke, er ei avveging som må gjerast medvite og skrivast ned. Det er også verdt å spørje om tunellen høyrer heime på ei anna eining, fordi ein ruter som må inspisere alt, og ein ruter som må videresende alt, er to ulike jobbar.

Den andre årsaka: LAN-området flytta seg

Fastvareoppdateringar tilbakestiller rutinemessig LAN-adressa til standardverdien til produsenten, og nokre rutarar har ein eksplisitt modusbrytar som avgjer om LAN held på eit privat område eller arvar eitt frå eininga ovanfor. Ein klient som ventar 192.168.8.x, kan hamne på 10.64.0.x, og då går ein SSH-økt til ein vert ut sjølv om tunellen er heilt sunn.

ipconfig /all
ip addr show
ip route get 192.168.8.20

Les prefikset og gatewayen frå leiga før du opnar rutarsida. Dei to første kommandoane viser kva klienten faktisk fekk, og den tredje viser kva grensesnitt klienten ville bruke for ei lokal adresse, og slik avslører ei attverande rute eller eit utdatert subnett seg. Samanlikn deretter med LAN-sida og modusen ruteren er i.

Viss området ikkje kan gå tilbake, oppdaterer du kvart objekt som namngir det: DHCP-reservasjonar, kvar statisk rute inn i det gamle subnettet og kvar brannmurregel som ber det førre prefikset. Eit område som kolliderer med det eksterne subnettet til tunellen, er den verre varianten, fordi lokale einingar blir tilgjengelege medan eksterne mål stille blir sende feil inn i LAN-et.

Kopla til på nytt og test på nytt i pakkerekkjefølgje

Etter ei av dei to endringane koplar du til tunellen på nytt og gjer testane om att i pakkerekkjefølgje: ruter, lokal vert, ekstern vert, deretter namn, deretter applikasjonen. Å teste applikasjonen først skjuler kva lag som framleis er brote, og eit nytt forsøk i nettlesaren mot eit buftra namn kan sjå ut som ein rutefeil.

Noter fastvareversjonen, LAN-prefikset og tilstanden til inspeksjonsfunksjonen ved sida av VPN-profilen. Alle tre er konfigurasjon som den neste oppdateringa kan skrive over, og to linjer med notat sparar timen du nettopp brukte.