Split tunneling glede na aplikacijo ali na cilj: kaj izbrati

Split tunneling glede na aplikacijo in glede na cilj nista dve nastavitvi za isto nalogo. Eno vpraša, kateri proces pošilja paket; drugo vpraša, kam gre ta paket. Pravilo, zgrajeno za prvo vprašanje, tiho odpove, ko promet prihaja iz pomožnega procesa, pravilo za drugo pa odpove, ko se ime gostitelja razreši v naslov, ki ga nikoli niste navedli. Izberite predmet, ki ustreza zahtevi, in to dokažite z dvema testnima paketoma: eden mora uporabiti tunel, drugi ne sme.

Dve pravili delujeta na različnih plasteh

Pravilo aplikacije se uveljavlja nad omrežno plastjo, proti identiteti, ki jo operacijski sistem dodeli pošiljatelju. V Androidu je to UID za paketom, storitev VPN pa odloči za vsak UID, ali promet vstopi v tunel. O cilju se nič ne vpraša, zato izbrana aplikacija doseže vse, nobena druga aplikacija pa ne doseže notranjega omrežja.

Pravilo cilja se uveljavlja na samem paketu. Vmesnik tunela ima nabor predpon, usmerjevalna tabela pošlje ustrezni promet vanj, proces, ki pošilja, pa ni pomemben. Zato pravilo cilja pokrije storitev, tiskalnik ali paketno opravilo, ki se ga nihče ni spomnil navesti, in zato ga na platformi, katere odjemalec nikoli ne pogleda procesa, ni mogoče izraziti kot prav ta program.

Pravila aplikacij ustrezajo mobilnim odjemalcem in upravljanim agentom

Android izbiro pokaže neposredno: VpnService.Builder.addAllowedApplication() in addDisallowedApplication() sprejmeta imena paketov in uveljavita odločitev za vsak UID, kot je opisano v razvijalskem vodniku za VPN v Androidu. iOS ima enakovredno rešitev s pravili VPN za posamezno aplikacijo, vezanimi na identifikatorje paketov, ki jih običajno dostavi profil MDM in ne ročno vnesemo.

Namizni odjemalci so šibka točka. Večina odjemalcev VPN za Windows in macOS usmerja po cilju in sploh ne ponuja izbirnika po procesu, ker gonilnik tunela vidi pakete, ne procesov. Če je vaš načrt odvisen od tuneliranja ene aplikacije na prenosniku, preverite dejanske zmožnosti odjemalca, preden karkoli načrtujete okoli tega; morda izbirate med seznamom ciljev in drugim strojem.

Posledica, ki jo ljudje spregledajo: na teh platformah pravila aplikacije ni mogoče posnemati s potmi. Če dodate pot gostitelja za strežnik aplikacije, se promet vseh usmeri skozi tunel do tega strežnika, vključno z brskalnikom in posodabljalnikom.

Pravila cilja ustrezajo seznamom podomrežij in dosegljivosti spletišč

WireGuard naredi model ekspliciten. AllowedIPs je usmerjanje s kriptografskim ključem: notranji paket, katerega cilj pade v seznam partnerja, se šifrira k temu partnerju, vse ostalo pa odide nešifrirano po običajni poti. Ni procesa, ki bi ga bilo treba imenovati, in ni dvoumnosti o tem, kaj je vključeno.

OpenVPN pride na isto mesto prek potisnjene usmerjevalne tabele. route-nopull prepreči strežniku, da bi narekoval poti, nato odjemalska route 10.20.0.0 255.255.0.0 vpn_gateway pokrije natanko pisarniško predpono. IPv6 je v vsakem od teh odjemalcev ločena izjava in pozaba le-te je najpogostejši način puščanja okoli pravilno videče se delitve IPv4.

Ime gostitelja ni pot. Če profil ponuja polje domene, ga obravnavajte kot ime, ki ga odjemalec razreši enkrat, ne kot trajni razpon naslovov; omrežja za dostavo vsebine in razporejevalniki obremenitve bodo jutri dali druge naslove.

Kjer se oba modela zlomita: pomočniki, skupne storitve, razreševalniki

Pomožni procesi zlomijo pravila aplikacij tako, da je videti kot okvara strežnika. Posodabljalnik brskalnika, poročevalec o sesutjih, storitev za sinhronizacijo, ki teče kot SYSTEM, in WebView, vdelan v drug paket, so ločene identitete, zato lahko tuneliranje brskalnika pusti dejansko zahtevo zunaj tunela. Tudi obratno je enako zmedeno: izključena aplikacija, ki kliče skupno knjižnico znotraj tuneliranega procesa, ima promet še vedno skozi tunel.

Pravila cilja se zlomijo na skupnih storitvah in na imenih. Datotečne delitve, tiskalniki, notranji DNS in licenčni strežnik živijo na naslovih, zato tunel ene aplikacije da brskalniku dostop, medtem ko preslikan disk ostane mrtev. Ta razlika v pokritosti ni napaka nobenega modela, je pa razlog, da tunel ene aplikacije tako pogosto ustvari stanje, ko VPN deluje, delitve pa ni več.

Razreševalniki prerežejo oba. Če odjemalec nastavi notranje strežnike DNS, operacijski sistem pa uporablja DNS prek HTTPS do javnega razreševalnika, pride odgovor od zunaj tunela in pravilo cilja se morda nikoli ne ujame. Preverite, kateri razreševalnik je dejansko odgovoril, preden sklepate, da je pravilo napačno, in na strani odjemalca potrdite, ali je razreševalnik tunela sploh namestil. Delitev, ki pusti DNS zunaj tunela, je v usmerjevalni tabeli videti popolna in vseeno odpove pri vsakem notranjem imenu.

Postopek: izberi, uporabi, preveri

Začnite pri zahtevi, ne pri meniju. Če je cilj, da sme tunel uporabljati le ta aplikacija, potrebujete pravila aplikacij in platformo, ki jih podpira. Če je cilj, da so ta omrežja dosegljiva skozi tunel, potrebujete predpone. Če je odgovor oboje, jih uresničite kot dva ločena nadzora in zapišite, kateri od njiju je odgovoren za katero okvaro.

Uporabite najožjo obliko, ki jo znate izraziti, nato preverite tako, da vprašate usmerjevalno tabelo in ne ikono stanja odjemalca:

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

Prvi dve vrstici imenujeta vmesnik, ki bi ga uporabil resničen cilj; wg show izpiše nastavljeni seznam predpon; v Windows Find-NetRoute odgovori na isto vprašanje, na katero bo odgovoril sklad ob pošiljanju paketa. Če je vmesnik tunel, se je pravilo ujelo.

Nato preizkusite drugi paket, ki bi moral biti izključen, iz druge aplikacije, na isti cilj. V zahtevek zapišite različico odjemalca, vrsto pravila, seznam predpon ali paketov in dva opažena rezultata. Prav ta par rezultatov pove naslednjemu inženirju, ali je politika napačno nastavljena ali promet nikoli ni spadal vanjo.