Блокування 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-клієнт. Потім запишіть, як працює ця ідентифікація, бо людина, яка за рік перевірятиме правило, не матиме вашої історії оболонки.

Зробіть завантажену політику атрибутованою

Назва якоря впорядковує правила; вона не доводить, що чинна політика саме та, яку ви задумали. Пріоритет між якорями, правила, завантажені іншим програмним забезпеченням, і наявний стан можуть змінити результат. Перегляньте чинний набір разом з усіма іншими, хто володіє PF на цій машині, і задокументуйте власність там само, де конфігурація. Два власники, що редагують різні якорі з різними припущеннями, — звичний спосіб, у який блокування отримує діру.

Тримайте набір правил у підтримуваному шляху конфігурації майданчика, версіонуйте його та позначайте, які випуски macOS перевірено. Зміна, застосована вручну й запам'ятована однією людиною, не є інфраструктурою, що обслуговується, хоч би що казав заголовок файлу.

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

Знімок екрана, зроблений під час роботи тунелю, майже нічого не доводить. Пройдіть станами: запуск до будь-якого підключення, робочий тунель, тунель, що падає без попередження, навмисне від'єднання та перехід з Wi-Fi на точку доступу. Кожен стан має власну відповідь, і цікавими є саме збої, а не благополучний шлях.

У кожному стані фіксуйте, що навмисно доступне. Перевіряйте IPv4 та IPv6 окремо, тестуйте розв'язання імен і включайте потік, який уже був встановлений до переходу, оскільки наявні з'єднання не завжди дотримуються нової політики. Браузер, що не працює при опущеному тунелі, — це одна точка даних, а не доказ, що всі інші шляхи заблоковані.

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