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

Split tunneling zasnovan na aplikaciji i na odredištu nisu dve 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 razreši u adresu koju nikada niste naveli. Odaberite objekat koji odgovara zahtevu i dokažite to dvama testnim paketima: jedan mora koristiti tunel, drugi ne sme.

Dva pravila deluju na različitim slojevima

Pravilo aplikacije primenjuje se iznad mrežnog sloja, prema identitetu koji operativni sistem dodeljuje 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 primenjuje se na sam paket. Interfejs tunela poseduje 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 setio 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 primenjuju odluku po UID-u, kao što je opisano u Android vodiču za VPN programere. 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 mesto. 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, proverite stvarne mogućnosti klijenta pre nego što dizajnirate oko toga; možda birate između liste odredišta i drugog računara.

Posledica 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 pregledač 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 partnera šifruje se prema tom partneru, 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 mesto kroz potisnutu tabelu ruta. route-nopull spreč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 razreši jednom, a ne kao trajni raspon adresa; mreže za isporuku sadržaja i balanseri opterećenja sutra će dati drugačije adrese.

Gde se lome oba modela: pomoćnici, zajednički servisi, resolveri

Pomoćni procesi kvare pravila aplikacija na način koji izgleda kao kvar servera. Ažuriranje pregledača, izvestilac o rušenju, servis za sinhronizaciju koji radi kao SYSTEM i WebView ugrađen u drugi paket sve su odvojeni identiteti, pa tunelovanje pregledača može ostaviti stvarni zahtev 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 delovi, štampači, interni DNS i licencni server žive na adresama, pa tunel jedne aplikacije daje pregledaču 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.

Resolver i presecaju 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. Proverite koji je resolver stvarno odgovorio pre 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.

Postupak: odabir, primena, provera

Pođite od zahteva, ne od menija. Ako je cilj samo ova aplikacija sme 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 dve odvojene kontrole i zapišite koja od njih poseduje koji kvar.

Primenite najužu formu koju možete izraziti, pa proverite 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 poslat. Ako je interfejs tunel, pravilo se poklopilo.

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