Waarom 'n voltonnel-VPN jou geroteerde plaaslike VLAN's wegsteek

Die skakelaar “allow local network” in 'n VPN-kliënt klink asof dit alles in die gebou dek. In die praktyk voeg dit gewoonlik net 'n paar uitsonderings vir private adresse by die tonnel se standaardroete en stop daar. Jou stoors-VLAN bly slegs bereikbaar as 'n roete vir daardie spesifieke voorvoegsel die aankoms van die tonnel oorleef, en by baie kliënte gebeur dit nie.

Dit is 'n routeringsvraag eerder as 'n VPN-instelling, en dit is goeie nuus: dit het 'n konkrete antwoord.

Wat allow-local-network werklik dek

Kliënte implementeer daardie opsie verskillend. Sommige voeg roetes by vir die subnet waaraan die masjien gekoppel is, sommige voeg die RFC 1918-reekse by, en 'n paar sluit net die standaard-gateway uit. Nie een van hulle weet dat jou kantoorrouter ook 'n stoors-VLAN, 'n lab-segment of 'n drukker-subnet bedien nie, want daardie voorvoegsels is nie op die draad wat die kliënt kan sien nie. Lees die kliënt se eie dokumentasie vir die presiese gedrag in plaas daarvan om te aanvaar dat die etiket jou topologie beskryf.

Die onderskeid maak die meeste saak in 'n voltonnel-ontwerp, waar die kliënt doelbewus die standaardroete vervang sodat alle verkeer deur die VPN gaan. Dit is die ontwerp se hele punt, en dit is ook wat die plaaslike geroteerde netwerke laat verdwyn. Hulle was nooit deur 'n eie roete gedek nie; hulle het op die standaardroete gery wat pas vervang is. 'n Kliënt kan nie roete wat hy nie weet bestaan nie, en hy leer net van voorvoegsels wat aan sy eie koppelvlak gekoppel is. Alles anders moet deur iemand beskryf word wat die topologie ken.

Gekoppelde roetes stop by die eerste router

'n Werkstasie op 192.168.10.20/24 met gateway 192.168.10.1 kry outomaties 'n gekoppelde roete vir 192.168.10.0/24. Die stoors-VLAN op 192.168.20.0/24 is 'n ander voorvoegsel, bereikbaar net deur daardie gateway, en die werkstasie het geen roete daarvoor buite die standaard nie. Voordat die tonnel opkom, stuur die gewone standaard toevallig stoorsverkeer na 192.168.10.1 en alles werk.

Wanneer die VPN 'n voltonnel-standaard installeer, volg pakkette vir 192.168.20.1 die nuwe standaard in die tonnel in. Die afgeleë gateway het geen idee waar daardie voorvoegsel woon nie, so dit laat val hulle of stuur hulle na 'n nuttelose plek. Niks was verkeerd opgestel op die stoors-VLAN nie; sy pad was geleen, en die lening is opgeroep.

Die versoeking is om na 'n breë uitsondering te gryp, soos 'n /1-roetepaar of 'n tweede standaardroete. Weerstaan dit. Hoe nouer die uitsondering, hoe makliker is dit om te verduidelik, te ouditeer en te verwyder wanneer die netwerk verander.

Sit die uitsondering in die tabel wat wen

Binne een routeringstabel klop 'n /24 'n /0 of 'n /1 deur die langste-voorvoegsel-passing, so 'n spesifieke roete na die stoors-VLAN deur die plaaslike gateway is genoeg, mits die tabel hoegenaamd geraadpleeg word. Op Linux is die gewone vorm kort:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

Beleidsroutering bemoeilik daardie waarborg. 'n Vroeër reël kan verkeer na 'n tabel stuur waarvan die eie standaardroete in die tonnel wys, en die hoof-tabel met jou /24 word dan nooit bereik nie. Kyk na die reëls voordat jy aanvaar die roete is gesaghebbend, want 'n korrek-lykende inskrywing in die verkeerde tabel verduidelik 'n fout wat soos 'n stukkende roete lyk.

Maak dan die inskrywing blywend deur die kliënt se ondersteunde meganisme of die netwerkbestuurder wat die koppelvlak besit. 'n Roete wat by die opdragprompt getik is, verdwyn by die volgende herverbinding, en 'n roete wat aan een Wi-Fi-gateway gebind is, is nie oordraagbaar na die volgende netwerk wat die skootrekenaar besoek nie.

Name en beleid volg nie roetes nie

Die regmaak van die roete herstel pakkette, nie name nie. As plaaslike toestelle deur 'n gestuurde oplosser opgelos word wat niks van hulle weet nie, misluk die montering steeds, selfs al is die adres bereikbaar. Plaaslike name het 'n plaaslike of gesplete DNS-reëling nodig, en dit is 'n aparte besluit van die roete-uitsondering.

Beleid is weer apart. 'n VPN-kliënt se plaaslike-toegangfilter kan opsetlik verkeer na private reekse verbied, en 'n roete oorskryf nie daardie reël nie. Op 'n onvertroude netwerk is 'n private adres ook nie bewys dat die bestemming jou stoorbediener is nie, so die uitsondering moet so spesifiek soos die roete self wees.

'n Kontrak wat jy kan oorhandig

Die voltooide ontwerp moet as 'n kort lys lees: algemene internetverkeer volg die tonnel, en hierdie genoemde plaaslike voorvoegsels behou hul pad deur die plaaslike router. Skryf die voorvoegsels, die volgende hop en die DNS-agtervoegsel wat daarmee saamgaan neer, en hou die lys kort genoeg dat iemand dit kan verifieer sonder om 'n routeringstabel te lees.

Pas op vir oorvleueling tussen plaaslike en afgeleë reekse. 'n Stoors-VLAN wat 'n voorvoegsel met iets agter die VPN deel, sal na die meer spesifieke roete oplos, en die gevolglike gedrag is verwarrend op 'n manier wat wisselvallig lyk. Om een kant te hernommer is gewoonlik goedkoper as om die onduidelikheid vir ewig te ontfout.

Toets die kontrak twee keer: een keer met die tonnel op en een keer met dit af. As die plaaslike pad net in een van daardie toestande werk, is die uitsondering nog nie 'n kontrak nie.