Mailcow за обратным прокси OpenWRT. История одной рабочей конфигурации

Зачем вообще понадобился Reverse Proxy?

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

Я пошел по второму пути.

В моей домашней инфраструктуре роль пограничного устройства выполняет маршрутизатор Cisco с OpenWRT. На нем уже работает встроенный nginx, который обслуживает несколько внутренних сервисов. Логичным решением было использовать его и для Mailcow.

Это позволило оставить сам почтовый сервер внутри локальной сети, а наружу публиковать только необходимые сервисы.

Первая схема выглядела просто

Интернет
      │
      ▼
OpenWRT + nginx
      │
      ▼
Mailcow

На практике оказалось, что одной строки proxy_pass недостаточно.

Почтовый сервер - это не обычный веб-сайт.

Он использует сразу несколько сервисов:

• веб-интерфейс;
• SOGo;
• ActiveSync;
• Autodiscover;
• API.

Каждый из них имеет свои особенности.

Первые проблемы

После первой настройки веб-интерфейс открывался без проблем.

Но практически сразу начали проявляться мелкие ошибки.

Сначала не заработал ActiveSync.

Затем Outlook не смог автоматически определить параметры подключения.

Позже выяснилось, что часть запросов вообще приходит по другому URL.

Оказалось, что Mailcow ожидает определенные HTTP-заголовки и корректно обрабатывает только те запросы, которые содержат информацию об исходном HTTPS-соединении.

Что пришлось изменить

В nginx пришлось добавить передачу стандартных заголовков:

• Host
• X-Forwarded-For
• X-Forwarded-Proto
• X-Real-IP

Кроме этого пришлось отдельно описывать несколько location-блоков.

Например:

/SOGo

и

/Microsoft-Server-ActiveSync

А также оба варианта регистра для Autodiscover.

/autodiscover/autodiscover.xml

/Autodiscover/Autodiscover.xml

На первый взгляд кажется мелочью.

Но именно подобные детали чаще всего и занимают большую часть времени при настройке.

Еще одна неожиданность

В какой-то момент я решил разместить на основном домене личный сайт.

И здесь выяснилось, что раньше весь трафик с

romik.uz

перенаправлялся на

mail.romik.uz

Когда появился Ghost, этот редирект пришлось полностью пересмотреть.

В результате почта осталась доступна по своему поддомену, а основной домен стал использоваться уже как обычный сайт.

Что получилось в итоге

Сегодня схема выглядит следующим образом:

Интернет
        │
        ▼
Cisco + OpenWRT
        │
        ▼
nginx Reverse Proxy
        │
 ┌──────┴────────┐
 │               │
 ▼               ▼
Ghost         Mailcow

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

Вывод

Самая сложная часть подобных проектов - не установка Mailcow.

Сложнее всего правильно организовать взаимодействие нескольких сервисов между собой.

Когда почта, веб-сайт, сертификаты и обратный прокси начинают работать как единая система, инфраструктура становится намного проще в сопровождении.

Именно такие мелочи обычно не попадают в официальную документацию, но именно они чаще всего отнимают больше всего времени.