Који macOS алат може присилити једну апликацију да иде само кроз VPN?

Један ред у документу захтева — „ова апликација сме да користи VPN и ништа друго“ — тихо тражи два механизма која не даје ниједан прекидач. Саобраћају треба пут кроз предвиђени тунел, а саобраћај који би изашао директно мора бити одбијен. Алати који једно раде добро, а друго уопште не, чести су, зато поређење које пита само да ли нешто може да блокира сигурно одговара на половину питања. Прво запишите границу, затим изаберите компоненте које покривају обе њене половине.

Два захтева скривена у једној реченици

Усмеравање је део који ставља везу у тунел или прокси. Одбијање је део који спречава исту везу да изађе било којим другим путем. Спроводе их различите компоненте, оне отказују на различите начине, и производ може бити одличан у једном, а да не каже ништа о другом:

Читајте табелу као контролну листу, а не као ранг. Ниједан ред не попуњава обе средње колоне, а редови који их покривају су две компоненте које сарађују: једна поседује пут, друга одбијање. Колона идентитета је важна из другог разлога, јер правило које не може да именује апликацију не може да спроведе правило о тој апликацији. Шта год да примените, мора да одговори на сва три, иначе граница у документу захтева није граница на машини.

Само усмеравање оставља излаз

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

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

Само одбијање квари апликацију

Документација Apple-а о филтерима садржаја описује пресуду дозволи-или-блокирај за саобраћај док пролази кроз мрежни стек. Та пресуда није тунел нити прокси веза, јер одлучује да ли нешто сме да настави, а не куда иде. Филтер сам по себи беспрекорно спроводи одбијање и оставља апликацију неупотребљивом, са чистим дневницима и без објашњења. Пресуда филтера може да заустави везу, али никада не даје тунел, зато је њено спајање са усмеравањем дизајнерска одлука, а не опциона додатак.

Локално управљан скуп PF правила стоји на другом крају тог спектра. То је легитимна одлука подршке на машини коју поседује администратор и није аутоматски основа производа који се дистрибуира, јер онај који поседује скуп правила поседује и његове интеракције са другим корисницима заштитног зида, пут надоградње и опоравак када је правило погрешно. Додавање PF-а производу не уклања то питање власништва; оно га дефинише.

Распоређивање одлучује да ли ће правило постојати и сутра

Како се Network Extension распоређује на Apple платформама зависи од типа добављача, паковања и верзије оперативног система пред вама. Проширење апликације на macOS ради у корисничком контексту и завршава се када се тај корисник одјави, док системско проширење има глобални контекст који не зависи од сесије. Ако заштита мора да преживи одјаву, та разлика је цео дизајн, а не фуснота. Потврдите пут распоређивања пре него што обећате понашање, јер исти код слеће другачије зависно од тога који се тип проширења испоручује.

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

Случај прихватања који именује апликацију

Изаберите једну радњу коју апликација сама извршава, забележите адресу коју треба да достигне и да ли је та адреса IPv4 или IPv6, затим поновите исту радњу у одобреном стању без тунела. Друго извршавање мора да да објављено одбијање, а не тихи директни нови покушај. То је половина коју људи остављају неодређену и једина половина која доказује да одбијање уопште постоји. Извршите је прво са доступним тунелом, како би разлика између два резултата могла да дође само од тунела који недостаје.

Затим прођите кроз прелазе које захтев именује: поновно покретање апликације, активирање помоћног процеса, поновно повезивање тунела, промену мрежа на машини и одјаву или поновно покретање где се примењују. Страница са јавном IP адресом у прегледачу није тест прикључака друге апликације, зато не може да замени овај. Тамо где ниједно подржано распоређивање не покрива стварно понашање апликације, ауторизовано изоловано окружење са јасним пролазом и без алтернативног излаза је одлука о задржавању са сопственим трошком управљања, а не замена за поље за потврду.

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