Toepassing-gebaseerde vs bestemming-gebaseerde split-tunneling: wat om te kies

Toepassing-gebaseerde en bestemming-gebaseerde split-tunneling is nie twee instellings vir dieselfde taak nie. Die een vra watter proses 'n pakket stuur; die ander vra waarheen daardie pakket op pad is. 'n Reël wat vir die eerste vraag gebou is, faal stil wanneer die verkeer van 'n hulpproses kom, en 'n reël wat vir die tweede gebou is, faal wanneer 'n gasheernaam na 'n adres oplos wat jy nooit gelys het nie. Kies die objek wat by die vereiste pas, en bewys dit met twee toetspakkette: een wat die tonnel moet gebruik en een wat dit nie moet nie.

Die twee reëls pas op verskillende vlakke

'n Toepassingsreël word bo die netwerklaag toegepas, teen die identiteit wat die bedryfstelsel aan die sender toeken. Op Android is dit die UID agter 'n pakket, en die VPN-diens besluit per UID of verkeer die tonnel binnegaan. Niks oor die bestemming word geraadpleeg nie, so die gekose toepassing kan enigiets bereik en geen ander toepassing kan die interne netwerk bereik nie.

'n Bestemmingsreël word op die pakket self toegepas. Die tonnelkoppelvlak besit 'n stel voorvoegsels, die roetetabel stuur ooreenstemmende verkeer daarin, en die sturende proses is irrelevant. Daarom dek 'n bestemmingsreël 'n diens, 'n drukker of 'n lottaak wat niemand onthou het om te lys nie, en daarom kan dit nie as hierdie een program uitgedruk word op 'n platform wie se kliënt nooit na die proses kyk nie.

Toepassingsreëls pas by mobiele kliënte en bestuurde agente

Android stel die keuse direk bloot: VpnService.Builder.addAllowedApplication() en addDisallowedApplication() neem pakketname en pas die besluit per UID toe, soos beskryf in Android se VPN-ontwikkelaarsgids. iOS het 'n ekwivalent deur per-toepassing-VPN-reëls wat op bundel-identifiseerders geskoei is, gewoonlik gelewer deur 'n MDM-profiel eerder as met die hand getik.

Tafelbladkliënte is die swak plek. Die meeste Windows- en macOS-VPN-kliënte roeteer volgens bestemming en bied glad geen per-proses-kieser nie, want die tonnelaandrywer sien pakkette, nie prosesse nie. As jou plan daarvan afhang om een toepassing op 'n skootrekenaar te tonnel, kyk na die kliënt se werklike vermoëns voordat jy rondom dit ontwerp; jy kies miskien tussen 'n bestemmingslys en 'n tweede masjien.

'n Gevolgtrekking wat mense mis: jy kan nie 'n toepassingsreël met roetes op daardie platforms naboots nie. Om 'n gasheerroete vir die toepassing se bediener by te voeg, tonnel almal se verkeer na daardie bediener, insluitend die blaaier en die opdaterer.

Bestemmingsreëls pas by subnetlyste en werfbereikbaarheid

WireGuard maak die model eksplisiet. AllowedIPs is kriptosleutel-roetering: 'n binnerste pakket wie se bestemming binne 'n peer se lys val, word na daardie peer geënkripteer, en enigiets anders verlaat die netwerk onversleuteld via die normale pad. Daar is geen proses om te noem nie en geen onduidelikheid oor wat ingesluit is nie.

OpenVPN bereik dieselfde plek deur die gestuurde roetetabel. route-nopull keer dat die bediener roetes voorskryf, waarna 'n kliëntkant route 10.20.0.0 255.255.0.0 vpn_gateway presies die kantoorvoorvoegsel dek. IPv6 is 'n aparte stelling in elkeen van hierdie kliënte, en om dit te vergeet is die mees algemene manier om rondom 'n korrek-lykende IPv4-splitsing te lek.

'n Gasheernaam is nie 'n roete nie. As die profiel 'n domeinveld bied, behandel dit as 'n naam wat die kliënt een keer oplos, nie as 'n permanente adresreeks nie; inhoudleweringnetwerke en lasbalanseerders sal môre ander adresse uitdeel.

Waar albei modelle breek: hulpprosesse, gedeelde dienste, oplossers

Hulpprosesse breek toepassingsreëls op 'n manier wat soos 'n bedienerfout lyk. 'n Blaaier se opdaterer, 'n ineenstortingsverslaggewer, 'n sinchroondiens wat as SYSTEM loop en 'n WebView wat in 'n ander pakket ingebed is, is almal aparte identiteite, so om die blaaier te tonnel kan die werklike versoek buite die tonnel laat. Die omgekeerde is net so verwarrend: 'n uitgeslote toepassing wat 'n gedeelde biblioteek binne 'n getonnelde proses aanroep, se verkeer word steeds getonnel.

Bestemmingsreëls breek op gedeelde dienste en op name. Lêerdelings, drukkers, interne DNS en die lisensiebediener woon almal op adresse, so 'n een-toepassing-tonnel gee die blaaier toegang terwyl die gekarteerde skyf dood bly. Daardie dekkingverskil is nie 'n fout in enige model nie, maar dit is die rede waarom 'n een-toepassing-tonnel so dikwels die VPN is op en die deel is weg oplewer.

Oplossers sny deur albei. As die kliënt interne DNS-bedienerstel maar die bedryfstelsel gebruik DNS oor HTTPS na 'n openbare oplosser, kom die antwoord van buite die tonnel en die bestemmingsreël pas dalk nooit nie. Kyk watter oplosser werklik geantwoord het voordat jy aflei die reël is verkeerd, en bevestig aan die kliëntkant of dit die tonneloplosser hoegenaamd geïnstalleer het. 'n Splitsing wat DNS buite die tonnel laat, lyk perfek in die roetetabel en faal steeds elke interne naam.

Werkplan: kies, pas toe, verifieer

Begin by die vereiste, nie by die spyskaart nie. As die doel is net hierdie toepassing mag die tonnel gebruik, het jy toepassingsreëls en 'n platform nodig wat dit ondersteun. As die doel is hierdie netwerke is deur die tonnel bereikbaar, het jy voorvoegsels nodig. As die antwoord albei is, implementeer dit as twee aparte kontroles en skryf neer watter een watter fout besit.

Pas die nouste vorm toe wat jy kan uitdruk, en verifieer dan deur die roetetabel te vra eerder as die kliënt se statusikoon:

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

Die eerste twee reëls noem die koppelvlak wat 'n werklike bestemming sou gebruik; wg show druk die gekonfigureerde voorvoegsellys; op Windows beantwoord Find-NetRoute dieselfde vraag wat die stapel sal beantwoord wanneer die pakket gestuur word. As die koppelvlak die tonnel is, het die reël gepas.

Toets dan 'n tweede pakket wat uitgesluit moet wees, van 'n ander toepassing, na dieselfde bestemming. Teken die kliëntweergawe, die reëltipe, die voorvoegsellys of pakketlys en die twee waargenome resultate in die kaartjie aan. Daardie paar resultate is wat die volgende ingenieur vertel of die beleid verkeerd opgestel is of die verkeer nooit daaraan behoort het nie.