Hogyan dönti el a szétválasztott tunel, melyik forgalom használja a VPN-t

A szétválasztott tunel szabályhalmazként kifejezett útválasztási szabályzat, és a kliens csak az a dolog, ami ezeket telepíti. Az elkülönítés két helyen történik: a csomagok számára utat választó illeszkedő szabályok, és azok a kötések, amelyek egy alkalmazást egy interfészen tartanak, bármit is mond a táblázat. Hogy a kliens melyik mechanizmusra támaszkodik, megmagyarázza az emberek által jelentett meglepődések nagy részét.

Az egy sorban kimondható szabályzat tesztelhető. A gyorsabb böngészésként leírt szabályzat nem az, és nem mondja meg, melyik szabályt kell megváltoztatni, amikor egy kérés a rossz irányba indul.

A kliens telepíti a szabályokat, a választást a kernel hozza

Amikor a tunel felmegy, a kliens útvonalakat és gyakran szabályzati szabályokat ad azokhoz a táblákhoz, amelyeket a többi interfésze használ. Minden csomag ezután egy olyan kereséshez ér, amely összeveti a célját minden jelölt prefixszel és a legpontosabb illeszkedést tartja meg, miközben a prioritás eldönti a különböző táblákra mutató szabályok között kialakuló holtversenyeket. Ebben a keresésben semmi sem tudja, hogy a csomag egy böngészőlapról érkezett, nem pedig egy biztonsági mentési feladatból. A nyertes szabály az, amely meghatározza az útvonalat, és ezt a változás előtt és után is elolvashatja.

Ezért tűnhet a szétválasztott tunel önkényesnek. Egy alkalmazás két célja egyszerűen azért követhet különböző útvonalakat, mert az egyik prefix szűkebb a másiknál.

Ugyanez a választás minden platformon létezik, bár a nevek változnak. A Windows a szűrőplatformjába tolja a döntést, az Android a VPN szolgáltatásán keresztül alkalmazásonkénti engedélylistát tesz közzé, a macOS pedig egy olyan eszközhöz csatolja a tunelt, amely még engedelmeskedik az útválasztási táblának. A Microsoft útválasztási jegyzetei olvasásra érdemesek a Windows esetében, és az egy platformra írt útmutató ritkán fordítható át változatlanul egy másikra.

Az alkalmazásonkénti kötés és a célprefixek különböző eszközök

A cél szabályzata azt kérdezi, hová tart a csomag, és az útválasztási táblához vagy egy szabályzati szabályhoz fordul. Az alkalmazásonkénti szabályzat azt kérdezi, melyik program nyitotta a szoftett, és a platform ezt a programot a tunel interfészén tartja, még akkor is, ha egy pontosabb útvonal máshová mutat. A második erősebb, mert túlél táblázatváltozásokat, de csak azokat a folyamatokat fedi, amelyeket a platform hozzá tud rendelni. Egy segédprocessz, egy beágyazott böngésző vagy egy olyan szolgáltatás, amely a saját kapcsolatát nyitja, nem biztos, hogy örökli a feltételezett kötést.

Egyik megközelítés sem marad fenn segítség nélkül a névalapú szabályzattal szemben. A nagy oldalak címei a tartalomhálózatok között forognak, így egy hosztnév néhány prefixhez rögzítése olyan szabályt hoz létre, amely csendben elmulasztja az illeszkedést. Az olyan szabályzathoz, amelynek neveket kell követnie, resolver-tudatos komponensre van szükség statikus útvonal helyett.

A DNS és a biztonsági kapcsoló a saját szabályait követi

A névfeloldás külön döntés a csomagútválasztástól, és a szétválasztott tunel általában két resolver-t akar: a cégét a belső nevekhez, a helyit minden másra. A kliens telepítheti az interfészenkénti DNS-beállításokat, átadhatja a kérdéseket egy közvetítő resolvernek, vagy hagyhatja a rendszer alapértelmezését érintetlenül. Egy böngésző saját titkosított resolverrel mindhárom megoldást megkerüli. Teszteljen egy keresést, ahelyett hogy feltételezné, hogy a resolver követte az útvonalat.

A biztonsági kapcsoló egy szűrőt tesz a tetejére, és ez a szűrő nem mindig különbözteti meg a kívánt kizárást egy véletlen szivárgástól. Egyes kliensek mindent blokkolnak a tunelen kívül, mások engedélyezik a szabályzatban nyilvánított kizárásokat, ezért olvassa el, melyik viselkedést valósítja meg a sajátja, mielőtt bármelyikre támaszkodna.

Ellenőrizze a szétválasztást mindkét oldalról

Tesztelje külön a belefoglalt útvonalat és a kizárt útvonalat, és az eredményt az interfész neve, ne pedig egy nyilvános cím alapján ítélje meg. Ezek a parancsok Linux-gazdát feltételeznek a tunel eszköz már felállított állapotában. Cserélje a 203.0.113.10-t egy olyan célra, amelyet a szabályzata befelé irányít, a 198.51.100.25-t pedig egy olyanra, amelyet kifelé küld.

ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'

Az első két választ együtt olvassa, mert az mindegyikben nevesített interfész megmutatja, hogy a szétválasztás feltette-e azt a célt a tunelre. A resolver-kérdés megmutatja, melyik kiszolgáló válaszolt a belső névre, az utolsó parancs pedig bizonyítja, hogy a tunel eszköz egyáltalán képes kérést vinni. Ha a második sor hibázik, miközben az első sikeres, a szabályzat pontosan azt tette, amit mondtak neki.

Ismételje meg a készletet újracsatlakozás után és hálózatváltozás után. A lízing megújítása és az interfészek mozgása azok a helyek, ahol a szétválasztás abbahagyja a cél és az iránti illeszkedést, amelyre épült, és az egyes futások mentett kimenete nyilvánvalóvá teszi az elcsúszást.