Внутрикластерный TLS

Внутрикластерный TLS шифрует TCP-соединения между Серверами Кластера (Фронтенд-Серверами, Бэкенд-Серверами и Контроллером Динамического Кластера). TLS для клиентских соединений (HTTPS, SMTPS и т.п.) настраивается отдельно и здесь не рассматривается.

Типичные защищаемые пути: Фронтенд-Сервер <-> Бэкенд-Сервер, Бэкенд-Сервер <-> Бэкенд-Сервер, Бэкенд-Сервер <-> Контроллер. Роли описаны в разделе Кластер. Порты для соединения с Бэкенд-Серверами задаются в Внутрикластерном Взаимодействии.

Сервер записывает события внутрикластерного TLS с префиксом TLSC в Журнал Наблюдения. Конфигурацию и состояние даёт команда интерфейса командной строки GETCLUSTERTLSSTATUS (требуется право Может наблюдать за Сервером).

Настройка

Для каждого порта Бэкенд-Сервера внутрикластерный TLS состоит из двух независимых частей:

Часть	Где настраивается	Смысл
TLS Кластера (исходящий)	Настройки Кластера (DeliveryUseTLS, IMAPUseTLS, PWDUseTLS и т.д.)	Этот Сервер использует TLS при соединении с другими Серверами Кластера на данном порту.
Начальный SSL/TLS локального приёмника	Установки -> Услуги -> Приёмник соответствующего модуля	Режим Начальный SSL/TLS включается на TCP-приёмнике этого Сервера для данного порта (см. Приёмники). На Бэкенд-Сервере его можно сопоставлять с исходящим UseTLS Сервера Кластера, который сюда подключается. На Фронтенд-Сервере это режим публичного приёмника, а не удалённая сторона соединения Фронтенд-Сервер -> Бэкенд-Сервер.

Обе стороны должны совпадать. Если на инициаторе включён исходящий TLS, принимающий Сервер должен принимать TLS на соответствующем приёмнике.

Поддерживаемые порты Бэкенд-Серверов: Доставка, Отправление, POP, IMAP, PWD, HTTP User, HTTP Admin, XIMSS, XMPP, LDAP.

Серверные сертификаты и Доверенные Сертификаты для TLS настраиваются в разделе PKI.

Состояние через интерфейс командной строки

Конфигурацию и текущее состояние внутрикластерного TLS можно получить командой GETCLUSTERTLSSTATUS. Описание полей и пример ответа приведены в справочнике интерфейса командной строки.

Журналирование

Сообщения, связанные с внутрикластерным TLS, записываются в Журнал Наблюдения с префиксом TLSC. Префикс используется только для соединений между Серверами Кластера, когда адрес удалённого Сервера есть в списках адресов Фронтенд-Серверов или Бэкенд-Серверов Кластера. Обычный TLS-трафик записывается без этого префикса.

Метки Журнала Наблюдения

У каждой записи Журнала Наблюдения есть метка, указывающая компонент. Для внутрикластерного TLS смотрите эти метки вместе с текстовым префиксом TLSC:

Метка Журнала Наблюдения	Настройка (Кластер / Установки)	Что покрывает
LOCKER	Кластер -> Журнал Локера Динамического Кластера	Соединение Бэкенд-Сервера с Контроллером по порту PWD (LOCKER).
CLUSTER	Кластер -> Папки (SingleImageLogLevel)	Соединение Сервера Динамического Кластера с Контроллером при синхронизации доступа к Пользователям Общих Доменов.
ADMIN	Кластер -> Администрация Объектов	Внутрикластерные команды администрирования через PWD.
SUBMIT, IMAP, ...	Соответствующие уровни журнала Кластера	Отправление, удалённый доступ к папкам и другие внутрикластерные соединения между Серверами Кластера.

Подробности установления соединения (шифр, сертификат) задаются на панели Сессии TLS в разделе PKI (поле Уровень Журнала). Такие строки обычно сохраняют метку модуля (LOCKER, IMAP и т.п.) и не образуют отдельный компонент Журнала Наблюдения с именем TLS.

В Журнале Наблюдения откройте активный файл журнала с Filter=TLSC. Дополнительно ищите LOCKER, ADMIN, failed.

Рекомендуемые уровни журнала для диагностики

При разборе проблем внутрикластерного TLS временно поднимите эти уровни, затем верните обычные значения:

1. Кластер -> Журнал Локера Динамического Кластера = Проблемы, Администрация Объектов = Проблемы, Папки = Проблемы.
2. PKI -> Сессии TLS -> Уровень Журнала = Проблемы (или Всё для одной сессии).
3. Убедитесь, что на нужных портах включён UseTLS (PWDUseTLS, IMAPUseTLS, ...).

Типичные сообщения

Ниже приведены примеры строк Журнала Наблюдения, по которым удобно подтверждать успех или сбой TLS между Серверами Кластера.

• При TLSC controller %T TLS handshake failed Бэкенд-Сервер не установил TLS с Контроллером (метка LOCKER).
• При TLSC connected to CONTROLLER%T Бэкенд-Сервер установил TLS-соединение LOCKER с Контроллером.
• При TLSC TLS to CONTROLLER%T failed Сервер Динамического Кластера не установил TLS к Контроллеру (метка CLUSTER, синхронизация доступа к Пользователям Общих Доменов).
• При TLSC %T -> %T TCP connect failed, TLS handshake failed или protocol open failed исходящее внутрикластерное соединение между Серверами Кластера не удалось (метки ADMIN, SUBMIT, IMAP и подобные).
• При TLSC backend %T TLS handshake failed этот Сервер не установил TLS при соединении с Бэкенд-Сервером (часто Фронтенд-Сервер -> Бэкенд-Сервер для IMAP, POP, PWD и т.п.). Слово backend в строке журнала обозначает адрес удалённого Бэкенд-Сервера, а не роль Сервера, который пишет журнал.
• При TLSC server cluster %T STLS failed не удался входящий STLS на PWD от Сервера Кластера.
• При TLSC client %T STLS failed не удался исходящий STLS на пути клиентской сессии PWD для администрирования. Слово client здесь означает сессию PWD как сторону, которая открывает TLS для STLS, а не почтовый клиент конечного пользователя.

Сообщения слоя OpenSSL (failed to open a secure connection, принятие шифра) пишутся без префикса TLSC. Чтобы их увидеть, поднимите Уровень Журнала на панели Сессии TLS в PKI.

Ограничения

Исходящий внутрикластерный TLS не проверяет серверный сертификат удалённого Сервера, потому что имя сервера для проверки не задаётся. Диагностика опирается на сбои установления TCP и TLS с префиксом TLSC, а не на отдельный отказ по проверке сертификата.