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

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

Две барања скриени во една реченица

Насочувањето е делот што врската го става во тунелот или проксито. Одбивањето е делот што спречува истата врска да излезе по кој било друг пат. Ги спроведуваат различни компоненти, тие пропаѓаат на различни начини, и производот може да биде одличен во едното, а да не каже ништо за другото:

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

Самото насочување остава излез

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

Профилот за VPN по апликација насочува подобро од прокси, бидејќи платформата одлучува кои апликации влегуваат во тунелот наместо секоја апликација да одлучува сама. Сепак не одбива ништо: профилот дава пат, а сообраќајот што не се совпаѓа со него оди по вообичаениот пат. Токму таа празнина е местото каде втората компонента го заслужува своето место, и затоа производите што изгледаат како еден прекинувач обично се два.

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

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

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

Распоредувањето одлучува дали правилото ќе постои и утре

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

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

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

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

Потоа поминете низ премините што ги именува барањето: рестартирање на апликацијата, активирање на помошен процес, повторно поврзување на тунелот, промена на мрежите на машината и одјавување или рестарт каде што се применуваат. Страницата со јавна IP во прелистувач не е тест на приклучоци на друга апликација, затоа не може да го замени овој. Каде што ниту едно поддржано распоредување не го покрива вистинското однесување на апликацијата, авторизирано изолирано опкружување со јасен портал и без алтернативен излез е одлука за задржување со сопствен трошок за управување, а не замена за поле за избор.

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