Hogyan küldjünk egy IPv4-célt az OpenVPN-alagúton kívülre

A legtöbb teljes alagút beállítás minden csomagot a VPN-en keresztül küld, és a redirect-gateway az a direktíva, amely ezt lehetővé teszi. Egyetlen cél mégis kivonható. Egy gazdagép-útvonal hozzáadása ehhez a címhez a net_gateway helyőrzővel azt mondja a kliensnek, hogy a gép eredeti átjáróján keresztül érje el, miközben minden más továbbra is az alagutat használja.

A sor ártalmatlannak tűnik, és gyakran az is, de csak egy kérdést dönt el: hova mennek a pontosan ehhez az IPv4-címhez tartozó csomagok. Nem változtatja meg a DNS-t, az IPv6-ot, a tűzfal szabályzatát vagy azt, hogy melyik folyamat nyitotta a kapcsolatot, és ezek bármelyike csendben semmissé teheti a kivételt.

Mit nevez meg valójában a net_gateway

A kivétel profilbejegyzése egyetlen sor: route 198.51.100.77 255.255.255.255 net_gateway. Az első cím dokumentációs helyőrző a célhoz, a maszk egyetlen gazdagépre szűkíti az útvonalat, az utolsó token pedig az átjáró helyőrzőjét nevezi meg. OpenVPN az útvonalak telepítésekor oldja fel az átjáró helyőrzőit. vpn_gateway az alagút saját átjáróját jelenti, a VPN-kapcsolat túlsó oldalát. net_gateway azt az alapértelmezett átjárót jelenti, amely a gazdagépnek a VPN bármilyen változtatása előtt volt, általában a fizikai hálózat helyi útválasztóját.

Egy harmadik helyőrző, a remote_host, a VPN-kiszolgáló címére utal, és azért létezik, hogy az alagút a fizikai útvonalon érje el a kiszolgálót. E három összekeverése a leggyakoribb oka annak, hogy egy kivétel rossz helyre kerül, vagy egyáltalán nem települ.

Az értéket kapcsolódáskor olvassák, nem írják be a fájlba. Ha a gép másik hálózatra kerül, a VPN előtti átjáró megváltozik, és az útvonal az újat követi. Ez általában az, amit szeretne, de azt is jelenti, hogy a kivétel viselkedése attól a hálózattól függ, amelyről a kliens elindult.

Miért győz a gazdagép-útvonal az alagút alapértelmezett útvonala felett

Az útválasztást a leghosszabb illeszkedő előtag dönti el. A redirect-gateway def1 általában nem cseréli le az alapértelmezett útvonalat; két felet ad hozzá, egy útvonalat a címterület alsó felére és egyet a felsőre, így az eredeti alapértelmezett útvonal más célokra megmarad. Ezek a felek szélesebbek egyetlen címnél.

Egy cím útvonala 255.255.255.255 maszkkal /32, ami a legpontosabb, amit az IPv4 adhat. Amikor az adott címhez tartozó csomagot értékelik, a /32 illeszkedik és győz, függetlenül attól, melyik útvonal települt előbb. Ez a kivétel mögötti mechanizmus, és ugyanígy működik Linuxon, macOS-en és Windowson, amíg az útvonal valóban jelen van.

A Windows egy második dimenziót ad hozzá. Ha két útvonal egyformán pontos, az alacsonyabb metrikájú győz, és a VPN-adapter olyan interfész-metrikát hordozhat, amely megváltoztatja az eredményt. A /32 továbbra is pontosabb a feleknél, ezért a kivétel általában tart, de egy korábbi munkamenetből maradt elavult útvonal zavaró eredményt adhat, ha ugyanolyan pontos.

Amit a kivétel nem fed le

A DNS az első rés. A kliens belső feloldóbeállításokat továbbíthat, és az operációs rendszer továbbra is ezeket használja a lekérdezésekhez. Egy alkalmazás, amely a kapcsolódás előtt felold egy nevet, belső címet kaphat egy közvetlenül menni hivatott szolgáltatáshoz, vagy külső címet, amely helyesen oldódik fel, de aztán megbotlik a következő résen.

Az IPv6 a második. Az útvonal-direktíva csak az IPv4-gyel foglalkozik. Egy kettős verem cél előnyben részesítheti az IPv6-ot, amely a szabályzattól függően az alagutat vagy a gazdagép IPv6-os alapértelmezett útvonalát követi, így az IPv4-es kivétel soha nem lép életbe. Szüksége van egy megfelelő IPv6-os útvonalra, vagy tudatos döntésre, hogy kikapcsolja az IPv6-ot annak a kliensnek.

Az alkalmazáskör a harmadik. A szabály célalapú, ezért minden folyamat, amely ehhez a címhez kapcsolódik, a közvetlen utat használja, akár az, amelyre gondolt, akár nem. Fordítva, egy webhely több címről is válaszolhat, ezért egy /32 kivétele nem teszi kivétellé a webhelyet. Ha a valódi követelmény az alkalmazásonkénti útválasztás, a Community kliens útvonaltáblája a rossz eszköz.

A kivétel ellenőrzése önmaga becsapása nélkül

Kezdje a telepített útvonallal, ne a böngészővel. Linuxon kérdezze meg a kernelt, melyik útvonalat és következő ugrást használja a konkrét címhez; Windowson olvassa ki az útvonaltáblát ehhez a /32-höz. Erősítse meg, hogy az átjáró a fizikai, nem az alagút. Ha a bejegyzés hiányzik, a profil nem lett alkalmazva, vagy a kliensnek nem volt joga az útvonalak módosításához.

Ezután teszteljen két célt. A kivételes címre irányuló kérésnek a fizikai interfészen kell kilépnie, a vezérlő belső címre irányulónak pedig továbbra is az alagutat kell használnia. Csak a kivételes cím tesztelése semmit sem bizonyít az alagút többi részéről, egy nyilvános webhely tesztelése pedig azt a címet teszteli, amelyre az a webhely feloldódott, ami nem biztos, hogy a szabályban szereplő cím.

Végül ellenőrizze azokat a vezérlőket, amelyek felülírhatják az útvonalat. Egy kliensoldali kill switch vagy egy Windows block-outside-dns beállítás megtilthatja a közvetlen forgalmat, ami úgy jelenik meg, mint egy kapcsolat, amely az útvonal helyessége ellenére meghiúsul. Ne kapcsolja ki ezeket a vezérlőket, hogy a kivétel működni látszódjék; ha a szabályzat tiltja a közvetlen utat, a kivétel tervezési probléma a VPN-szolgáltatás tulajdonosának.

Ellenőrizze újra újracsatlakozás vagy hálózatváltás után, mert a VPN előtti átjáró és a rendelkezésre álló út a pillanat tulajdonságai, nem a profilé.