Mac PF VPN заклучување: локална политика, а не функција што се испорачува

Тоа работи на вашиот Mac, па изгледа како нешто што можете да им го предадете на корисниците. Оваа претпоставка е првото нешто што треба да го загубите. Apple TN3165 јасно наведува дека Packet Filter не е поддржан API за општо дистрибуирани производи, и привилегираната, контролирана администрација на локацијата ја смета за разумен случај. Затоа VPN заклучување изградено на PF е локална оперативна политика со сопственик, а не функција што можете да ја испорачате во апликација.

PF не е површина за пакување

Разликата не е академска. Дистрибуиран производ што зависи од PF го наследува секој промена што Apple ја прави во него, секој конфликт со друг алат што исто така пишува правила, и никаква поддршка дека оваа поставеност ќе продолжи да работи. Локацијата што ги администрира своите машини има поинаков однос: таа може да ја документира зависноста, да ја тестира со секое издание на ОС и да го прифати одржувањето.

Некои совети за инсталација ја преминуваат границата што вреди да се именува. Препишувањето на целото системско множество правила за да се вчита еден анкер, уредувањето на системската конфигурација за стартување на Apple или оневозможувањето на System Integrity Protection не се прифатливи барања за рецепт што се користи повеќепати. Ако објавен водич бара било што од тоа, тој опишува лабораторија, а не политика што може да се распореди.

Запишете ја намерата за излез пред синтаксата

Одлучете што е дозволено пред да изберете еден клучен збор. Обично треба да постојат три патеки: сопствениот транспорт на VPN клиентот до неговиот сервер, заштитениот сообраќај на апликацијата внатре во тунелот и сите поставувања или локални услуги што навистина бараат директен пат.

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

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

utun броевите не се идентитет

MacOS создава тунелски интерфејси како utun уреди, а бројот доделен на вашиот VPN не е стабилен низ рестартирања, повторни поврзувања или присуство на друг клиент. Правило што наведува неколку претпоставени броеви не е политика; тоа е снимка од едно попладне.

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

Направете ја вчитаната политика да може да се припише

Името на анкерот организира правила; тоа не докажува дека ефективната политика е онаа што ја сакавте. Приоритетот меѓу анкерите, правилата што ги вчитал друг софтвер и постојната состојба можат да го променат исходот. Прегледајте го ефективното множество со сите други што управуваат со PF на таа машина и документирајте го сопствеништвото на истото место како конфигурацијата. Двајца сопственици што уредуваат различни анкери со различни претпоставки се вообичаениот начин на кој заклучувањето добива дупка.

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

Тестирајте ги премините, а не поврзаната состојба

Снимка од екранот направена додека тунелот е активен речиси ништо не докажува. Минете низ состојбите: стартување пред било каква врска, работен тунел, тунел што паѓа без предупредување, намерно исклучување и премин од Wi-Fi на мобилен хотспот. Секоја состојба има свој одговор, а интересните се неуспесите, а не среќниот пат.

Во секоја состојба запишете што е намерно достапно. Проверете IPv4 и IPv6 одделно, тестирајте го разрешувањето на имиња и вклучете тек што веќе бил воспоставен пред преминот, бидејќи постојните врски не секогаш ја следат новата политика. Прелистувач што не успева додека тунелот е паднат е една точка на податоци, а не доказ дека сите други патеки се блокирани.

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