Sovellusperusteinen vs. kohdeperusteinen split tunneling: kumpi valita

Sovellusperusteinen ja kohdeperusteinen split tunneling eivät ole kaksi asetusta samaan työhön. Toinen kysyy, mikä prosessi lähettää paketin; toinen kysyy, minne paketti on menossa. Ensimmäiseen kysymykseen rakennettu sääntö pettää hiljaa, kun liikenne tulee apuprosessista, ja toiseen rakennettu sääntö pettää, kun isäntänimi ratkeaa osoitteeksi, jota et koskaan luetellut. Valitse vaatimusta vastaava objekti ja todista se kahdella testipaketilla: yhden on käytettävä tunnelia ja toisen ei.

Kaksi sääntöä vaikuttaa eri kerroksissa

Sovellussääntöä valvotaan verkkokerroksen yläpuolella, sitä identiteettiä vastaan, jonka käyttöjärjestelmä antaa lähettäjälle. Androidissa se on paketin takana oleva UID, ja VPN-palvelu päättää UID-kohtaisesti, tuleeko liikenne tunneliin. Kohdetta ei kysytä lainkaan, joten valittu sovellus tavoittaa mitä tahansa, eikä mikään muu sovellus tavoita sisäistä verkkoa.

Kohdesääntöä valvotaan itse paketissa. Tunnelirajapinnalla on joukko etuliitteitä, reititystaulu lähettää vastaavan liikenteen sinne, eikä lähettävä prosessi merkitse mitään. Siksi kohdesääntö kattaa palvelun, tulostimen tai eräajon, jota kukaan ei muistanut luetella, ja siksi sitä ei voi ilmaista muodossa juuri tämä ohjelma alustalla, jonka asiakasohjelma ei koskaan katso prosessia.

Sovellussäännöt sopivat mobiiliasiakkaille ja hallituille agenteille

Android tarjoaa valinnan suoraan: VpnService.Builder.addAllowedApplication() ja addDisallowedApplication() ottavat pakettinimiä ja toteuttavat päätöksen UID-kohtaisesti, kuten Androidin VPN-kehittäjäoppaassa kuvataan. iOSilla on vastine sovelluskohtaisten VPN-sääntöjen kautta, jotka perustuvat pakettitunnisteisiin ja jaetaan yleensä MDM-profiililla eikä kirjoiteta käsin.

Työpöytäasiakkaat ovat heikko kohta. Useimmat Windowsin ja macOSin VPN-asiakkaat reitittävät kohteen mukaan eivätkä tarjoa lainkaan prosessikohtaista valitsinta, koska tunneliajuri näkee paketteja, ei prosesseja. Jos suunnitelmasi nojaa yhden sovelluksen tunneloimiseen kannettavassa, tarkista asiakkaan todelliset kyvyt ennen kuin suunnittelet sen varaan; saatat valita kohdeluettelon ja toisen koneen välillä.

Seuraus, jonka ihmiset ohittavat: näillä alustoilla et voi jäljitellä sovellussääntöä reiteillä. Kun lisäät isäntäreitin sovelluksen palvelimelle, kaikkien liikenne kulkee tunneliin sille palvelimelle, myös selain ja päivittäjä.

Kohdesäännöt sopivat aliverkkoluetteloille ja sivustojen tavoitettavuudelle

WireGuard tekee mallista eksplisiittisen. AllowedIPs on kryptoavainreititys: sisempi paketti, jonka kohde osuu vertaislaitteen luetteloon, salataan kyseiselle vertaislaitteelle, ja kaikki muu lähtee salaamattomana normaalia reittiä. Prosessia ei tarvitse nimetä eikä siitä, mitä sisältyy, ole epäselvyyttä.

OpenVPN pääsee samaan työnnetyn reititystaulun kautta. route-nopull estää palvelinta sanelemasta reittejä, minkä jälkeen asiakaspuolen route 10.20.0.0 255.255.0.0 vpn_gateway kattaa täsmälleen toimiston etuliitteen. IPv6 on erillinen lause jokaisessa näistä asiakkaista, ja sen unohtaminen on yleisin tapa vuotaa oikealta näyttävän IPv4-jaon ohi.

