Split tunneling заснован на апликацији или на одредишту: шта изабрати

Split tunneling заснован на апликацији и на одредишту нису две поставке за исти посао. Једно пита који процес шаље пакет; друго пита куда тај пакет иде. Правило направљено за прво питање тихо отказује када саобраћај долази из помоћног процеса, а правило за друго отказује када се име хоста разреши у адресу коју никада нисте навели. Изаберите објекат који одговара захтеву и докажите то двама тестним пакетима: један мора да користи тунел, други не сме.

Два правила делују на различитим слојевима

Правило апликације примењује се изнад мрежног слоја, према идентитету који оперативни систем додељује пошиљаоцу. На Android-у то је UID иза пакета, а VPN сервис одлучује по UID-у да ли саобраћај улази у тунел. О одредишту се ништа не пита, па изабрана апликација може да достигне било шта, а ниједна друга апликација не може да достигне интерну мрежу.

Правило одредишта примењује се на сам пакет. Интерфејс тунела поседује скуп префикса, табела рутирања шаље одговарајући саобраћај у њега, а процес који шаље је небитан. Зато правило одредишта покрива услугу, штампач или batch посао који се нико није сетио да наведе, и зато се не може изразити као баш овај програм на платформи чији клијент никада не гледа процес.

Правила апликација одговарају мобилним клијентима и управљаним агентима

Android излаже избор директно: VpnService.Builder.addAllowedApplication() и addDisallowedApplication() узимају имена пакета и примењују одлуку по UID-у, као што је описано у водичу за VPN програмере за Android. iOS има еквивалент кроз VPN правила по апликацији везана за идентификаторе пакета, обично достављена кроз MDM профил, а не откуцана ручно.

Десктоп клијенти су слабо место. Већина Windows и macOS VPN клијената рутира по одредишту и уопште не нуди бирач по процесу, јер драјвер тунела види пакете, не процесе. Ако ваш план зависи од тунеловање једне апликације на преносном рачунару, проверите стварне могућности клијента пре него што дизајнирате око тога; можда бирате између листе одредишта и другог рачунара.

Последица коју људи пропуштају: на тим платформама не можете да имитирате правило апликације рутама. Додавање host руте за сервер апликације тунелује саобраћај свих према том серверу, укључујући прегледач и програм за ажурирање.

Правила одредишта одговарају листама подмрежа и доступности локација

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 одговара на исто питање на које ће стек одговорити када пакет буде послат. Ако је интерфејс тунел, правило се поклопило.

Затим тестирајте други пакет који треба да буде изузет, из друге апликације, на исто одредиште. Забележите у тикету верзију клијента, тип правила, листу префикса или пакета и два посматрана резултата. Управо тај пар резултата каже следећем инжењеру да ли је политика погрешно конфигурисана или саобраћај никада није ни припадао њој.