Две учётные записи Mac не разделяют трафик VPN

Две учётные записи на одном Mac выглядят как два отдельных мира, пока не появится сеть. Туннель, запущенный в одной сессии, всё же может изменить то, что переживает другая сессия, в зависимости от того, какой клиент им владеет и какая политика идёт с ним. Опишите разделение, которое вам нужно, прежде чем выбирать механизм для его принудительного применения. Порядок важен, потому что механизм, выбранный первым, склонен переопределять требование вокруг себя.

Три вопроса выполняют бо́льшую часть работы: чьи приложения нуждаются в каких частных ресурсах, должны ли обе сессии быть активны одновременно и что этим приложениям разрешено делать, когда их туннель недоступен.

Начните с трафика, а не со списка учётных записей

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

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

Канал профиля и охват трафика — разные вещи

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

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

Гостевая система — настоящая граница с настоящими ограничениями

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

Режим виртуальной сети всё ещё требует проверки. То, подключён ли гость мостом, находится ли за NAT или изолирован, определяет, чего он может достичь и что может достичь его, а приложения хоста не становятся приложениями гостя только потому, что гость случайно подключён. Проверьте и политику блокировки, иначе упавший туннель гостя вернётся на путь хоста так, как никто не задумывал.

Прокси уже учётной записи

Одно приложение хоста может достигать настоящего прокси-сервиса, работающего в одобренном госте или контейнере, и это охватывает трафик, который приложение действительно отправляет по поддерживаемому протоколу. Это не охватывает каждый процесс, принадлежащий этой учётной записи Mac, и не охватывает трафик, который приложение отправляет вне протокола прокси.

Ещё одна предосторожность на общих машинах: TCP-слушатель, привязанный к loopback хоста, не является проверкой имени пользователя. Ограничение прокси локальной машиной удерживает его вне сети, но не даёт одному локальному пользователю прав перед другим, который уже вошёл. Держите аутентификацию сервиса явной, если это различие важно.

Докажите границу двумя тестами

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

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