Isäntänimi ei ole reitti. Jos profiili tarjoaa verkkotunnuskentän, käsittele sitä nimenä, jonka asiakas ratkaisee kerran, älä pysyvänä osoitealueena; sisällönjakeluverkot ja kuormantasaajat antavat huomenna eri osoitteita.

Missä molemmat mallit hajoavat: apurit, jaetut palvelut, ratkaisijat

Apuprosessit rikkovat sovellussääntöjä tavalla, joka näyttää palvelinvialta. Selaimen päivittäjä, kaatumisraportoija, SYSTEM-tunnuksella ajettava synkronointipalvelu ja toiseen pakettiin upotettu WebView ovat kaikki erillisiä identiteettejä, joten selaimen tunneloiminen voi jättää varsinaisen pyynnön tunnelin ulkopuolelle. Päinvastainen on yhtä hämmentävää: pois jätetty sovellus, joka kutsuu jaettua kirjastoa tunneloidun prosessin sisällä, kulkee silti tunnelin kautta.

Kohdesäännöt rikkoutuvat jaetuissa palveluissa ja nimissä. Tiedostojakamiset, tulostimet, sisäinen DNS ja lisenssipalvelin sijaitsevat osoitteissa, joten yhden sovelluksen tunneli antaa selaimelle pääsyn, kun taas liitetty asema jää kuolleeksi. Tämä kattavuusero ei ole kummankaan mallin vika, mutta juuri siksi yhden sovelluksen tunneli tuottaa niin usein sen, että VPN on päällä ja jako on poissa.

Ratkaisijat leikkaavat molempia. Jos asiakas asettaa sisäiset DNS-palvelimet mutta käyttöjärjestelmä käyttää DNS:ää HTTPS:n yli julkiseen ratkaisijaan, vastaus tulee tunnelin ulkopuolelta eikä kohdesääntö välttämättä osu koskaan. Tarkista, mikä ratkaisija todella vastasi, ennen kuin päättelet säännön olevan väärä, ja varmista asiakkaan puolelta, asensiko se tunnelin ratkaisijan lainkaan. Jako, joka jättää DNS:n tunnelin ulkopuolelle, näyttää reititystaulussa täydelliseltä ja epäonnistuu silti jokaisessa sisäisessä nimessä.

Toimintamalli: valitse, ota käyttöön, varmista

Aloita vaatimuksesta, älä valikosta. Jos tavoite on vain tämä sovellus saa käyttää tunnelia, tarvitset sovellussäännöt ja alustan, joka tukee niitä. Jos tavoite on nämä verkot ovat tavoitettavissa tunnelin kautta, tarvitset etuliitteitä. Jos vastaus on molemmat, toteuta ne kahtena erillisenä ohjaimena ja kirjaa, kumpi omistaa minkä vian.

Käytä kapeinta muotoa, jonka voit ilmaista, ja varmista sitten kysymällä reititystaululta eikä asiakkaan tilakuvakkeelta:

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

Kaksi ensimmäistä riviä nimeävät rajapinnan, jota todellinen kohde käyttäisi; wg show tulostaa määritetyn etuliiteluettelon; Windowsissa Find-NetRoute vastaa samaan kysymykseen, johon pino vastaa pakettia lähetettäessä. Jos rajapinta on tunneli, sääntö osui.

Testaa sitten toinen paketti, joka pitäisi jättää pois, toisesta sovelluksesta, samaan kohteeseen. Kirjaa tikettiin asiakasversio, säännön tyyppi, etuliite- tai pakettiluettelo ja kaksi havaittua tulosta. Juuri tämä tulos pari kertoo seuraavalle insinöörille, onko käytäntö väärin määritetty vai eikö liikenne koskaan kuulunut sille.