VPN на Mac, фильтр контента или Private Relay: что активно
Три сетевых уровня Mac выглядят в Настройках одинаково. Отличите VPN, фильтр контента и Private Relay по пути выхода, политике потоков и охвату просмотра.
На вашем Mac могут одновременно быть установлены туннель VPN, фильтр контента и iCloud Private Relay, и ни один из них не сообщает, какой именно формирует данное соединение. Панели настроек выглядят похоже, значки выглядят похоже, и почти каждый поставщик называет свой продукт сетевой безопасностью. Три факта различают их: выходит ли трафик через удалённую конечную точку, которую вы можете назвать, принимает ли машина политик решения разрешить-или-отбросить по отдельным потокам и заканчивается ли защита на Safari. Разберитесь с этими тремя, и большинство вопросов вида включён-ли-мой-VPN отвечаются сами.
Три условия, по которым опознаётся компонент
Первое условие — выход. Поставщик туннеля передаёт пакеты удалённому шлюзу, поэтому ваш публичный адрес меняется и, если профиль так указывает, хосты за этим шлюзом становятся доступны. Если адрес никогда не меняется и никакая частная подсеть не открывается, вы смотрите не на работающий туннель, что бы ни утверждала строка меню.
Второе условие — решение. Фильтр контента оценивает потоки и возвращает разрешить или отбросить. Он может применять блокировку категории, правило для отдельного приложения или политику, присланную работодателем, и может записывать вердикт. Чего он не может сам, — дать трафику место, куда идти.
Третье условие — охват. Private Relay защищает заданный срез просмотра, а не всё устройство, и его задача — отделить то, кто вы, от того, что вы посещаете, а не поместить вас в другую сеть.
Поставьте их рядом, и границы трудно пропустить:
| Layer | Question it answers | Evidence to look for | What it does not do |
|---|---|---|---|
| VPN tunnel provider | Where does my traffic emerge, and which private networks can I reach? | Changed public address, a connected service, a default route through a utun interface | Enforce per-app content policy |
| Content filter | May this flow proceed, and who decided? | A filter extension in Network Extensions, drop verdicts, an MDM profile | Supply a different public exit |
| iCloud Private Relay | Can the local network see which sites Safari loads? | A relay egress address in Safari only, the relay toggle in iCloud settings | Cover other apps or grant access to a private subnet |
Фильтр контента — это машина политик, а не выход
В macOS фильтр приходит как Network Extension, построенное на классе поставщика данных фильтрации Apple NEFilterDataProvider. В управляемом развёртывании его проталкивает MDM, он устанавливается как системное расширение и один раз одобряется в System Settings > General > Login Items and Extensions. С этого момента он видит потоки TCP, а в некоторых конфигурациях и UDP, и возвращает вердикт по каждому.
Путаницу вызывает именно режим отказа. Фильтр, отбрасывающий поток, даёт тайм-аут, зависшее рукопожатие TLS или сброс, и это выглядит в точности как туннель, который поднялся, но не пропускает трафик. Публичный адрес не менялся, потому что менять его было нечем.
Коммерческие клиенты часто объединяют обе роли. Один установщик приносит и поставщика туннеля, и фильтр: фильтр блокирует, а туннель маршрутизирует. Поэтому имя приложения ничего не говорит о том, какой компонент отклонил соединение. Проверьте список расширений, затем подключённую службу, затем журнал клиента — именно в этом порядке.
Private Relay охватывает Safari, а не всю машину
Private Relay отправляет охваченный просмотр через два реле, которыми управляют разные стороны, так что ни один оператор не держит одновременно и вашу личность, и ваши адресаты. Это проект приватности, а не туннель: нет шлюза, в который можно войти, нет частной подсети и нет способа закрепить адрес выхода в выбранной вами стране.
Его охват намеренно узок: он покрывает просмотр в Safari вместе с DNS-запросами и небезопасными HTTP-загрузками, которые к нему прилагаются. Сеанс терминала, почтовый клиент, приложение чата и игровой лаунчер остаются снаружи. Если проверка в терминале по-прежнему показывает адрес сети доступа, а Safari показывает адрес реле, это ожидаемый результат, а не сломанная установка.
Доступность условна. Нужен план iCloud+, он предлагается не во всех регионах, а управляемая сеть может блокировать доступ к реле, и тогда Safari возвращается к прямому соединению. Обзор Private Relay от Apple — ориентир для текущего охвата. Когда профиль VPN подключён и несёт этот трафик, реле не надстраивается сверху; путь определяет профиль.
Читайте доказательства в правильном порядке
Начните с состояния службы, потому что это самый дешёвый признак. scutil --nc list печатает настроенные службы VPN и то, подключена ли каждая. Профиль может лежать там годами, ни разу не подключившись, и люди обычно считают это туннелем.
Затем посмотрите на интерфейсы и маршруты. ifconfig показывает интерфейсы utun, но само их присутствие доказывает немногое, поскольку macOS использует utun и для других целей помимо VPN. Важно, ведёт ли маршрут по умолчанию в один из них, о чём сообщает route -n get default.
Для разрешения имён scutil --dns перечисляет резолверы, которые система действительно будет использовать, и там появляется поставщик DNS-прокси. Сравнение dig +short example.com с dig +short example.com @1.1.1.1 отделяет отвечающий резолвер от перехватываемого.
Активность расширений попадает в объединённый журнал: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. Вы ищете, какое расширение запустилось и сообщил ли фильтр вердикт по нужному вам потоку, а не строку для заучивания.
Сузьте симптом, прежде чем что-то отключать
Сначала классифицируйте отказ. Имя, которое не разрешается, соединение, отклоняемое сразу, и соединение, висящее до тайм-аута, — три разных наблюдения с тремя разными ответственными. Разрешение указывает на резолвер или DNS-прокси. Немедленный отказ указывает на правило фильтра. Тишина обычно указывает на маршрутизацию или на туннель, который поднят, но не передаёт.
На управляемом Mac исходите из того, что фильтр принадлежит организации. Отключение его ради проверки VPN убирает именно тот компонент, который вы хотели наблюдать, и MDM часто возвращает его при следующей проверке. Спросите у администратора имя политики, прежде чем что-либо менять, и проверяйте тем конкретным приложением, которое дало сбой, а не всей системой.
Ещё одна ловушка: отключение Private Relay ради проверки VPN ничего не говорит о зарубежном трафике, потому что реле этот трафик никогда не покрывало. Каждый уровень нужно проверять в приложении, которым он действительно управляет.
Пройдите этот список и остановитесь на первом пункте, который не пройдёт:
- Показывает ли
scutil --nc listожидаемую службу как подключённую? - Отличается ли публичный адрес, видимый из терминала, от адреса, выданного вашей сетью доступа?
- Установлено ли расширение фильтра и записало ли оно вердикт по сбойному потоку?
- Отказ только в Safari? Если да, проверьте охват реле, прежде чем винить туннель.
Если все четыре пройдены, а приложение всё равно не работает, проблема выше сетевого уровня: настройки прокси, доверие к сертификату или список разрешённых на уровне приложения.