Router i VPN-klientläge: varför LAN-enheter försvinner

Tron att klientläget i sig dödar LAN-åtkomst leder människor in i fel inställningsmeny, och de verkliga orsakerna är oftast två. Tunneln tar inte bort LAN-bron och hindrar inte trådbundna och trådlösa klienter från att nå varandra. Det som bryter lokal åtkomst är antingen en inspektionsfunktion i routerns vidarebefordringsväg eller ett LAN-adressintervall som flyttades när firmware gjorde det. Båda ger samma klagomål, och inget av dem åtgärdas genom att installera om VPN-profilen.

Myten, och vad klientläget verkligen ändrar

Klientläget lägger till ett tunnelgränssnitt och en standardrutt som pekar genom det, och vidarebefordrar sedan LAN-trafik in i den tunneln. Bron mellan de trådbundna portarna och de trådlösa radioenheterna är orörd, liksom den lokala växlingen. Det som ändras är policy: vilken trafik som vidarebefordras, var den översätts och vilken resolver klienterna får.

Den skillnaden spelar roll eftersom ett trasigt LAN oftast betyder att en av de tre policyerna ändrades, inte att routern slutade vara en switch. En router som fortfarande svarar på sin egen administrationssida är bevis på att LAN-gränssnittet lever. En router som inte svarar alls har ett annat problem, som en ändrad LAN-adress eller en klient på fel subnät.

Så det användbara första steget är att ta reda på vilket lager som gick sönder, inte att ändra lagret du misstänker.

Testa tre mål innan du rör en inställning

Från en trådbunden klient testar du tre mål separat och skriver ner varje resultat: routerns egen LAN-adress, en annan enhet på samma switch via IP och något som bara nås genom tunneln. Gör dem i den ordningen, eftersom varje resultat utesluter ett annat lager. Använd adresser i stället för namn i första omgången, eftersom ett namnförsök blandar in DNS i en anslutningsfråga.

Mönstret av svar är diagnosen. En router som svarar medan lokala enheter inte gör det pekar på lokal växling eller en filtreringsfunktion snarare än routning. Lokala enheter som svarar medan tunnelsidan inte gör det pekar på tunnelrutten eller den externa brandväggen. Om allt svarar på adress men namn misslyckas är det en resolverfråga, och ingen ruttredigering kommer att fixa det.

Håll tabellen bredvid testresultaten. Den förvandlar ett vagt klagomål till en rad du kan agera på.

Säkerhetslagret inne i vidarebefordringsvägen

Konsumentroutrar levereras allt oftare med en inspektionsfunktion som övervakar vidarebefordrad trafik, och den körs i samma väg som bär paket från LAN till tunneln. När den inspektionen inte kan klassificera tunneltrafiken kan vidarebefordringen stanna medan själva tunneln står kvar och routern rapporterar en frisk anslutning. Inget i VPN-loggen visar detta, eftersom VPN faktiskt anslöt.

Diagnosen är ett kontrollerat experiment, inte en permanent ändring. Notera den aktuella inställningen, stäng av funktionen under ett test, ta upp tunneln igen och testa en enda lokal värd via adress. Vidarebefordringen som kommer tillbaka är beviset du behövde, och avvägningen blir då ett beslut i stället för en gissning. Om inget ändras, slå på den igen direkt och gå vidare till adresseringsorsaken.

Att lämna en betald säkerhetsfunktion avstängd så att en tunnel fortsätter fungera är en avvägning som måste göras medvetet och skrivas ner. Det är också värt att fråga om tunneln hör hemma på en annan enhet, eftersom en router som måste inspektera allt och en router som måste vidarebefordra allt är två olika jobb.

Den andra orsaken: LAN-intervallet flyttades

Firmwareuppdateringar återställer rutinmässigt LAN-adressen till tillverkarens standard, och vissa routrar har en uttrycklig lägesbrytare som avgör om LAN behåller ett privat intervall eller ärver ett från enheten ovanför. En klient som förväntar sig 192.168.8.x kan hamna på 10.64.0.x, och då löper en SSH-session till en värd ut trots att tunneln är helt frisk.

ipconfig /all
ip addr show
ip route get 192.168.8.20

Läs prefixet och gatewayen från leasen innan du öppnar routersidan. De två första kommandona visar vad klienten faktiskt fick, och det tredje visar vilket gränssnitt klienten skulle använda för en lokal adress, och det är så en kvarvarande rutt eller ett inaktuellt subnät avslöjar sig. Jämför sedan med LAN-sidan och läget routern är i.

Om intervallet inte kan gå tillbaka, uppdatera varje objekt som namnger det: DHCP-reservationer, varje statisk rutt in i det gamla subnätet och varje brandväggsregel som bär det tidigare prefixet. Ett intervall som kolliderar med tunnelns externa subnät är den värre varianten, eftersom lokala enheter förblir nåbara medan externa destinationer tyst dirigeras fel in i LAN.

Anslut igen och testa igen i paketordning

Efter någon av de två ändringarna ansluter du tunneln igen och upprepar testerna i paketordning: router, lokal värd, extern värd, sedan namn, sedan programmet. Att testa programmet först döljer vilket lager som fortfarande är trasigt, och ett nytt försök i webbläsaren mot ett cachelagrat namn kan se ut som ett routningsfel.

Notera firmwareversionen, LAN-prefixet och inspektionsfunktionens tillstånd bredvid VPN-profilen. Alla tre är konfiguration som nästa uppdatering kan skriva över, och två rader anteckningar sparar timmen du just tillbringade.