Rakendusepõhine vs sihtkohapõhine split tunneling: kumba valida

Rakendusepõhine ja sihtkohapõhine split tunneling ei ole sama töö jaoks kaks seadet. Üks küsib, milline protsess paketi saadab; teine küsib, kuhu see pakett läheb. Esimese küsimuse jaoks ehitatud reegel ebaõnnestub vaikselt, kui liiklus tuleb abiprotsessist, ja teise jaoks ehitatud reegel ebaõnnestub, kui hostinimi laheneb aadressiks, mida te kunagi ei lisanud. Valige nõudele vastav objekt ja tõestage seda kahe testpaketiga: üks peab tunnelit kasutama ja teine ei tohi.

Kaks reeglit toimivad eri kihtidel

Rakenduse reegel rakendub võrgukihi kohal, identiteedi vastu, mille operatsioonisüsteem saatjale omistab. Androidis on see paketi taga olev UID ja VPN-teenus otsustab iga UID kohta, kas liiklus siseneb tunnelisse. Sihtkoha kohta ei küsita midagi, seega valitud rakendus pääseb kõikjale ja ükski teine rakendus ei pääse sisemisesse võrku.

Sihtkoha reegel rakendub paketi enda peal. Tunneli liides omab prefiksite kogumit, marsruutimistabel saadab sobiva liikluse sinna ja saatja protsess ei loe. Seetõttu katab sihtkoha reegel teenuse, printeri või pakktöö, mida keegi ei mäletanud lisada, ja seetõttu ei saa seda platvormil, mille klient ei vaata kunagi protsessi, väljendada kui täpselt see programm.

Rakenduse reeglid sobivad mobiiliklientidele ja hallatavatele agentidele

Android pakub valiku otse: VpnService.Builder.addAllowedApplication() ja addDisallowedApplication() võtavad paketinimesid ja rakendavad otsust iga UID kohta, nagu on kirjeldatud Androidi VPN-i arendajajuhendis. iOS-il on vaste rakendusepõhiste VPN-reeglite kaudu, mis on seotud komplekti identifikaatoritega ja mida tavaliselt edastatakse MDM-profiiliga, mitte ei trükita käsitsi.

Töölauakliendid on nõrk koht. Enamik Windowsi ja macOS-i VPN-kliente marsruudib sihtkoha järgi ega paku üldse protsessipõhist valijat, sest tunneli draiver näeb pakette, mitte protsesse. Kui teie plaan sõltub ühe rakenduse tunnelist sülearvutis, kontrollige kliendi tegelikke võimalusi enne, kui selle ümber disainite; võib-olla valite sihtkohtade loendi ja teise masina vahel.

Järeldus, mida inimesed sageli märkavad: neil platvormidel ei saa rakenduse reeglit marsruutidega jäljendada. Rakenduse serveri jaoks hostimarsruudi lisamine tunnelib kõigi liikluse sellesse serverisse, kaasa arvatud brauser ja uuendaja.

Sihtkoha reeglid sobivad alamvõrkude loenditele ja saitide kättesaadavusele

WireGuard teeb mudeli selgeks. AllowedIPs on krüptovõtme marsruutimine: sisemine pakett, mille sihtkoht jääb partneri loendi sisse, krüpteeritakse selle partneri jaoks, ja kõik muu väljub krüpteerimata tavalisel teel. Pole protsessi, mida nimetada, ega ebaselgust selle üle, mis on hõlmatud.

OpenVPN jõuab samasse kohta läbi surutud marsruutimistabeli. route-nopull takistab serveril marsruute dikteerida, mille järel kliendipoolne route 10.20.0.0 255.255.0.0 vpn_gateway katab täpselt kontori prefiksi. IPv6 on igaühes neist klientidest eraldi lause ja selle unustamine on kõige tavalisem viis lekkida ümber korrektselt näiva IPv4 spliti.

Hostinimi ei ole marsruut. Kui profiil pakub domeenivälja, käsitlege seda nimena, mille klient lahendab üks kord, mitte püsiva aadressivahemikuna; sisu edastamise võrgud ja koormusjaoturid annavad homme teistsugused aadressid.

Kus mõlemad mudelid murduvad: abilised, jagatud teenused, lahendajad

Abiprotsessid rikuvad rakenduse reegleid nii, et see näeb välja nagu serveri tõrge. Brauseri uuendaja, krahhiaruandja, SYSTEM-na töötav sünkroonimisteenus ja teise paketti põimitud WebView on kõik eraldi identiteedid, seega brauseri tunnelimine võib tegeliku päringu jätta tunnelist välja. Vastupidine on sama segane: välistatud rakendus, mis kutsub tunnelitud protsessi sees jagatud teeki, saab ikka oma liikluse tunnelisse.

Sihtkoha reeglid murduvad jagatud teenustel ja nimedel. Failijagamised, printerid, sisemine DNS ja litsentsiserver asuvad kõik aadressidel, seega ühe rakenduse tunnel annab brauserile juurdepääsu, samal ajal kui kaardistatud ketas jääb surnuks. See katvuse erinevus ei ole kummagi mudeli viga, kuid just seetõttu annab ühe rakenduse tunnel nii sageli VPN töötab ja jagamine on kadunud.

Lahendajad lõikavad mõlemat. Kui klient seab sisemised DNS-serverid, aga operatsioonisüsteem kasutab DNS-i üle HTTPS-i avaliku lahendaja vastu, tuleb vastus väljastpoolt tunnelit ja sihtkoha reegel ei pruugi kunagi sobida. Kontrollige, milline lahendaja tegelikult vastas, enne kui järeldate, et reegel on vale, ja kinnitage kliendi poolel, kas see üldse paigaldas tunneli lahendaja. Split, mis jätab DNS-i tunnelist välja, näeb marsruutimistabelis täiuslik välja ja ebaõnnestub ikkagi igal sisemisel nimel.

Tegevuskava: vali, rakenda, kontrolli

Alustage nõudest, mitte menüüst. Kui eesmärk on ainult see rakendus tohib tunnelit kasutada, vajate rakenduse reegleid ja platvormi, mis neid toetab. Kui eesmärk on need võrgud on tunneli kaudu kättesaadavad, vajate prefikseid. Kui vastus on mõlemad, rakendage neid kahe eraldi juhtimisena ja kirjutage üles, milline neist vastutab millise tõrke eest.

Rakendage kitsaim vorm, mida suudate väljendada, ja kontrollige seejärel, küsides marsruutimistabelilt, mitte kliendi olekukoonilt:

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

Kaks esimest rida nimetavad liidese, mida tegelik sihtkoht kasutaks; wg show prindib seadistatud prefiksite loendi; Windowsis vastab Find-NetRoute samale küsimusele, millele pinu vastab paketi saatmisel. Kui liides on tunnel, siis reegel sobis.

Seejärel testige teist paketti, mis peaks olema välistatud, teisest rakendusest, samasse sihtkohta. Kirjutage pileti sisse kliendi versioon, reegli tüüp, prefiksite või pakettide loend ja kaks täheldatud tulemust. Just see tulemuste paar ütleb järgmisele insenerile, kas poliitika on valesti seadistatud või ei kuulunud liiklus kunagi selle alla.