Split tunneling podľa aplikácie alebo podľa cieľa: čo zvoliť

Split tunneling podľa aplikácie a podľa cieľa nie sú dve nastavenia pre tú istú úlohu. Jedno sa pýta, ktorý proces posiela paket; druhé sa pýta, kam tento paket ide. Pravidlo postavené na prvú otázku ticho zlyhá, keď prevádzka prichádza z pomocného procesu, a pravidlo na druhú zlyhá, keď sa meno hostiteľa preloží na adresu, ktorú ste nikdy neuvedli. Zvoľte objekt, ktorý zodpovedá požiadavke, a dokážte to dvoma testovacími paketmi: jeden musí použiť tunel a druhý nesmie.

Dve pravidlá pôsobia v rôznych vrstvách

Pravidlo aplikácie sa vynucuje nad sieťovou vrstvou, voči identite, ktorú operačný systém priradí odosielateľovi. Na Androide je to UID za balíčkom a služba VPN rozhoduje pre každé UID, či prevádzka vstúpi do tunela. Na cieľ sa nič nepýta, takže vybraná aplikácia dosiahne na čokoľvek a žiadna iná aplikácia nedosiahne na internú sieť.

Pravidlo cieľa sa vynucuje na samotnom pakete. Rozhranie tunela vlastní sadu prefixov, smerovacia tabuľka doň posiela zodpovedajúcu prevádzku a odosielajúci proces nehrá rolu. Preto pravidlo cieľa pokrýva službu, tlačiareň alebo dávkovú úlohu, ktorú si nikto nespomenul uviesť, a preto ho na platforme, ktorej klient sa na proces nikdy nepozerá, nemožno vyjadriť ako práve tento program.

Pravidlá aplikácií sedia mobilným klientom a spravovaným agentom

Android voľbu ukazuje priamo: VpnService.Builder.addAllowedApplication() a addDisallowedApplication() prijímajú názvy balíčkov a rozhodnutie vynucujú pre každé UID, ako popisuje vývojárska príručka VPN pre Android. iOS má ekvivalent cez pravidlá VPN pre jednotlivé aplikácie viazané na identifikátory balíčkov, zvyčajne dodávané profilom MDM, nie písané ručne.

Stolné klienty sú slabé miesto. Väčšina klientov VPN pre Windows a macOS smeruje podľa cieľa a vôbec neponúka výber podľa procesu, pretože ovládač tunela vidí pakety, nie procesy. Ak váš plán závisí od tunelovania jednej aplikácie na notebooku, overte skutočné možnosti klienta, skôr než okolo nich budete navrhovať; možno vyberáte medzi zoznamom cieľov a druhým strojom.

Dôsledok, ktorý ľudia prehliadajú: na týchto platformách nemožno pravidlo aplikácie napodobniť routami. Pridanie hostiteľskej routy pre server aplikácie protuneluje prevádzku všetkých k tomuto serveru, vrátane prehliadača a aktualizátora.

Pravidlá cieľa sedia zoznamom podsietí a dostupnosti lokalít

WireGuard robí model explicitným. AllowedIPs je kryptokľúčové smerovanie: vnútorný paket, ktorého cieľ spadá do zoznamu partnera, sa šifruje k tomuto partnerovi, a všetko ostatné odchádza nešifrované bežnou cestou. Nie je žiadny proces na pomenovanie ani nejasnosť o tom, čo je zahrnuté.

OpenVPN sa dostane na to isté miesto cez vynútenú smerovaciu tabuľku. route-nopull zabráni serveru diktovať routy, potom klientska route 10.20.0.0 255.255.0.0 vpn_gateway pokrýva presne kancelársky prefix. IPv6 je v každom z týchto klientov samostatný príkaz a zabudnutie naň je najčastejší spôsob úniku okolo správne vyzerajúceho IPv4 splitu.

Meno hostiteľa nie je routa. Ak profil ponúka pole domény, berte ho ako meno, ktoré klient raz preloží, nie ako trvalý rozsah adries; siete na doručovanie obsahu a load balancery zajtra vydajú iné adresy.

Kde sa oba modely lomia: pomocníci, zdieľané služby, resolvery

Pomocné procesy lámajú pravidlá aplikácií spôsobom, ktorý vyzerá ako porucha servera. Aktualizátor prehliadača, hlásenie zlyhaní, synchronizačná služba bežiaca ako SYSTEM a WebView vložený v inom balíčku sú oddelené identity, takže tunelovanie prehliadača môže nechať skutočnú požiadavku mimo tunela. Opak je rovnako mätúci: vylúčená aplikácia, ktorá volá zdieľanú knižnicu vnútri tunelovaného procesu, má prevádzku stále tunelom.

Pravidlá cieľa sa lámajú na zdieľaných službách a na menách. Súborové share, tlačiarne, interný DNS a licenčný server žijú na adresách, takže tunel jednej aplikácie dá prehliadaču prístup, zatiaľ čo mapovaný disk zostane mŕtvy. Ten rozdiel v pokrytí nie je chyba ani jedného modelu, ale je dôvodom, prečo tunel jednej aplikácie tak často plodí VPN beží a share je preč.

Resolvery prestupujú oba. Ak klient nastaví interné DNS servery, ale operačný systém používa DNS cez HTTPS k verejnému resolveru, odpoveď prichádza zvonku tunela a pravidlo cieľa nemusí nikdy zodpovedať. Než usúdite, že pravidlo je zlé, zistite, ktorý resolver skutočne odpovedal, a na strane klienta potvrďte, či vôbec nainštaloval resolver tunela. Split, ktorý necháva DNS mimo tunela, vyzerá v smerovacej tabuľke dokonale a napriek tomu zlyhá na každom internom mene.

Postup: voľba, nasadenie, overenie

Začnite od požiadavky, nie od menu. Ak je cieľom tunel smie používať len táto aplikácia, potrebujete pravidlá aplikácií a platformu, ktorá ich podporuje. Ak je cieľom tieto siete sú dostupné cez tunel, potrebujete prefixy. Ak je odpoveď oboje, implementujte ich ako dve oddelené kontroly a zapíšte, ktorá z nich vlastní ktorú poruchu.

Použite najužšiu formu, ktorú viete vyjadriť, a potom overte dotazom na smerovaciu tabuľku, nie na ikonu stavu klienta:

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

Prvé dva riadky pomenujú rozhranie, ktoré by použil skutočný cieľ; wg show vypíše nakonfigurovaný zoznam prefixov; vo Windows Find-NetRoute odpovedá na tú istú otázku, ktorú zodpovie stack pri odoslaní paketu. Ak je rozhraním tunel, pravidlo zabralo.

Potom otestujte druhý paket, ktorý má byť vylúčený, z inej aplikácie, na rovnaký cieľ. Do tiketu zapíšte verziu klienta, typ pravidla, zoznam prefixov alebo balíčkov a dva pozorované výsledky. Práve táto dvojica výsledkov povie ďalšiemu inžinierovi, či je politika zle nastavená alebo či prevádzka do nej nikdy nepatrila.