Спліт-тунэляванне паводле праграмы і паводле прызначэння: што выбраць

Спліт-тунэляванне паводле праграмы і паводле прызначэння не два налады для адной задачы. Адно пытае, які працэс адпраўляе пакет; другое пытае, куды гэты пакет ідзе. Правіла, пабудаванае пад першае пытанне, ціха адмаўляе, калі трафік ідзе ад дапаможнага працэса, а правіла пад другое пытанне адмаўляе, калі імя хоста разрозніваецца ў адрас, якога вы ніколі не ўносілі. Выберыце аб'ект, які адпавядае патрабаванню, і дакажыце гэта двума тэставымі пакетамі: адзін мусіць ісці праз тунель, другі не.

Два правілы дзейнічаюць на розных узроўнях

Правіла праграмы выконваецца вышэй за сеткавы ўзровень, супраць ідэнтычнасці, якую аперацыйная сістэма прысвойвае адпраўніку. На Android гэта UID за пакетам, і служба VPN вырашае для кожнага UID, ці трапляе трафік у тунель. Пра прызначэнне нічога не пытаюцца, таму абраная праграма дасягае чаго заўгодна, а ніводная іншая праграма не дасягае ўнутранай сеткі.

Правіла прызначэння выконваецца на самім пакеце. Інтэрфейс тунеля валодае наборам прэфіксаў, табліца маршрутызацыі накіроўвае туды адпаведны трафік, а працэс-адпраўнік не мае значэння. Таму правіла прызначэння ахоплівае службу, прынтар або пакетную задачу, якую ніхто не ўспомніў унесці, і таму яго нельга выказаць як менавіта гэтая праграма на платформе, чый кліент ніколі не глядзіць на працэс.

Правілы праграм падыходзяць для мабільных кліентаў і кіраваных агентаў

Android паказвае выбар непасрэдна: VpnService.Builder.addAllowedApplication() і addDisallowedApplication() прымаюць імёны пакетаў і выконваюць рашэнне для кожнага UID, як апісана ў кіраўніцтве распрацоўшчыка VPN для Android. У iOS ёсць эквівалент праз правілы VPN для кожнай праграмы, прывязаныя да ідэнтыфікатараў пакетаў, звычайна дастаўляемыя профілем MDM, а не набраныя ўручную.

Кліенты для настольных камп'ютараў слабое месца. Большасць кліентаў VPN для Windows і macOS маршрутызуюць па прызначэнні і зусім не прапануюць выбар па працэсе, бо драйвер тунеля бачыць пакеты, а не працэсы. Калі ваш план залежыць ад тунэлявання адной праграмы на ноўтбуку, праверце фактычныя магчымасці кліента, перш чым будаваць вакол гэтага; магчыма, вы выбіраеце паміж спісам прызначэнняў і другой машынай.

Выснова, якую часта ўпускаюць: на гэтых платформах нельга імітаваць правіла праграмы маршрутамі. Даданне маршруту да хоста сервера праграмы тунэлюе трафік усіх да гэтага сервера, уключаючы браўзер і абнаўляльнік.

Правілы прызначэння падыходзяць для спісаў падсетак і дасягальнасці сайтаў

WireGuard робіць мадэль відавочнай. AllowedIPs гэта маршрутызацыя па крыптаключы: унутраны пакет, прызначэнне якога патрапляе ў спіс суседа, шыфруецца да гэтага суседа, а ўсё астатняе выходзіць незашыфраваным звычайным шляхам. Няма працэса, які трэба назваць, і няма нявызначанасці ў тым, што ўключана.

OpenVPN дасягае таго ж праз прадпісаную табліцу маршрутаў. route-nopull спыняе дыктоўку маршрутаў серверам, пасля чаго кліенцкі route 10.20.0.0 255.255.0.0 vpn_gateway ахоплівае менавіта офісны прэфікс. IPv6 асобны радок ва ўсіх гэтых кліентах, і забыцца пра яго самы распаўсюджаны спосаб уцечкі вакол правільнага на выгляд раздзялення IPv4.

Імя хоста не маршрут. Калі профіль прапануе поле дамена, стаўцеся да яго як да імені, якое кліент разрознівае адзін раз, а не як да пастаяннага дыяпазону адрасоў; сеткі дастаўкі кантэнту і балансавальнікі нагрузкі заўтра выдадуць іншыя адрасы.

Дзе ламаюцца абедзве мадэлі: дапаможныя працэсы, агульныя службы, рашальнікі

Дапаможныя працэсы ламаюць правілы праграм так, што выглядае як збой сервера. Абнаўляльнік браўзера, паведамляльнік пра збоі, служба сінхранізацыі пад SYSTEM і WebView, убудаваны ў іншы пакет, усё гэта асобныя ідэнтычнасці, таму тунэляванне браўзера можа пакінуць фактычны запыт па-за тунелем. Зваротнае гэтак жа заблытанае: выключаная праграма, якая выклікае агульную бібліятэку ўнутры тунэляванага працэса, усё адно мае трафік у тунелі.

Правілы прызначэння ламаюцца на агульных службах і на імёнах. Сеткавыя дыскі, прынтары, унутраны DNS і сервер ліцэнзій жывуць на адрасах, таму тунель адной праграмы дае браўзеру доступ, а падключаны дыск застаецца мёртвым. Гэтая розніца пакрыцця не памылка ні ў адной мадэлі, але менавіта яна робіць так, што тунель адной праграмы часта дае VPN працуе, а дыск знік.

Рашальнікі перасякаюць абодва. Калі кліент задае ўнутраныя DNS-серверы, але аперацыйная сістэма выкарыстоўвае DNS праз HTTPS да публічнага рашальніка, адказ прыходзіць з-за тунеля, і правіла прызначэння можа ніколі не супасці. Праверце, які рашальнік фактычна адказаў, перш чым рабіць выснову, што правіла няправільнае, і пацвердзіце на баку кліента, ці ўсталяваў ён рашальнік тунеля наогул. Раздзяленне, якое пакідае DNS па-за тунелем, выглядае бездакорна ў табліцы маршрутаў і ўсё адно не разрознівае ніводнае ўнутранае імя.

Парадак дзеянняў: выбар, ужыванне, праверка

Пачынайце з патрабавання, а не з меню. Калі мэта толькі гэтая праграма можа выкарыстоўваць тунель, патрэбны правілы праграм і платформа, якая іх падтрымлівае. Калі мэта гэтыя сеткі дасягальныя праз тунель, патрэбны прэфіксы. Калі адказ абодва, рэалізуйце іх як два асобныя кіраванні і запішыце, якое з іх адказвае за які збой.

Прымяніце самую вузкую форму, якую можаце выказаць, затым праверце, пытаючыся ў табліцы маршрутызацыі, а не ў значку стану кліента:

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

Першыя два радкі называюць інтэрфейс, які выкарыстаў бы сапраўдны пункт прызначэння; wg show друкуе наладжаны спіс прэфіксаў; у Windows Find-NetRoute адказвае на тое ж пытанне, на якое адкажа стэк пры адпраўцы пакета. Калі інтэрфейс гэта тунель, правіла супала.

Затым праверце другі пакет, які павінен быць выключаны, з іншай праграмы, да таго ж пункта прызначэння. Запішыце ў тыкет версію кліента, тып правіла, спіс прэфіксаў або пакетаў і два назіраныя вынікі. Менавіта гэтая пара вынікаў кажа наступнаму інжынеру, ці палітыка наладжана няправільна, ці трафік ніколі да яе не належаў.