Miért rejti el egy teljes alagutas VPN az útvonalazott helyi VLAN-okat

Az „allow local network” kapcsoló egy VPN-kliensben úgy hangzik, mintha mindent lefedne az épületben. A gyakorlatban általában hozzáad néhány privátcím-kivételt az alagút alapértelmezett útvonalához, és ott megáll. A tároló VLAN csak akkor marad elérhető, ha az adott előtaghoz tartozó útvonal túléli az alagút megjelenését, és sok kliensben nem éli túl.

Ez útvonalválasztási kérdés, nem VPN-beállítás, ami jó hír: van rá konkrét válasz.

Mit fed le valójában az allow-local-network

A kliensek ezt a beállítást eltérően valósítják meg. Egyesek útvonalakat adnak ahhoz az alhálózathoz, amelyhez a gép csatlakozik, mások az RFC 1918 tartományokat adják hozzá, és néhányan csak az alapértelmezett átjárót zárják ki. Egyikük sem tudja, hogy az irodai router egy tároló VLAN-t, egy labor szegmenst vagy egy nyomtató alhálózatot is kiszolgál, mert ezek az előtagok nincsenek azon a kábelen, amelyet a kliens lát. Olvassa el a kliens saját dokumentációját a pontos viselkedésről, ahelyett hogy feltételezné, hogy a címke az ön topológiáját írja le.

A különbség a teljes alagutas kialakításban a legfontosabb, ahol a kliens szándékosan lecseréli az alapértelmezett útvonalat, hogy minden forgalom a VPN-en menjen át. Ez a kialakítás egész célja, és ez az is, amitől a helyi útvonalazott hálózatok eltűnnek. Soha nem fedte őket saját útvonal; az éppen lecserélt alapértelmezett útvonalon utaztak. A kliens nem tud olyat útvonalazni, amiről nem tudja, hogy létezik, és csak a saját interfészéhez kapcsolt előtagokat ismeri meg. Minden mást valakinek le kell írnia, aki ismeri a topológiát.

A csatlakoztatott útvonalak az első routernél megállnak

Az 192.168.10.20/24 címen lévő munkaállomás 192.168.10.1 átjáróval automatikusan csatlakoztatott útvonalat kap a 192.168.10.0/24 hálózathoz. Az 192.168.20.0/24 címen lévő tároló VLAN másik előtag, csak ezen az átjárón keresztül érhető el, és a munkaállomásnak nincs rá útvonala az alapértelmezetten kívül. Mielőtt az alagút feljön, a szokásos alapértelmezett útvonal véletlenül a 192.168.10.1 címre küldi a tárolóforgalmat, és minden működik.

Amikor a VPN telepít egy teljes alagutas alapértelmezett útvonalat, a 192.168.20.1 címre menő csomagok az új alapértelmezettet követve az alagútba mennek. A távoli átjárónak fogalma sincs, hol lakik ez az előtag, ezért eldobja őket, vagy valahová haszontalanul továbbítja. Semmi sem volt rosszul beállítva a tároló VLAN-on; az útja kölcsönzött volt, és a kölcsönt visszakérték.

A kísértés az, hogy széles kivételhez nyúljon, például egy /1 útvonalpárhoz vagy egy második alapértelmezett útvonalhoz. Ellenálljon. Minél szűkebb a kivétel, annál könnyebb megmagyarázni, ellenőrizni és eltávolítani, amikor a hálózat megváltozik.

Tegye a kivételt abba a táblába, amelyik nyer

Egy útvonalválasztási táblán belül a /24 a leghosszabb előtag-egyezés miatt legyőzi a /0 vagy /1 útvonalat, így egy konkrét útvonal a tároló VLAN-hoz a helyi átjárón keresztül elegendő, feltéve hogy a táblát egyáltalán megnézik. Linuxon a szokásos forma rövid:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

A szabályalapú útvonalválasztás bonyolítja ezt a garanciát. Egy korábbi szabály olyan táblába küldheti a forgalmat, amelynek saját alapértelmezett útvonala az alagútba mutat, és akkor a /24-et tartalmazó fő táblát soha nem érik el. Ellenőrizze a szabályokat, mielőtt az útvonalat mérvadónak tekinti, mert egy helyesnek látszó bejegyzés a rossz táblában olyan hibát magyaráz, amely törött útvonalnak látszik.

Ezután tegye a bejegyzést tartóssá a kliens által támogatott mechanizmussal vagy az interfészt birtokló hálózatkezelővel. A parancssorba írt útvonal eltűnik a következő újracsatlakozáskor, és az egyetlen Wi-Fi-átjáróhoz kötött útvonal nem vihető át a laptop következő hálózatára.

A nevek és a szabályok nem követik az útvonalakat

Az útvonal javítása csomagokat állít helyre, nem neveket. Ha a helyi eszközök egy ráerőltetett feloldón keresztül oldódnak fel, amely semmit sem tud róluk, a csatolás továbbra is sikertelen, még ha a cím elérhető is. A helyi neveknek helyi vagy osztott DNS-elrendezésre van szükségük, és ez az útvonal-kivételtől külön döntés.

A szabályok megint külön vannak. Egy VPN-kliens helyi hozzáférési szűrője szándékosan megtilthatja a forgalmat a privát tartományok felé, és egy útvonal nem írja felül ezt a szabályt. Nem megbízható hálózaton egy privát cím sem bizonyítja, hogy a cél az ön tárolószervere, ezért a kivételnek olyan konkrétnak kell lennie, mint maga az útvonal.

Egy szerződés, amelyet átadhat

A kész kialakításnak rövid listaként kell olvashatónak lennie: az általános internetes forgalom az alagutat követi, és ezek a megnevezett helyi előtagok megtartják az útjukat a helyi routeren keresztül. Írja le az előtagokat, a következő ugrást és a hozzájuk tartozó DNS-utótagot, és tartsa a listát elég rövidnek ahhoz, hogy valaki útvonalválasztási tábla olvasása nélkül ellenőrizhesse.

Figyeljen a helyi és távoli tartományok átfedésére. Egy tároló VLAN, amely előtagot oszt meg valamivel a VPN mögött, ahhoz az útvonalhoz oldódik fel, amelyik konkrétabb, és az így keletkező viselkedés zavaró módon tűnik szakaszosnak. Az egyik oldal újraszámozása általában olcsóbb, mint a kétértelműség örökös hibakeresése.

Tesztelje a szerződést kétszer: egyszer felállított alagúttal és egyszer leállítottal. Ha a helyi út csak az egyik állapotban működik, a kivétel még nem szerződés.