Split tunneling i bazuar në aplikacion apo në destinacion: cilin të zgjidhni

Split tunneling i bazuar në aplikacion dhe ai i bazuar në destinacion nuk janë dy cilësime për të njëjtën punë. Njëri pyet se cili proces po dërgon një paketë; tjetri pyet se ku po shkon ajo paketë. Një rregull i ndërtuar për pyetjen e parë dështon në heshtje kur trafiku vjen nga një proces ndihmës, dhe një rregull i ndërtuar për të dytën dështon kur një emër hosti zgjidhet në një adresë që nuk e keni listuar kurrë. Zgjidhni objektin që përputhet me kërkesën, pastaj provojeni me dy paketa testuese: njëra duhet të përdorë tunelin dhe tjetra nuk duhet.

Të dy rregullat veprojnë në shtresa të ndryshme

Rregulli i aplikacionit zbatohet mbi shtresën e rrjetit, kundrejt identitetit që sistemi operativ i cakton dërguesit. Në Android ai është UID-ja pas paketës, dhe shërbimi VPN vendos për çdo UID nëse trafiku hyn në tunel. Për destinacionin nuk pyetet asgjë, kështu që aplikacioni i zgjedhur mund të arrijë çdo gjë dhe asnjë aplikacion tjetër nuk mund të arrijë rrjetin e brendshëm.

Rregulli i destinacionit zbatohet mbi vetë paketën. Ndërfaqja e tunelit zotëron një grup prefiksesh, tabela e rrugëzimit dërgon atje trafikun që përputhet, dhe procesi që dërgon është i parëndësishëm. Kjo është arsyeja pse një rregull destinacioni mbulon një shërbim, një printer ose një punë batch që askush nuk e kujtoi të listonte, dhe pse ai nuk mund të shprehet si pikërisht ky program në një platformë klienti i së cilës nuk e shikon kurrë procesin.

Rregullat e aplikacionit përshtaten me klientët celularë dhe agjentët e menaxhuar

Android e ekspozon zgjedhjen drejtpërdrejt: VpnService.Builder.addAllowedApplication() dhe addDisallowedApplication() marrin emra paketash dhe zbatojnë vendimin për çdo UID, siç përshkruhet në udhëzuesin e zhvilluesit të VPN-së të Android. iOS ka një ekuivalent përmes rregullave VPN për çdo aplikacion të bazuara në identifikues bundle, zakonisht të shpërndara nga një profil MDM dhe jo të shtypura me dorë.

Klientët e desktopit janë pika e dobët. Shumica e klientëve VPN për Windows dhe macOS rrugëzojnë sipas destinacionit dhe nuk ofrojnë fare zgjedhës sipas procesit, sepse drejtuesi i tunelit sheh paketa, jo procese. Nëse plani juaj varet nga tunelizimi i një aplikacioni të vetëm në një laptop, kontrolloni aftësitë reale të klientit përpara se të projektoni rreth tij; mbase po zgjidhni midis një liste destinacionesh dhe një makine të dytë.

Një pasojë që njerëzit e humbin: në ato platforma nuk mund të imitoni një rregull aplikacioni me rrugë. Shtimi i një rruge hosti për serverin e aplikacionit e tunelizon trafikun e të gjithëve drejt atij serveri, përfshirë shfletuesin dhe përditësuesin.

Rregullat e destinacionit përshtaten me listat e nënrrjeteve dhe arritshmërinë e sajteve

WireGuard e bën modelin të qartë. AllowedIPs është rrugëzim me çelës kriptografik: një paketë e brendshme, destinacioni i së cilës bie brenda listës së një palë, enkriptohet drejt asaj pale, dhe çdo gjë tjetër del e paenkirptuar në rrugën normale. Nuk ka proces për të emërtuar dhe as paqartësi për atë që përfshihet.

OpenVPN arrin në të njëjtin vend përmes tabelës së rrugëzimit të shtyrë. route-nopull ndalon serverin të diktojë rrugë, pas së cilës një route 10.20.0.0 255.255.0.0 vpn_gateway nga ana e klientit mbulon saktësisht prefiksin e zyrës. IPv6 është një pohim i veçantë në secilin prej këtyre klientëve, dhe harresa e tij është mënyra më e zakonshme për të rrjedhur rreth një ndarjeje IPv4 që duket e saktë.

