Кой инструмент за macOS може да принуди едно приложение да минава само през VPN?

Един ред в документ с изисквания — „това приложение може да използва VPN и нищо друго“ — тихо иска два механизма, които нито един ключ не предоставя. Трафикът се нуждае от път през предвидения тунел, а трафикът, който би излязъл директно, трябва да бъде отказан. Инструментите, които правят едното добре, а другото съвсем не, са често срещани, затова сравнение, което пита само дали нещо може да блокира, уверено отговаря на половината въпрос. Първо запишете границата, след което изберете компонентите, които покриват двете ѝ половини.

Две изисквания, скрити в едно изречение

Насочването е частта, която поставя връзката в тунела или проксито. Отказът е частта, която спира същата връзка да излезе по друг маршрут. Различни компоненти ги реализират, те се провалят по различен начин и един продукт може да е отличен в едното, без да казва нищо за другото:

Четете таблицата като контролен списък, а не като класация. Нито един ред не запълва двете средни колони, а редовете, които ги покриват, са два компонента, които си сътрудничат: единият притежава пътя, другият — отказа. Колоната за идентичност е важна по друга причина, защото правило, което не може да назове приложението, не може да наложи правило за това приложение. Каквото и да внедрите, то трябва да отговаря на трите, иначе границата в документа с изисквания не е границата на машината.

Насочването само по себе си оставя изход

Настройката на прокси на ниво приложение е най-ясният пример за насочване без отказ. Тя може да насочва заявки от приложение, което зачита системното прокси, и не покрива нищо друго: помощен процес, програма за обновяване, фонова услуга или друг протокол могат да минат по свой път, без изобщо да прочетат тази настройка. Затова избирането на SOCKS крайна точка в един панел не създава политика за забрана на директен изход за приложението. Ако изискването е за приложението като цяло, попитайте кои компоненти правилото действително идентифицира.

Профилът за VPN за отделно приложение насочва по-добре от прокси, защото платформата решава кои приложения влизат в тунела вместо всяко приложение да решава само. И все пак той не отказва нищо: профилът дава път, а трафикът, който не му съответства, поема обичайния маршрут. Точно тази празнина е мястото, където вторият компонент заслужава своето място, и затова продуктите, които изглеждат като един ключ, обикновено са два.

Отказът сам по себе си чупи приложението

Документацията на Apple за филтрите на съдържание описва присъда „разреши или блокирай“ върху трафика, докато той минава през мрежовия стек. Тази присъда не е тунел и не е прокси връзка, защото решава дали нещо може да продължи, а не накъде отива. Филтърът сам по себе си прилага отказа перфектно и оставя приложението неизползваемо, с чисти журнали и без обяснение. Присъдата на филтъра може да спре връзка, но никога не дава тунела, затова съчетаването ѝ с насочване е дизайнерско решение, а не допълнителна опция.

Локално управляваният набор от правила на PF стои в другия край на този спектър. Това е законно решение за поддръжка на машина, която администратор притежава, и не е автоматично основата на разпространяван продукт, защото който притежава набора от правила, притежава и взаимодействията му с другите потребители на защитната стена, пътя му за надграждане и възстановяването му, когато правило е грешно. Добавянето на PF към продукт не премахва този въпрос за собственост; то го дефинира.

Внедряването решава дали правилото ще съществува утре

Как се внедрява Network Extension на платформите на Apple зависи от типа доставчик, пакетирането и версията на операционната система пред вас. Разширението на приложение в macOS работи в потребителски контекст и приключва, когато този потребител излезе, докато системното разширение има глобален контекст, който не зависи от сесията. Ако защитата трябва да оцелее след излизане, тази разлика е целият дизайн, а не бележка под линия. Потвърдете пътя на внедряване, преди да обещавате поведението, защото същият код каца различно в зависимост от типа разширение.

Наличността на изходния код е отделен въпрос от налагането. Четенето на хранилище ви казва как нещо е реализирано, а не какво инсталираният двоичен файл има право да прави на тази машина. Подписването, инсталирането и оторизацията все още важат, а инструкциите около остаряло разширение на ядрото или трик с инжектиране на библиотека описват друга платформа и друга позиция спрямо риска, колкото и добре да са работили някога.

Приемателен случай, който назовава приложението

Изберете едно действие, което приложението извършва само, отбележете адреса, който трябва да достигне, и дали този адрес е IPv4 или IPv6, след което повторете същото действие в одобреното състояние без тунел. Второто изпълнение трябва да даде обявения отказ, а не тих директен опит. Това е половината, която хората оставят неуточнена, и единствената половина, която доказва, че отказ изобщо съществува. Изпълнете го първо с наличен тунел, така че разлика между двата резултата да може да идва само от липсващия тунел.

След това преминете през преходите, които изискването назовава: рестартиране на приложението, задействане на помощен процес, повторно свързване на тунела, смяна на мрежите от машината и излизане или рестарт, където е приложимо. Страницата с публичен IP в браузър не е тест на сокетите на друго приложение, затова не може да замени този тест. Където никое поддържано внедряване не покрива реалното поведение на приложението, оторизирана изолирана среда с явен шлюз и без алтернативен изход е решение за ограничаване със собствени разходи за управление, а не заместител на отметка.

Завършете, като запишете четири точки: кои компоненти изграждат приложението, кой притежава насочването, кой притежава отказа и състоянията, в които правилото трябва да важи. Публичното хранилище може да е един критерий за избор, но не е една от четирите, и именно тези точки решават дали даден инструмент отговаря на изискването за мрежата.