Mac Mail, два аккаунта и одно правило VPN, которое не может их разделить

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

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

Почему приложение — неверная единица

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

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

Когда два аккаунта используют разные серверы

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

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

Когда оба аккаунта делят один сервер

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

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

Запустить туннель — не то же самое, что покрыть его

Полезная нагрузка App Layer VPN от Apple документирует параметр MailDomains: перечисленные домены заставляют Mail запускать VPN-соединение в поддерживаемых управляемых развёртываниях. Это полезная возможность, и она уже, чем звучит. Она запускает туннель, когда Mail общается с этими доменами; она не описывает каждый маршрут, каждую связь приложения или то, что происходит, пока туннель опущен.

Это также управляемая функция, а не флажок для каждого аккаунта в интерфейсе Mail. Если развёртывание не управляется, настройка вам недоступна, и никакое редактирование профилей её не создаст.

Проверяйте свежей синхронизацией, а не кэшированным ящиком

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

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