Блокировка VPN через PF на Mac: политика площадки, а не поставляемая функция

Это работает на вашем Mac, поэтому кажется чем-то, что можно передать пользователям. С этим допущением нужно расстаться первым делом. В документе Apple TN3165 прямо сказано, что Packet Filter не является поддерживаемым API для широко распространяемых продуктов, и привилегированное, контролируемое администрирование площадки рассматривается как разумный случай. Поэтому блокировка VPN на основе PF — это локальная операционная политика с владельцем, а не функция, которую можно поставить внутри приложения.

PF — это не поверхность упаковки

Различие не академическое. Распространяемый продукт, зависящий от PF, наследует каждое изменение, которое Apple в него вносит, каждый конфликт с другим инструментом, который тоже пишет правила, и никаких обязательств поддержки, что эта схема продолжит работать. Площадка, которая администрирует свои машины, имеет другое отношение: она может документировать зависимость, проверять её на каждом выпуске ОС и принимать обслуживание.

Некоторые советы по установке пересекают черту, которую стоит назвать. Перезапись всего системного набора правил ради загрузки одного якоря, правка системной конфигурации запуска Apple или отключение System Integrity Protection не являются приемлемыми требованиями для многоразового рецепта. Если опубликованное руководство требует чего-либо из этого, оно описывает лабораторию, а не развёртываемую политику.

Запишите замысел исходящего трафика до синтаксиса

Решите, что разрешено, прежде чем выбирать одно ключевое слово. Обычно должны существовать три пути: собственный транспорт VPN-клиента к его серверу, защищённый трафик приложения внутри туннеля и всё, что настройке или локальным службам действительно требует прямого пути.

Каждому предлагаемому исключению дайте назначение, транспорт и владельца. Разрешение всех портов к одной конечной точке допускает гораздо больше, чем единственный транспорт, который использует туннель, и дополнительная экспозиция появляется без чьего-либо решения о том, что так и должно быть. Разрешение публичного резолвера — та же ловушка в более дружелюбном обличье: она создаёт прямой путь DNS даже при опущенном туннеле, поэтому запросы имён всё равно утекают.

Полезная проверка исключения — можете ли вы назвать человека, который его попросил, и сбой, который оно предотвращает. Если ни одного ответа нет, правило, вероятно, обходит неправильную конфигурацию, которая иначе осталась бы незаметной.

Номера utun — это не идентичность

MacOS создаёт туннельные интерфейсы как устройства utun, а номер, назначенный вашему VPN, не стабилен между перезагрузками, переподключениями или при наличии другого клиента. Правило, перечисляющее несколько угаданных номеров, — это не политика; это снимок одного дня.

Привяжите правило к чему-то, что идентифицирует предполагаемого провайдера: план адресов, который назначает туннель, процесс, владеющий интерфейсом, или конфигурация, которую поддерживает сам VPN-клиент. Затем запишите, как работает эта идентификация, потому что человек, который через год будет проверять правило, не будет иметь вашей истории shell.

Сделайте загруженную политику атрибутируемой

Имя якоря упорядочивает правила; оно не доказывает, что действующая политика — та, которую вы задумали. Приоритет между якорями, правила, загруженные другим ПО, и существующее состояние — всё это может изменить результат. Просмотрите действующий набор вместе со всеми, кто тоже владеет PF на этой машине, и задокументируйте владение там же, где конфигурация. Два владельца, редактирующие разные якоря с разными допущениями, — обычный способ, которым в блокировке появляется дыра.

Держите набор правил в поддерживаемом пути конфигурации площадки, версионируйте его и отмечайте, какие выпуски macOS были проверены. Изменение, применяемое вручную и запоминаемое одним человеком, не является обслуживаемой инфраструктурой, что бы ни говорил заголовок файла.

Проверяйте переходы, а не подключённое состояние

Снимок экрана, сделанный при работающем туннеле, почти ничего не доказывает. Пройдите по состояниям: запуск до любого подключения, работающий туннель, туннель, который падает без предупреждения, намеренное отключение и переход с Wi-Fi на точку доступа. У каждого состояния свой ответ, и интересны именно сбои, а не благополучный путь.

В каждом состоянии фиксируйте, что намеренно достижимо. Проверяйте IPv4 и IPv6 отдельно, тестируйте разрешение имён и включайте поток, который уже был установлен до перехода, поскольку существующие соединения не всегда следуют новой политике. Браузер, который не работает при опущенном туннеле, — это одна точка данных, а не доказательство, что все остальные пути заблокированы.

Наконец, держите метод восстановления, не зависящий от сетевого пути, который вы меняете. Известная рабочая конфигурация в локальном хранилище и документированный способ её загрузить превращают блокировку в политику; без них одна плохая ревизия запирает администратора вне машины, которую предполагалось защитить.