Alkalmazásalapú vs. célalapú split tunneling: melyiket válassza

Az alkalmazásalapú és a célalapú split tunneling nem ugyanannak a feladatnak két beállítása. Az egyik azt kérdezi, melyik folyamat küldi a csomagot; a másik azt, hová megy ez a csomag. Az első kérdésre épített szabály csendben elbukik, amikor a forgalom segédfolyamatból érkezik, a másodikra épített szabály pedig akkor, amikor egy hosztnév olyan címre oldódik fel, amelyet soha nem listázott. Válassza a követelményhez illő objektumot, és bizonyítsa két tesztcsomaggal: az egyiknek a tunelt kell használnia, a másiknak nem.

A két szabály különböző rétegeken hat

Az alkalmazásszabály a hálózati réteg felett érvényesül, azzal az identitással szemben, amelyet az operációs rendszer a küldőnek ad. Androidon ez a csomag mögötti UID, és a VPN-szolgáltatás UID-nként dönti el, bekerül-e a forgalom a tunelbe. A célról semmit sem kérdez, ezért a kiválasztott alkalmazás bármit elérhet, más alkalmazás pedig nem érheti el a belső hálózatot.

A célszabály magán a csomagon érvényesül. A tunel interfésze prefixek halmazával rendelkezik, az útválasztási tábla oda küldi a megfelelő forgalmat, és a küldő folyamat irreleváns. Ezért fed le egy célszabály olyan szolgáltatást, nyomtatót vagy kötegelt feladatot, amelyet senki nem jutott eszébe listázni, és ezért nem fejezhető ki úgy, hogy pont ez a program olyan platformon, amelynek kliense soha nem nézi a folyamatot.

Az alkalmazásszabályok mobil kliensekhez és felügyelt ügynökökhöz illenek

Az Android közvetlenül kínálja a választást: a VpnService.Builder.addAllowedApplication() és a addDisallowedApplication() csomagneveket fogad, és UID-nként érvényesíti a döntést, ahogy az Android VPN-fejlesztői útmutatója leírja. Az iOS-en a bundle-azonosítókon alapuló, alkalmazásonkénti VPN-szabályok jelentenek megfelelőt, amelyeket általában MDM-profil szállít, nem kézzel gépelnek.

Az asztali kliensek a gyenge pont. A legtöbb Windows és macOS VPN-kliens cél szerint útválaszt, és egyáltalán nem kínál folyamatonkénti választót, mert a tunel illesztőprogramja csomagokat lát, nem folyamatokat. Ha a terve egyetlen alkalmazás laptopon való tunelésétől függ, nézze meg a kliens tényleges képességeit, mielőtt köré tervezne; lehet, hogy egy céllista és egy második gép között választ.

Egy gyakran kihagyott következmény: ezeken a platformokon nem lehet útvonalakkal utánozni egy alkalmazásszabályt. Ha hosztútvonalat ad az alkalmazás kiszolgálójához, mindenki forgalma azon a kiszolgálón megy át a tunelen, a böngészőt és a frissítőt is beleértve.

A célszabályok alhálózati listákhoz és oldalak elérhetőségéhez illenek

A WireGuard explicitté teszi a modellt. A AllowedIPs kriptokulcs-alapú útválasztás: az a belső csomag, amelynek célja egy peer listájába esik, ahhoz a peerhez titkosítódik, minden más pedig titkosítatlanul hagyja el a hálózatot a normál úton. Nincs megnevezhető folyamat, és nincs bizonytalanság abban, mi tartozik bele.

Az OpenVPN ugyanoda jut a betoltott útválasztási táblán keresztül. A route-nopull megakadályozza, hogy a kiszolgáló útvonalakat diktáljon, ezután az ügyféloldali route 10.20.0.0 255.255.0.0 vpn_gateway pontosan az irodai prefixet fedi le. Az IPv6 mindegyik ilyen kliensben külön utasítás, és elfelejteni a leggyakoribb módja annak, hogy egy helyesnek látszó IPv4-split mellett szivárogjon a forgalom.

A hosztnév nem útvonal. Ha a profil domainmezőt kínál, kezelje úgy, mint egy nevet, amelyet a kliens egyszer old fel, nem mint állandó címteret; a tartalomkézbesítő hálózatok és a terheléselosztók holnap más címeket adnak.

Ahol mindkét modell megtörik: segédek, megosztott szolgáltatások, feloldók

A segédfolyamatok megtörik az alkalmazásszabályokat úgy, hogy kiszolgálóhibának látszik. Egy böngésző frissítője, egy összeomlás-jelentő, egy SYSTEM alatt futó szinkronizálási szolgáltatás és egy másik csomagba ágyazott WebView mind külön identitás, ezért a böngésző tunelése a tényleges kérést a tunelen kívül hagyhatja. A fordítottja ugyanolyan zavaró: egy kizárt alkalmazás, amely egy tunelbe vont folyamaton belüli megosztott könyvtárat hív, forgalma továbbra is a tunelen megy.

A célszabályok megosztott szolgáltatásokon és neveken törik meg. A fájlmegosztások, nyomtatók, a belső DNS és a licenckiszolgáló mind címeken él, ezért egy alkalmazás tunelje hozzáférést ad a böngészőnek, miközben a csatolt meghajtó halott marad. Ez a lefedettségi különbség egyik modellben sem hiba, de ez az oka, hogy az egyalkalmazásos tunel olyan gyakran azt eredményezi, hogy a VPN megy, és a megosztás eltűnt.

A feloldók mindkettőt átvágják. Ha a kliens belső DNS-kiszolgálókat állít be, de az operációs rendszer HTTPS-en keresztüli DNS-t használ egy nyilvános feloldóhoz, a válasz a tunelen kívülről érkezik, és a célszabály talán soha nem illeszkedik. Ellenőrizze, melyik feloldó válaszolt valójában, mielőtt arra jutna, hogy a szabály hibás, és erősítse meg az ügyfél oldalán, telepítette-e egyáltalán a tunel feloldóját. Az a split, amely a DNS-t a tunelen kívül hagyja, tökéletesnek látszik az útválasztási táblában, és mégis minden belső néven elbukik.

Munkamenet: választás, alkalmazás, ellenőrzés

A követelményből induljon ki, ne a menüből. Ha a cél az, hogy csak ez az alkalmazás használhassa a tunelt, alkalmazásszabályokra és azokat támogató platformra van szüksége. Ha a cél az, hogy ezek a hálózatok a tunelen keresztül elérhetők, prefixekre van szüksége. Ha a válasz mindkettő, két külön vezérlőként valósítsa meg őket, és írja le, melyik melyik hibáért felel.

A legszűkebb kifejezhető formát alkalmazza, majd ellenőrizze az útválasztási táblától kérdezve, nem a kliens állapotikonjától:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

Az első két sor megnevezi az interfészt, amelyet egy valódi cél használna; a wg show kiírja a beállított prefixlistát; Windowson a Find-NetRoute ugyanarra a kérdésre válaszol, amelyre a verem válaszol a csomag elküldésekor. Ha az interfész a tunel, a szabály illeszkedett.

Ezután teszteljen egy második csomagot, amelyet ki kellene zárni, egy másik alkalmazásból, ugyanarra a célra. Jegyezze fel a jegybe a kliens verzióját, a szabály típusát, a prefix- vagy csomaglistát és a két megfigyelt eredményt. Pont ez az eredménypár mondja meg a következő mérnöknek, hogy a házirend hibásan van beállítva, vagy a forgalom soha nem tartozott hozzá.