Развертывание нескольких 3CX MCU и серверов ИИ-транскрипции в одной локальной сети.

При запуске нескольких серверов, требующих публичных FQDN и SSL-сертификатов, управление сертификатами может стать сложной задачей.

Чтобы предоставить наглядные примеры того, что можно и чего нельзя достичь, в качестве отправной точки используется распространенный сценарий, а затем подробно рассматривается, как различные варианты влияют на стратегию управления SSL-сертификатами.

Общий пример настройки

Для лучшего понимания рассматривается инфраструктура с 3 серверами внутри одной локальной сети (LAN):

  • АТС 3CX – IP-адрес 192.168.0.10
  • сервер 3CX MCU – IP-адрес 192.168.0.20
  • сервер ИИ-транскрипции 3CX – IP-адрес 192.168.0.30

FQDN, предоставляемые 3CX

В стандартном развертывании 3CX используется собственный клиент ACME для автоматического выпуска и продления сертификатов Let’s Encrypt. Следовательно, этот метод жестко привязывает сертификат к установке 3CX и FQDN. Ниже описаны 3 обязательных требования:

1. Выделенные публичные IP-адреса

Для работы этой конфигурации каждой из 3 машин потребуется выделенный публичный IP-адрес; рассмотрим этот пример:

FQDN Система Локальный
IP-адрес		 Публичный
IP-адрес
mypbx.3cx.com.cy АТС 3CX 192.168.0.10 20.20.20.20
mymcu.3cx.com.cy сервер 3CX MCU 192.168.0.20 20.20.20.21
myai.3cx.com.cy сервер ИИ-транскрипции 3CX 192.168.0.30 20.20.20.22

2. Split DNS

DNS-сервер локальной сети должен быть настроен таким образом, чтобы:

  • Внутри локальной сети FQDN разрешались во внутренние IP-адреса локальной сети.
  • За пределами локальной сети FQDN разрешались в ПУБЛИЧНЫЕ IP-адреса.

Самый простой способ сделать это — создать специфичные для FQDN A-записи (или AAAA) для машин в локальной сети, где локальный DNS-сервер настроен следующим образом:

  • FQDN: mypbx.3cx.com.cy – АТС 3CX – IP-адрес 192.168.0.10
  • FQDN: mymcu.my3cx.net – сервер 3CX MCU – IP-адрес 192.168.0.20
  • FQDN: myai.my3cx.net – сервер ИИ-транскрипции 3CX – IP-адрес 192.168.0.30

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

  • Pinpoint DNS Zones
  • Response Policy Zone (RPZ)
  • Split-Horizon DNS или Views
  • Shadow Zones

3. Проброс портов для автоматического обновления сертификата

Потребуется настроить Сетевой экран или пограничный маршрутизатор на:

  • Проброс всего трафика (для mymcu.my3cx.net) с 20.20.20.21:80 на 192.168.0.20:80
  • Проброс всего трафика (для myai.my3cx.net) с 20.20.20.22:80 на 192.169.0.30:80

В результате Let’s Encrypt сможет получить доступ к машине для обновления сертификатов.

АТС 3CX (mypbx.3cx.com.cy) не требует такого проброса портов, поскольку использует облачную инфраструктуру 3CX для обновления сертификатов 3CX FQDN.

ПРИМЕЧАНИЕ: Если невозможно предоставить отдельные публичные IP-адреса всем машинам MCU и/или ИИ в локальной сети, ОБЯЗАТЕЛЬНО использовать собственные пользовательские FQDN.

Пользовательские FQDN с использованием Let’s Encrypt и автоматизацией DNS

Этот подход подходит, если все три машины 3CX находятся в локальной сети и не имеют прямого доступа из публичного интернета. Таким образом, требуется ручная настройка за рамками стандартной конфигурации 3CX. Для этого примера предполагаются следующие FQDN:

  • mypbx.example.com
  • mymcu.example.com
  • myai.example.com

Как и прежде, существуют требования, которые необходимо соблюдать и которые описаны ниже:

1. Скрипт автоматизации

Потребуется создать скрипт автоматизации на одной из машин в локальной сети, который:

  • Использует механизм проверки Let’s Encrypt DNS-01
  • Выполняется периодически, чтобы гарантировать заблаговременное продление сертификатов
  • Взаимодействует с Let’s Encrypt для запроса продления сертификата
  • Взаимодействует с API DNS-провайдера для создания необходимых записей для проверки Let’s Encrypt
  • Сохраняет загруженный PEM-файл сертификата и файл KEY в папку; например:


/etc/letsencrypt/live/mymcu.example.com/fullchain.pem
/etc/letsencrypt/live/mymcu.example.com/privkey.pem

2. Скрипт обновления сертификата

Далее потребуется создать скрипт обновления сертификата, который:

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

Вот пример скрипта для машины mymcu.example.com, который можно сохранить в “/root/certupdate.sh” (то же самое применимо к myai.example.com):


#!/bin/bash
cp /etc/letsencrypt/live/mymcu.example.com/fullchain.pem /opt/3cxwm/cert/server.crt
cp /etc/letsencrypt/live/mymcu.example.com/privkey.pem /opt/3cxwm/cert/server.key
chown www-data:www-data /opt/3cxwm/cert/server.*
chmod 600 /opt/3cxwm/cert/server.*

Установите правильные права доступа для скрипта:

chmod +x /root/certupdate.sh

…и добавьте его в crontab для запуска, например, каждое утро в 3:00.

Пользовательский FQDN – Ручное продление сертификата

Если возможность ограничена ручным продлением сертификатов, например, из-за отсутствия у DNS-провайдера API для автоматизации, а также, возможно, из-за использования wildcard-сертификатов (сертификатов подстановки), процедура по сути остается той же, за исключением того, что изменения придется вносить самостоятельно, без преимуществ автоматизации.

Альтернативный центр сертификации

Для центров сертификации (CA), отличных от Let’s Encrypt, предоставляется общее руководство с рекомендациями по выбору, доступное здесь.