Varför en fulltunnel-VPN döljer dina routade lokala VLAN

Brytaren ”tillåt lokalt nätverk” i en VPN-klient låter som att den täcker allt i byggnaden. I praktiken lägger den oftast till några undantag för privata adresser i tunnelns standardrutt och stannar där. Ditt lagrings-VLAN är fortfarande nåbart bara om en rutt för just det prefixet överlever att tunneln kommer upp, och hos många klienter gör den inte det.

Det är en routingfråga snarare än en VPN-inställning, vilket är goda nyheter: den har ett konkret svar.

Vad tillåt-lokalt-nätverk faktiskt täcker

Klienter implementerar det alternativet olika. Några lägger till rutter för subnätet som maskinen sitter på, några lägger till RFC 1918-intervallen, och ett fåtal utesluter bara standardgatewayen. Ingen av dem vet att din kontorsrouter också betjänar ett lagrings-VLAN, ett labbsegment eller ett skrivarsubnät, eftersom de prefixen inte finns på den länk klienten kan se. Läs klientens egen dokumentation för det exakta beteendet i stället för att anta att etiketten beskriver din topologi.

Skillnaden spelar störst roll i en fulltunneldesign, där klienten medvetet ersätter standardrutten så att all trafik går genom VPN:en. Det är hela poängen med designen, och det är också det som får de lokalt routade näten att försvinna. De täcktes aldrig av en egen rutt; de åkte med på standardrutten som just har ersatts. En klient kan inte routa det den inte vet finns, och den lär sig bara om prefix som hör till dess eget gränssnitt. Allt annat måste beskrivas av någon som känner topologin.

Anslutna rutter stannar vid första routern

En arbetsstation på 192.168.10.20/24 med gateway 192.168.10.1 får automatiskt en ansluten rutt för 192.168.10.0/24. Lagrings-VLAN:et på 192.168.20.0/24 är ett annat prefix, nåbart bara via den gatewayen, och arbetsstationen har ingen rutt för det utöver standardrutten. Innan tunneln kommer upp råkar standardrutten skicka lagringstrafiken till 192.168.10.1 och allt fungerar.

När VPN:en installerar en fulltunnelstandard följer paket för 192.168.20.1 den nya standardrutten in i tunneln. Fjärrgatewayen har ingen aning om var det prefixet bor, så den släpper dem eller vidarebefordrar dem någonstans meningslöst. Inget var felkonfigurerat på lagrings-VLAN:et; dess väg var lånad, och lånet sades upp.

Frestelsen är att ta till ett brett undantag, som ett /1-ruttpar eller en andra standardrutt. Motstå den. Ju snävare undantaget är, desto lättare är det att förklara, granska och ta bort när nätet förändras.

Lägg undantaget i tabellen som vinner

Inom en routingtabell slår ett /24 ett /0 eller ett /1 genom längsta prefixmatchning, så en specifik rutt till lagrings-VLAN:et via den lokala gatewayen räcker, förutsatt att tabellen alls konsulteras. På Linux är den vanliga formen kort:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

Policyrouting komplicerar den garantin. En tidigare regel kan skicka trafik till en tabell vars egen standardrutt pekar in i tunneln, och huvudtabellen som håller ditt /24 nås då aldrig. Kontrollera reglerna innan du antar att rutten är auktoritativ, för en korrekt utseende post i fel tabell förklarar ett fel som ser ut som en trasig rutt.

Gör sedan posten beständig via klientens mekanism eller den nätverkshanterare som äger gränssnittet. En rutt som skrivs i prompten försvinner vid nästa återanslutning, och en rutt knuten till en enda Wi-Fi-gateway går inte att flytta med till nästa nät som laptopen besöker.

Namn och policy följer inte rutter

Att fixa rutten återställer paket, inte namn. Om lokala enheter slås upp via en pushad resolver som inte vet något om dem, misslyckas monteringen ändå även om adressen är nåbar. Lokala namn kräver en lokal lösning eller delad DNS, och det är ett separat beslut från ruttundantaget.

Policyn är återigen separat. En VPN-klients lokala åtkomstfilter kan medvetet förbjuda trafik till privata intervall, och en rutt åsidosätter inte den regeln. I ett otillförlitligt nät är en privat adress inte heller bevis på att målet är din lagringsserver, så undantaget bör vara lika specifikt som rutten själv.

Ett kontrakt du kan lämna över

Den färdiga designen bör läsas som en kort lista: allmän internettrafik följer tunneln, och dessa namngivna lokala prefix behåller sin väg via den lokala routern. Skriv ner prefixen, nästa hopp och DNS-suffixet som hör till dem, och håll listan så kort att någon kan verifiera den utan att läsa en routingtabell.

Se upp för överlapp mellan lokala och avlägsna intervall. Ett lagrings-VLAN som delar prefix med något bakom VPN:en löses till den rutt som är mer specifik, och det resulterande beteendet är förvirrande på ett sätt som ser intermittent ut. Att numrera om en sida är oftast billigare än att felsöka oklarheten för evigt.

Testa kontraktet två gånger: en gång med tunneln uppe och en gång med den nere. Om den lokala vägen bara fungerar i ett av dessa lägen är undantaget ännu inte ett kontrakt.