Një emër hosti nuk është rrugë. Nëse profili ofron një fushë domeni, trajtojeni si një emër që klienti e zgjidh një herë, jo si një interval adresash të përhershëm; rrjetet e shpërndarjes së përmbajtjes dhe balancuesit e ngarkesës nesër do të japin adresa të tjera.

Ku thyhen të dy modelet: ndihmësit, shërbimet e përbashkëta, zgjidhësit

Proceset ndihmëse thyejnë rregullat e aplikacionit në një mënyrë që duket si defekt i serverit. Përditësuesi i një shfletuesi, raportuesi i rrëzimeve, një shërbim sinkronizimi që ekzekutohet si SYSTEM dhe një WebView i integruar në një paketë tjetër janë identitete të veçanta, kështu që tunelizimi i shfletuesit mund ta lërë kërkesën reale jashtë tunelit. E kundërta është po aq konfuze: një aplikacion i përjashtuar që thërret një bibliotekë të përbashkët brenda një procesi të tunelizuar e ka trafikun përsëri në tunel.

Rregullat e destinacionit thyhen në shërbimet e përbashkëta dhe në emra. Ndarjet e skedarëve, printerat, DNS-ja e brendshme dhe serveri i licencave jetojnë në adresa, kështu që një tunel i një aplikacioni i jep shfletuesit akses ndërsa disku i mapuar mbetet i vdekur. Ky ndryshim mbulimi nuk është defekt në asnjë model, por është arsyeja pse një tunel i një aplikacioni prodhon kaq shpesh që VPN-ja është ndezur dhe ndarja ka humbur.

Zgjidhësit i prekin të dyja. Nëse klienti vendos serverë DNS të brendshëm, por sistemi operativ përdor DNS përmes HTTPS drejt një zgjidhësi publik, përgjigja vjen nga jashtë tunelit dhe rregulli i destinacionit mund të mos përputhet kurrë. Kontrolloni cili zgjidhës u përgjigj vërtet përpara se të konkludoni se rregulli është i gabuar, dhe konfirmoni nga ana e klientit nëse e instaloi fare zgjidhësin e tunelit. Një ndarje që e lë DNS-në jashtë tunelit duket përsosmërisht në tabelën e rrugëzimit dhe gjithsesi dështon në çdo emër të brendshëm.

Procedura: zgjidh, zbato, verifiko

Filloni nga kërkesa, jo nga menyja. Nëse qëllimi është vetëm ky aplikacion mund të përdorë tunelin, ju nevojiten rregulla aplikacioni dhe një platformë që i mbështet. Nëse qëllimi është këto rrjete janë të arritshme përmes tunelit, ju nevojiten prefikse. Nëse përgjigja është të dyja, zbatoni ato si dy kontrolle të veçanta dhe shkruani cili zotëron cilën dështim.

Zbatoni formën më të ngushtë që mund të shprehni, pastaj verifikoni duke pyetur tabelën e rrugëzimit në vend të ikonës së statusit të klientit:

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

Dy rreshtat e parë emërtojnë ndërfaqen që do të përdorte një destinacion i vërtetë; wg show printon listën e prefikseve të konfiguruar; në Windows, Find-NetRoute përgjigjet në të njëjtën pyetje që do të përgjigjet stiva kur paketa dërgohet. Nëse ndërfaqja është tuneli, rregulli u përputh.

Pastaj testoni një paketë të dytë që duhet të përjashtohet, nga një aplikacion tjetër, drejt të njëjtit destinacion. Shënoni në tiketë versionin e klientit, llojin e rregullit, listën e prefikseve ose të paketave dhe dy rezultatet e vëzhguara. Pikërisht ai çift rezultatesh i tregon inxhinierit tjetër nëse politika është konfiguruar gabimisht apo nëse trafiku nuk i përkiste kurrë asaj.