Split tunneling podle aplikace a podle cíle: který zvolit

Split tunneling podle aplikace a podle cíle nejsou dvě nastavení pro stejný úkol. Jedno se ptá, který proces posílá paket; druhé se ptá, kam tento paket směřuje. Pravidlo postavené na první otázku tiše selže, když provoz přichází z pomocného procesu, a pravidlo na druhou selže, když se jméno hostitele přeloží na adresu, kterou jste nikdy neuvedli. Zvolte objekt, který odpovídá požadavku, a dokažte to dvěma testovacími pakety: jeden musí použít tunel a druhý nesmí.

Dvě pravidla působí v různých vrstvách

Pravidlo aplikace se vynucuje nad síťovou vrstvou, vůči identitě, kterou operační systém přiřadí odesílateli. Na Androidu je to UID za balíčkem a služba VPN rozhoduje pro každé UID, zda provoz vstoupí do tunelu. Na cíl se neptá nic, takže vybraná aplikace dosáhne na cokoli a žádná jiná aplikace nedosáhne na interní síť.

Pravidlo cíle se vynucuje na samotném paketu. Rozhraní tunelu vlastní sadu prefixů, směrovací tabulka do něj posílá odpovídající provoz a odesílající proces nehraje roli. Proto pravidlo cíle pokrývá službu, tiskárnu nebo dávkovou úlohu, kterou si nikdo nevzpomněl uvést, a proto ho nelze na platformě, jejíž klient se na proces nikdy nedívá, vyjádřit jako právě tento program.

Pravidla aplikací sedí mobilním klientům a spravovaným agentům

Android volbu ukazuje přímo: VpnService.Builder.addAllowedApplication() a addDisallowedApplication() přijímají názvy balíčků a rozhodnutí vynucují pro každé UID, jak popisuje vývojářská příručka VPN pro Android. iOS má ekvivalent přes pravidla VPN pro jednotlivé aplikace vázaná na identifikátory balíčků, obvykle dodávaná profilem MDM, nikoli psaná ručně.

Stolní klienti jsou slabé místo. Většina klientů VPN pro Windows a macOS směruje podle cíle a nenabízí žádný výběr podle procesu, protože ovladač tunelu vidí pakety, ne procesy. Pokud váš plán závisí na tunelování jedné aplikace na notebooku, ověřte skutečné možnosti klienta, než kolem nich budete navrhovat; možná vybíráte mezi seznamem cílů a druhým strojem.

Důsledek, který lidé přehlížejí: na těchto platformách nelze pravidlo aplikace napodobit routami. Přidání hostitelské routy pro server aplikace protuneluje provoz všech k tomuto serveru, včetně prohlížeče a aktualizátoru.

Pravidla cíle sedí seznamům podsítí a dostupnosti lokalit

WireGuard model zpřesňuje. AllowedIPs je kryptoklíčové směrování: vnitřní paket, jehož cíl spadá do seznamu peeru, se šifruje k tomuto peeru, a vše ostatní odchází nešifrovaně běžnou cestou. Není žádný proces k pojmenování a žádná nejasnost o tom, co je zahrnuto.

OpenVPN se dostane na stejné místo přes vynucenou směrovací tabulku. route-nopull zabrání serveru diktovat routy, načež klientská route 10.20.0.0 255.255.0.0 vpn_gateway pokrývá přesně kancelářský prefix. IPv6 je v každém z těchto klientů samostatný příkaz a zapomenutí na něj je nejčastější způsob úniku kolem správně vypadajícího IPv4 splitu.

Jméno hostitele není routa. Pokud profil nabízí pole domény, berte ho jako jméno, které klient jednou přeloží, ne jako trvalý rozsah adres; sítě pro doručování obsahu a load balancery zítra vydají jiné adresy.

Kde se oba modely lámou: pomocné procesy, sdílené služby, resolvery

Pomocné procesy lámou pravidla aplikací způsobem, který vypadá jako závada serveru. Aktualizátor prohlížeče, hlášení pádů, synchronizační služba běžící jako SYSTEM a WebView vložený v jiném balíčku jsou oddělené identity, takže tunelování prohlížeče může nechat skutečný požadavek mimo tunel. Opak je stejně matoucí: vyloučená aplikace, která volá sdílenou knihovnu uvnitř tunelovaného procesu, má provoz stále tunelem.

Pravidla cíle se lámou na sdílených službách a na jménech. Souborové share, tiskárny, interní DNS a licenční server žijí na adresách, takže tunel jedné aplikace dá prohlížeči přístup, zatímco mapovaný disk zůstane mrtvý. Tento rozdíl v pokrytí není chyba ani jednoho modelu, ale je důvodem, proč tunel jedné aplikace tak často plodí VPN běží a share je pryč.

Resolver prostupuje oba. Pokud klient nastaví interní DNS servery, ale operační systém používá DNS přes HTTPS k veřejnému resolveru, odpověď přichází zvenčí tunelu a pravidlo cíle nemusí nikdy odpovídat. Než usoudíte, že pravidlo je špatné, zjistěte, který resolver skutečně odpověděl, a na straně klienta potvrďte, zda vůbec nainstaloval resolver tunelu. Split, který nechává DNS mimo tunel, vypadá ve směrovací tabulce dokonale a přesto selže na každém interním jménu.

Postup: volba, nasazení, ověření

Začněte od požadavku, ne od menu. Pokud je cílem tunel smí používat jen tato aplikace, potřebujete pravidla aplikací a platformu, která je podporuje. Pokud je cílem tyto sítě jsou dostupné tunelem, potřebujete prefixy. Pokud je odpověď obojí, implementujte je jako dvě oddělené kontroly a zapište, která z nich vlastní kterou poruchu.

Použijte nejužší formu, kterou umíte vyjádřit, a pak ověřte dotazem na směrovací tabulku, nikoli 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

První dva řádky pojmenují rozhraní, které by použil skutečný cíl; wg show vypíše nakonfigurovaný seznam prefixů; ve Windows Find-NetRoute odpovídá na stejnou otázku, kterou zodpoví stack při odeslání paketu. Pokud je rozhraním tunel, pravidlo zabralo.

Potom otestujte druhý paket, který má být vyloučen, z jiné aplikace, na stejný cíl. Do tiketu zapište verzi klienta, typ pravidla, seznam prefixů nebo balíčků a dva pozorované výsledky. Právě tato dvojice výsledků řekne dalšímu inženýrovi, zda je politika špatně nastavená, nebo zda provoz do ní nikdy nepatřil.