Разбираем, как PMG работает в роли почтового шлюза: сетевая схема, relay-режим, настройка нескольких доменов и типичные проблемы с доставкой писем.
Proxmox Mail Gateway — это решение для фильтрации почты, которое устанавливается перед почтовым сервером и обрабатывает входящий и исходящий трафик. Оно подходит для организаций, которым нужен контроль над почтой без привязки к облачным сервисам. Если вы только разбираетесь в теме, главное понять: PMG работает как отдельная машина в сети, а не плагин к почтовому серверу.
PMG разворачивается как отдельный хост на базе Debian и занимает место между интернетом и внутренним почтовым сервером — будь то Exchange, Postfix или любой другой MTA. MX-запись домена указывает на PMG, который принимает почту первым, обрабатывает её по правилам и только потом передаёт дальше. Такая схема называется relay-режимом, и именно она лежит в основе большинства развёртываний.
Сетевая схема обычно выглядит так: внешний IP или DMZ → PMG → внутренний почтовый сервер. PMG может стоять как на физической машине, так и в виртуальной среде — например, прямо на Proxmox VE, что логично, если инфраструктура уже на этой платформе. Кстати, сочетание PMG и PVE на одном железе вполне рабочий вариант для небольших компаний, хотя в продакшене лучше разделять роли.
После установки PMG настраивается через веб-интерфейс на порту 8006. Сетевой интерфейс конфигурируется в /etc/network/interfaces, как и в обычном Debian. PMG не требует двух физических сетевых карт: один интерфейс с маршрутизацией вполне справляется с ролью и входящего, и исходящего relay.
Если нужна более сложная схема — например, отдельный интерфейс для управления и отдельный для почтового трафика — это решается стандартными средствами Debian без специфических настроек PMG. На практике большинство небольших развёртываний обходятся одним интерфейсом и правилами на файрволе.
PMG использует несколько портов, и важно понимать назначение каждого. Порт 25 (SMTP) — основной: на него приходит почта снаружи и через него PMG передаёт письма на внутренний сервер. Порт 587 (submission) используется для отправки почты клиентами, если PMG настроен как исходящий relay. Порт 465 — SMTPS, шифрованная версия, встречается реже.
Веб-интерфейс администрирования работает на порту 8006 по HTTPS. Этот порт не должен быть доступен из интернета — только из доверенной сети управления. Порт 8006 совпадает с Proxmox VE, что иногда вызывает путаницу, если оба продукта стоят рядом.
Для кластерной конфигурации PMG использует порт 8007 для синхронизации между узлами. Если в инфраструктуре несколько шлюзов — например, для отказоустойчивости — между ними должен быть открыт этот порт. На файрволе периметра его закрывают от внешнего мира.
В режиме входящего relay PMG принимает почту для домена, фильтрует спам и вирусы, затем передаёт на внутренний сервер. Адрес внутреннего сервера прописывается в разделе Relay Domains в веб-интерфейсе — для каждого домена свой адрес назначения. Это позволяет обслуживать несколько доменов с разными бэкендами.
Исходящий relay — отдельная история. PMG может принимать почту от внутренних серверов и отправлять её наружу, применяя при этом политики, DKIM-подпись и ограничения по получателям. Для этого нужно указать доверенные сети в настройках Postfix, который работает под капотом PMG. Любопытно, что PMG не скрывает этот факт: в конфигурационных файлах вы найдёте стандартные директивы Postfix, которые можно редактировать напрямую — хотя лучше делать это через API или интерфейс, чтобы изменения не перезаписывались.
Ограничение, о котором стоит знать: PMG не поддерживает полноценный IMAP/POP3. Он работает исключительно с SMTP и не хранит почту постоянно — только в карантине. Если нужен почтовый ящик, потребуется отдельный сервер.
Корректная работа PMG невозможна без нескольких DNS-записей. MX-запись домена должна указывать на IP или hostname PMG — это базовое условие для приёма почты. PTR-запись (обратный DNS) для исходящего IP тоже обязательна: без неё письма будут уходить в спам на стороне получателя.
SPF-запись описывает, с каких IP разрешена отправка почты от имени домена. PMG сам по себе SPF не генерирует — запись нужно добавить в DNS вручную, указав IP шлюза. DKIM настраивается внутри PMG: система генерирует ключи, а публичную часть нужно добавить как TXT-запись в DNS. DMARC — следующий уровень, он ссылается на SPF и DKIM и указывает, что делать с письмами, которые проверку не прошли.
На практике отсутствие PTR-записи — самая частая причина проблем с доставкой при свежей установке PMG. Это не баг шлюза, а требование почтовых серверов получателей, и решается обращением к провайдеру или в панель управления хостингом.
PMG поддерживает кластеризацию: несколько узлов синхронизируют конфигурацию, карантин и статистику. Для этого между узлами нужна низколатентная сеть — в идеале выделенный интерфейс или хотя бы отдельный VLAN. Синхронизация идёт через зашифрованное соединение на порту 8007.
При кластерной схеме MX-записи домена обычно указывают на несколько узлов с разными приоритетами. Если основной шлюз недоступен, почта приходит на резервный. Оба узла должны уметь передавать почту на внутренний сервер — значит, маршруты и правила файрвола настраиваются на каждом отдельно.
Честно говоря, кластер из двух PMG — это уже заметное усложнение инфраструктуры. Для большинства организаций до 200–300 пользователей один шлюз с нормальным резервированием на уровне сети вполне достаточен.
Плюсы:
Минусы:
Перед установкой определитесь, будет ли PMG обрабатывать только входящую почту или исходящую тоже. Это влияет на конфигурацию портов, доверенных сетей и DNS-записей. Если исходящий трафик тоже идёт через PMG, убедитесь, что DKIM-ключи добавлены в DNS до начала отправки — иначе часть писем уйдёт в спам ещё до того, как вы это заметите.
При выборе между физической машиной и виртуальной обратите внимание на производительность сети: PMG чувствителен к задержкам при высоком потоке писем. Если вы разворачиваете PMG в виртуальной среде, выделите ему отдельный виртуальный интерфейс с минимальным оверхедом.
| Сценарий | Ключевой момент |
|---|---|
| Входящий relay | MX указывает на PMG, внутренний сервер — в Relay Domains |
| Исходящий relay | Доверенные сети в Postfix, DKIM в DNS |
| Порты для почты | 25 обязателен, 587/465 — по необходимости |
| Управление | Порт 8006, только из внутренней сети |
| DNS | PTR, SPF, DKIM, DMARC — все четыре, вручную |
| Кластер | Порт 8007 между узлами, выделенная сеть |
| Ограничение | IMAP/POP3 не поддерживается |
Технически — да, оба продукта основаны на Debian и могут работать на одном железе, но это разные системы с разными установщиками. На практике PMG чаще разворачивают как виртуальную машину внутри PVE: это проще в обслуживании и позволяет делать снапшоты. Совместная установка на один хост без виртуализации возможна, но не рекомендуется в продакшене из-за конфликтов пакетов.
Чаще всего причина — отсутствие PTR-записи для исходящего IP или некорректный SPF. Проверьте, совпадает ли hostname PMG с PTR-записью, и убедитесь, что IP шлюза перечислен в SPF-записи домена. Инструменты вроде MXToolbox помогают быстро найти проблему без разбора логов вручную.
Для каждого домена в разделе Relay Domains указывается свой адрес назначения — можно на разные серверы. Правила фильтрации и политики можно применять как глобально, так и на уровне конкретного домена. Это удобно для хостинг-провайдеров или компаний с несколькими юридическими лицами на одной инфраструктуре.
