Почта доходит до сервера без VPN: где применять правило

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

Выберите требование до выбора продукта. Правило сервера и правило клиента отказывают в разных местах, дают разные доказательства и принадлежат разным владельцам. Применять оба допустимо, когда оба утверждения верны, но одно не заменяет другое. Оба требования законны; просто это не один и тот же контроль.

Симптом выглядит как Mac, но утечка может быть на сервере

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

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

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

Допуск на сервере: отказывайте источнику, а не приложению

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

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

Её предел не менее важен. Отклонённое соединение доказывает, что служба отказала в сеансе; оно не доказывает, что Mac не пытался. Разрешение DNS, TCP SYN к более раннему балансировщику нагрузки и повторная попытка после сбоя — всё это может произойти до того, как будет достигнуто правило сервера. Если требование касается раскрытия попыток, а не доступа, допуск на сервере — лишь половина контроля.

Принуждение на клиенте: блокируйте попытку, а не только туннель

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

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

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

Правила уровня приложения и уровня назначения имеют разный охват

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

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

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

Проверяйте отказ и отсутствие попытки отдельно

С выделенной тестовой учётной записью подключитесь через VPN и подтвердите нормальную работу. Затем отключитесь и проверьте дважды: один раз — отказывает ли сервер в входе, и один раз — пытается ли Mac вообще установить соединение. Это разные наблюдения, и они относятся к разным журналам.

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

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