Split tunneling zasnovan na aplikaciji i na odredištu: šta odabrati

Split tunneling zasnovan na aplikaciji i na odredištu nisu dvije postavke za isti posao. Jedno pita koji proces šalje paket; drugo pita kuda taj paket ide. Pravilo napravljeno za prvo pitanje tiho zakaže kada saobraćaj dolazi iz pomoćnog procesa, a pravilo za drugo zakaže kada se ime hosta razriješi u adresu koju nikada niste naveli. Odaberite objekat koji odgovara zahtjevu, pa to dokažite s dva testna paketa: 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 operativni sistem dodjeljuje pošiljaocu. Na Androidu je to UID iza paketa, a VPN servis odlučuje po UID-u da li saobraćaj ulazi u tunel. Ništa o odredištu se ne pita, pa odabrana aplikacija može dosegnuti bilo šta, a nijedna druga aplikacija ne može dosegnuti internu mrežu.

Pravilo odredišta primjenjuje se na sam paket. Interfejs tunela posjeduje skup prefiksa, tabela rutiranja šalje odgovarajući saobraćaj u njega, a proces pošiljalac je nebitan. Zato pravilo odredišta pokriva servis, štampač ili batch posao koji se niko 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 direktno: VpnService.Builder.addAllowedApplication() i addDisallowedApplication() uzimaju imena paketa i primjenjuju odluku po UID-u, kao što je opisano u Android 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 rutira po odredištu i uopšte ne nudi birač po procesu, jer drajver tunela vidi pakete, ne procese. Ako vaš plan zavisi od tunelovanja jedne aplikacije na laptopu, provjerite stvarne mogućnosti klijenta prije nego što dizajnirate oko toga; možda birate između liste odredišta i drugog računara.

Posljedica koju ljudi propuštaju: na tim platformama ne možete imitirati pravilo aplikacije rutama. Dodavanje host rute za server aplikacije tuneluje saobraćaj svih prema tom serveru, uključujući preglednik i program za ažuriranje.

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

WireGuard model čini eksplicitnim. AllowedIPs je kriptoključno rutiranje: unutrašnji paket čije odredište pada unutar liste peera šifruje se prema tom peeru, a sve ostalo izlazi nešifrovano normalnim putem. Nema procesa koji treba imenovati i nema dvosmislenosti o tome šta je uključeno.

OpenVPN dolazi na isto mjesto kroz potisnutu tabelu ruta. route-nopull sprječava server da diktira rute, nakon čega klijentska route 10.20.0.0 255.255.0.0 vpn_gateway pokriva tačno kancelarijski 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 domena, 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 oba modela lome: pomoćni procesi, zajednički servisi, resolveri

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

Pravila odredišta kvare se na zajedničkim servisima i na imenima. Mrežni dijelovi, štampači, interni DNS i licencni server ž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.

Resolveri presijecaju oba. Ako klijent postavi interne DNS servere, ali operativni sistem koristi DNS preko HTTPS-a prema javnom resolveru, odgovor dolazi izvan tunela i pravilo odredišta možda nikada neće odgovarati. Provjerite koji resolver je stvarno odgovorio prije nego zaključite da je pravilo pogrešno, i potvrdite na strani klijenta da li je uopšte instalirao resolver tunela. Split koji ostavlja DNS izvan tunela izgleda savršeno u tabeli rutiranja i ipak pada na svakom internom imenu.

Plan rada: izbor, primjena, provjera

Pođite od zahtjeva, ne od menija. 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 tabelu rutiranja, 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 reda imenuju interfejs koji bi stvarno odredište koristilo; wg show ispisuje konfigurisanu listu prefiksa; na Windowsu Find-NetRoute odgovara na isto pitanje na koje će stek odgovoriti kada paket bude poslan. Ako je interfejs tunel, pravilo se poklopilo.

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