Split tunneling prema aplikaciji ili prema odredištu: što odabrati

Split tunneling prema aplikaciji i prema odredištu nisu dvije postavke za isti posao. Jedno pita koji proces šalje paket; drugo pita kamo taj paket ide. Pravilo napravljeno za prvo pitanje tiho zakaže kada promet dolazi iz pomoćnog procesa, a pravilo za drugo zakaže kada se ime hosta razriješi u adresu koju nikada niste naveli. Odaberite objekt koji odgovara zahtjevu i dokažite to dvama testnim paketima: jedan mora koristiti tunel, drugi ne smije.

Dva pravila djeluju na različitim slojevima

Pravilo aplikacije primjenjuje se iznad mrežnog sloja, prema identitetu koji operacijski sustav dodjeljuje pošiljatelju. Na Androidu je to UID iza paketa, a VPN servis odlučuje po UID-u ulazi li promet u tunel. Ništa o odredištu se ne pita, pa odabrana aplikacija može dosegnuti bilo što, a nijedna druga aplikacija ne može dosegnuti internu mrežu.

Pravilo odredišta primjenjuje se na sam paket. Sučelje tunela posjeduje skup prefiksa, tablica usmjeravanja šalje odgovarajući promet u njega, a proces pošiljatelj je nebitan. Zato pravilo odredišta pokriva uslugu, pisač ili batch posao koji se nitko nije sjetio navesti, i zato se ne može izraziti kao baš ovaj program na platformi čiji klijent nikada ne gleda proces.

Pravila aplikacija odgovaraju mobilnim klijentima i upravljanim agentima

Android izlaže izbor izravno: VpnService.Builder.addAllowedApplication() i addDisallowedApplication() uzimaju imena paketa i primjenjuju odluku po UID-u, kao što je opisano u Androidovu vodiču za VPN developere. iOS ima ekvivalent kroz VPN pravila po aplikaciji vezana za identifikatore paketa, obično dostavljena kroz MDM profil, a ne otkucana ručno.

Desktop klijenti su slabo mjesto. Većina Windows i macOS VPN klijenata usmjerava po odredištu i uopće ne nudi birač po procesu, jer upravljački program tunela vidi pakete, ne procese. Ako vaš plan ovisi o tuneliranju jedne aplikacije na prijenosnom računalu, provjerite stvarne mogućnosti klijenta prije nego što dizajnirate oko toga; možda birate između popisa odredišta i drugog stroja.

Posljedica koju ljudi propuštaju: na tim platformama ne možete oponašati pravilo aplikacije rutama. Dodavanje host rute za poslužitelj aplikacije tunelira promet svih prema tom poslužitelju, uključujući preglednik i program za ažuriranje.

Pravila odredišta odgovaraju popisima podmreža i dostupnosti lokacija

WireGuard model čini eksplicitnim. AllowedIPs je kriptoključno usmjeravanje: unutarnji paket čije odredište pada unutar popisa peera šifrira se prema tom peeru, a sve ostalo izlazi nešifrirano normalnim putem. Nema procesa koji treba imenovati i nema dvosmislenosti o tome što je uključeno.

OpenVPN dolazi na isto mjesto kroz potisnutu tablicu ruta. route-nopull sprječava poslužitelj da diktira rute, nakon čega klijentska route 10.20.0.0 255.255.0.0 vpn_gateway pokriva točno uredski prefiks. IPv6 je zasebna izjava u svakom od ovih klijenata, a zaboravljanje iste najčešći je način curenja oko ispravno izgledajućeg IPv4 splita.

Ime hosta nije ruta. Ako profil nudi polje domene, tretirajte ga kao ime koje klijent razriješi jednom, a ne kao trajni raspon adresa; mreže za isporuku sadržaja i balanseri opterećenja sutra će dati drugačije adrese.

Gdje se lome oba modela: pomoćni procesi, zajedničke usluge, razrješivači

Pomoćni procesi kvare pravila aplikacija na način koji izgleda kao kvar poslužitelja. Ažuriranje preglednika, izvjestitelj o rušenju, servis za sinkronizaciju koji radi kao SYSTEM i WebView ugrađen u drugi paket sve su odvojeni identiteti, pa tuneliranje preglednika može ostaviti stvarni zahtjev izvan tunela. Obrnuto je jednako zbunjujuće: izuzeta aplikacija koja poziva zajedničku biblioteku unutar tuneliranog procesa i dalje ima promet kroz tunel.

Pravila odredišta kvare se na zajedničkim uslugama i na imenima. Mrežni dijelovi, pisači, interni DNS i licencni poslužitelj žive na adresama, pa tunel jedne aplikacije daje pregledniku pristup dok mapirani disk ostaje mrtav. Ta razlika u pokrivenosti nije greška ni u jednom modelu, ali je razlog zašto tunel jedne aplikacije tako često proizvede VPN radi, a share je nestao.

Razrješivači presijecaju oba. Ako klijent postavi interne DNS poslužitelje, ali operacijski sustav koristi DNS preko HTTPS-a prema javnom razrješivaču, odgovor dolazi izvan tunela i pravilo odredišta možda nikada neće odgovarati. Provjerite koji je razrješivač stvarno odgovorio prije nego zaključite da je pravilo pogrešno, i potvrdite na strani klijenta je li uopće instalirao razrješivač tunela. Split koji ostavlja DNS izvan tunela izgleda savršeno u tablici usmjeravanja i ipak pada na svakom internom imenu.

Postupak: odabir, primjena, provjera

Pođite od zahtjeva, ne od izbornika. Ako je cilj samo ova aplikacija smije koristiti tunel, potrebna su pravila aplikacija i platforma koja ih podržava. Ako je cilj ove mreže su dostupne kroz tunel, potrebni su prefiksi. Ako je odgovor oba, implementirajte ih kao dvije odvojene kontrole i zapišite koja od njih posjeduje koji kvar.

Primijenite najužu formu koju možete izraziti, pa provjerite pitajući tablicu usmjeravanja, a ne ikonu statusa klijenta:

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

Prva dva retka imenuju sučelje koje bi stvarno odredište koristilo; wg show ispisuje konfigurirani popis prefiksa; na Windowsu Find-NetRoute odgovara na isto pitanje na koje će stog odgovoriti kada paket bude poslan. Ako je sučelje tunel, pravilo se poklopilo.

Zatim testirajte drugi paket koji treba biti izuzet, iz druge aplikacije, na isto odredište. Zabilježite u ticketu verziju klijenta, tip pravila, popis prefiksa ili paketa i dva promatrana rezultata. Upravo taj par rezultata kaže sljedećem inženjeru je li politika pogrešno konfigurirana ili promet nikada nije ni pripadao njoj.