Используем nginx для выполнения интересных и нестандартных задач. Установка iRedMail Nginx два почтовых сервера
Новые горизонты. Используем nginx для выполнения интересных и нестандартных задач
Используем nginx для выполнения интересных и нестандартных задач
Nginx стремительными темпами набирает популярность, превращаясь из просто ускорителя отдачи статики для Apache в полнофункциональный и развитый веб-сервер, который все чаще применяется обособленно. В этой статье мы поговорим об интересных и нестандартных сценариях использования nginx, которые позволят выжать из веб-сервера максимум.
Почтовый прокси
Начнем с самого очевидного — со способности nginx выступать в роли почтового прокси. Эта функция есть в nginx изначально, а вот используется в продакшн она почему-то крайне редко, некоторые так и вообще не догадываются о ее существовании. Как бы там ни было, nginx поддерживает проксирование протоколов POP3, IMAP и SMTP с разными методами аутентификации, включая SSL и StartTLS, причем делает это очень быстро.
Зачем это нужно? Есть как минимум два применения данной функциональности. Первая: использовать nginx в качестве щита от назойливых спамеров, пытающихся отправить мусорные письма через наш SMTP-сервер. Обычно спамеры не создают много проблем, так как быстро отшибаются на этапе аутентификации, однако, когда их становится действительно много, nginx поможет сэкономить процессорные ресурсы. Вторая: использовать nginx для перенаправления пользователей на несколько почтовых POP3/IMAP-серверов. С этим, конечно, мог бы справиться и другой почтовый прокси, но зачем городить огород серверов, если на фронтенде уже установлен nginx для отдачи статики по HTTP, например?
Почтовый прокси-сервер в nginx сделан не совсем стандартно. Он использует дополнительный слой аутентификации, реализованный средствами HTTP, и, только если пользователь проходит этот барьер, он пропускается дальше. Обеспечивается такая функциональность путем создания страницы/скрипта, которой nginx отдает данные пользователя, а она/он возвращает ответ в виде стандартных OK или причины отказа (типа «Invalid login or password»). Скрипт запускается со следующими заголовками:
А возвращает такие:
Замечательная особенность такого подхода в том, что его можно использовать вовсе не для самой аутентификации, а чтобы раскидать пользователей по разным внутренним серверам, в зависимости от имени юзера, данных о текущих нагрузках на почтовые серверы либо вообще организовав простейшую балансировку нагрузки с помощью round-robin. Впрочем, если требуется всего лишь перекинуть пользователей на внутренний почтовый сервер, можно использовать вместо реального скрипта заглушку, реализованную самим nginx. Например, простейший SMTP- и IMAP-прокси в конфиге nginx будет выглядеть следующим образом:
Далее в секцию http конфига добавляем следующее:
Это все. Такая конфигурация позволяет прозрачно перенаправлять пользователей на внутренний почтовый сервер, не создавая оверхеда в виде ненужного в данном случае скрипта. Применив скрипт, такую конфигурацию можно существенно расширить: настроить балансировку нагрузки, проверять пользователей по базе LDAP и выполнять другие операции. Написание скрипта выходит за рамки этой статьи, однако его очень легко реализовать, даже имея лишь поверхностные знания о PHP и Python.
Потоковое вещание видео
Поднять обычный видеохостинг на базе nginx легко. Достаточно только выложить перекодированное видео в доступный серверу каталог, прописать его в конфиг и настроить флеш- или HTML5-проигрыватель так, чтобы он брал видео из этого каталога. Однако, если требуется настроить непрерывное вещание видео из какого-то внешнего источника или веб-камеры, такая схема не сработает, и придется смотреть в сторону специальных потоковых протоколов.
Есть несколько протоколов, решающих эту задачу, наиболее эффективный и поддерживаемый из них RTMP. Беда только в том, что почти все реализации RTMP-сервера страдают от проблем. Официальный Adobe Flash Media Server платный. Red5 и Wowza написаны на Java, а потому не дают нужной производительности, еще одна реализация, Erlyvideo, написана на Erlang, что хорошо в случае настройки кластера, но не так эффективно для одиночного сервера.
Я же предлагаю другой подход — воспользоваться модулем RTMP для nginx. Он обладает превосходной производительностью и к тому же позволит использовать один сервер для отдачи как веб-интерфейса сайта, так и видеопотока. Проблема только в том, что модуль этот неофициальный, поэтому nginx с его поддержкой придется собрать самостоятельно. Благо сборка осуществляется стандартным способом:
Теперь модуль нужно настроить. Делается это, как обычно, через конфиг nginx:
Модуль RTMP не умеет работать в многопоточной конфигурации, поэтому количество рабочих процессов nginx придется сократить до одного (позже я расскажу, как обойти эту проблему):
Теперь можно сохранить файл и заставить nginx перечитать конфигурацию. Настройка nginx завершена, но самого видеопотока у нас еще нет, поэтому его нужно где-то взять. Для примера пусть это будет файл video.avi из текущего каталога. Чтобы превратить его в поток и завернуть в наш RTMP-вещатель, воспользуемся старым добрым FFmpeg:
В том случае, если видеофайл представлен не в формате H264, его следует перекодировать. Это можно сделать на лету с помощью все того же FFmpeg:
Поток также можно захватить прямо с веб-камеры:
Чтобы просмотреть поток на клиентской стороне, можно воспользоваться любым проигрывателем с поддержкой RTMP, например mplayer:
Или встроить проигрыватель прямо в веб-страницу, которая отдается тем же nginx (пример из официальной документации):
Простейший веб-проигрыватель RTMP
Важных строки тут всего две: «file: “stream”», указывающая на RTMP-поток, и «streamer: “rtmp://localhost/rtmp”», в которой указан адрес RTMP-стримера. Для большинства задач таких настроек будет вполне достаточно. По одному адресу можно пустить несколько разных потоков, а nginx будет эффективно их мультиплексировать между клиентами. Но это далеко не все, на что способен RTMP-модуль. С его помощью, например, можно организовать ретрансляцию видеопотока с другого сервера. Сервер FFmpeg для этого вообще не нужен, достаточно добавить следующие строки в конфиг:
Если требуется создать несколько потоков в разном качестве, можно вызвать перекодировщик FFmpeg прямо из nginx:
С помощью такой конфигурации мы получим сразу два вещателя, один из которых будет доступен по адресу rtmp://сайт/rtmp, а второй, вещающий в качестве 320 x 240, — по адресу rtmp://сайт/rtmp–320×240. Далее на сайт можно повесить флеш-плеер и кнопки выбора качества, которые будут подсовывать плееру тот или иной адрес вещателя.
Ну и напоследок пример вещания музыки в сеть:
Git-прокси
Система контроля версий Git способна обеспечивать доступ к репозиториям не только по протоколам Git и SSH, но и по HTTP. Когда-то реализация доступа по HTTP была примитивной и неспособной обеспечить полноценную работу с репозиторием. С версии 1.6.6 ситуация изменилась, и сегодня этот протокол можно использовать, чтобы, например, обойти ограничения брандмауэров как с той, так и с другой стороны соединения либо для создания собственного Git-хостинга с веб-интерфейсом.
К сожалению, официальная документация рассказывает только об организации доступа к Git средствами веб-сервера Apache, но, так как сама реализация представляет собой внешнее приложение со стандартным CGI-интерфейсом, ее можно прикрутить практически к любому другому серверу, включая lighttpd и, конечно же, nginx. Для этого не потребуется ничего, кроме самого сервера, установленного Git и небольшого FastCGI-сервера fcgiwrap, который нужен, потому что nginx не умеет работать с CGI напрямую, но умеет вызывать скрипты с помощью протокола FastCGI.
Вся схема работы будет выглядеть следующим образом. Сервер fcgiwrap будет висеть в фоне и ждать запроса на исполнение CGI-приложения. Nginx, в свою очередь, будет сконфигурирован на запрос исполнения CGI-бинарника git-http-backend через FastCGI-интерфейс каждый раз при обращении к указанному нами адресу. Получив запрос, fcgiwrap исполняет git-http-backend с указанными CGI-аргументами, переданными GIT-клиентом, и возвращает результат.
Чтобы реализовать такую схему, сначала установим fcgiwrap:
Настраивать его не нужно, все параметры передаются по протоколу FastCGI. Запущен он будет тоже автоматически. Поэтому остается только настроить nginx. Для этого создаем файл /etc/nginx/sites-enabled/git (если такого каталога нет, можно писать в основной конфиг) и пишем в него следующее:
Этот конфиг предполагает три важные вещи:
- Адресом репозитория будет /srv/git, поэтому выставляем соответствующие права доступа:
- Сам репозиторий должен быть открыт на чтение анонимусами и позволять аплоад по HTTP:
- Аутентификация осуществляется с помощью файла htpasswd, нужно его создать и добавить в него пользователей:
На этом все, перезагружаем nginx:
Далее можно подключиться к репозиторию с помощью клиента Git.
Настраиваем Git-прокси
Хакер #171. 3D-принтеры
Микрокеширование
Представим себе ситуацию с динамичным, часто обновляемым сайтом, который вдруг начинает получать очень большие нагрузки (ну попал он на страницу одного из крупнейших новостных сайтов) и перестает справляться с отдачей контента. Грамотная оптимизация и реализация правильной схемы кеширования займет долгое время, а проблемы нужно решать уже сейчас. Что мы можем сделать?
Есть несколько способов выйти из этой ситуации с наименьшими потерями, однако наиболее интересную идею предложил Фенн Бэйли (Fenn Bailey, fennb.com). Идея в том, чтобы просто поставить перед сервером nginx и заставить его кешировать весь передаваемый контент, но не просто кешировать, а всего на одну секунду. Изюминка здесь в том, что сотни и тысячи посетителей сайта в секунду, по сути, будут генерировать всего одно обращение к бэкенду, получая в большинстве своем кешированную страницу. При этом разницу вряд ли кто-то заметит, потому что даже на динамичном сайте одна секунда обычно ничего не значит.
Конфиг с реализацией этой идеи будет выглядеть не так уж и сложно:
Особое место в этом конфиге занимает строка «proxy_cache_use_stale updating;», без которой мы бы получили периодические всплески нагрузки на бэкенд-сервер из-за запросов, пришедших во время обновления кеша. В остальном все стандартно и должно быть понятно без лишних объяснений.
Тестирование производительности с выключенным/включенным микрокешированием 
Тестирование производительности с выключенным/включенным микрокешированием
Приближение прокси к ЦА
Несмотря на повсеместное глобальное увеличение скоростей интернета, физическая удаленность сервера от целевой аудитории все равно продолжает играть свою роль. Это значит, что, если русский сайт крутится на сервере, расположенном где-нибудь в Америке, скорость доступа к нему будет априори медленнее, чем с российского сервера с такой же шириной канала (естественно, если закрыть глаза на все остальные факторы). Другое дело, что размещать серверы за рубежом зачастую выгоднее, в том числе и в плане обслуживания. Поэтому для получения профита, в виде более высоких скоростей отдачи, придется идти на хитрость.
Один из возможных вариантов: разместить основной производительный сервер на Западе, а не слишком требовательный к ресурсам фронтенд, отдающий статику, развернуть на территории России. Это позволит без серьезных затрат выиграть в скорости. Конфиг nginx для фронтенда в этом случае будет простой и всем нам знакомой реализацией прокси:
Выводы
Сегодня с помощью nginx можно решить множество самых разных задач, многие из которых вообще не связаны с веб-сервером и протоколом HTTP. Почтовый прокси, сервер потокового вещания и интерфейс Git — это только часть таких задач.
Установка почтового сервера iRedMail
iRedMail представляет собой набор скриптов для развертывания полноценного почтового сервера на базе Postfix. Это готовое решение, которое позволяет упростить задачу довольно тонкой и трудоемкой установки почтового сервера. Используя эту готовую сборку, вы получаете «из коробки» следующие компоненты:
- Postfix – почтовый smtp сервер.
- Dovecot – pop3imap сервер
- Roundcube – популярный web-интерфейс для доступа к почтовым ящикам
- SOGo – альтернативный web-интерфейс для доступа к почтовым ящикам, с возможностью коллективного использования календаря и адресной книги
Netdata – доступ к статистике сервера. - Amavisd – модуль, с помощью которого вы сможете привязать к почтовому серверу антиспам, антивирус и другие вспомогательные средства.
- Greylist – система борьбы со спамом.
- SpamAssassin – бесплатный антиспам
- ClamAV – бесплатный антивирус.
Это основной, но далеко не полный список возможностей. С полным перечнем вы можете ознакомиться на официальной странице проекта. Забегая вперед, хочу обратить внимание, что существует платная и бесплатная версия iRedMail. Бесплатная версия имеет некоторые ограничения, например отсутствие возможности создания алиасов почтовых ящиков через web-интерфейс и возможность переадресации почты. Это можно выполнять через правку базы данных. В остальном это довольно мощное и средство, которое поможет без особых усилий установить собственный стабильный почтовый сервер. Для тонкой конфигурации, если возникнет необходимость, используются стандартные конфигурационные файлы перечисленных выше компонентов.
1. Настройка домена
Back-resolve (PTR)
Перед установкой постового сервера необходимо настроить доменное имя. Делать это будем на примере нашей панели управления. Первым делом нам необходимо зайти в панель управления доменом по адресу https://domainadmin.freehost.com.ua и указать IN A запись (IP адрес нашего VPS), MX запись и добавить необходимый субдомен.
Обратите внимание, эти настройки будут верны, если ваш домен обслуживается нашими ДНС серверами. Если Вы используете собственные ДНС, все эти настройки необходимо проводить на стороне провайдера, который обслуживает ваше доменное имя.
Для корректной доставки почты так же необходимо настроить PTR запись. Настройка производится в панели управления сервером по адресу https://admin.freehost.com.ua/. Более подробно о настройке PTR вы можете ознакомится в руководстве по настройке бекрезолва. Чтобы все работало правильно, у вас должно быть четкое соответствие в этих записях, иначе отправленная почта будет попадать в спам или вовсе отклоняться, в зависимости от настроек почтового сервера получателя. Визуально это будет выглядеть следующим образом:
Теперь необходимо проверить, правильно ли все работает. Для этого нам понадобятся три команды: dig, host и nslookup
Из примера видно, что бекрезолв настроен верно, в обе стороны ip адрес и адрес почтового сервера соответствуют друг другу. PTR необходимо прописывать у провайдера, который предоставляет вам внешний статический IP адрес.
Так же рассмотрим ситуацию, когда мы настроили iRedMail на один домен, но появилась необходимость добавить дополнительный. По умолчанию, вся почта будет уходить через первоначальный relay, подписывая письма сторонней DKIM записью. Следовательно, почта будет попадать в спам. Чтобы это исключить, обязательно пропишите для домена DKIM-подпись.
Запись SPF является разновидностью записи DNS Она определяет почтовые серверы, которым разрешено отправлять электронную почту от имени домена. Эта запись так же играет немаловажную роль в корректной доставке почты.
PTR запись, DKIM и SPF записи необходимо настраивать обязательно, в связи с внедрением ведущих почтовых систем более жесткой проверки отправителя в борьбе со спамом. Выше приведены примеры, как настроить эти записи в нашей панели управления. Если вы не являетесь нашим клиентом, вам необходимо обратиться за консультацией в техподдержку провайдера, ДНС которого обслуживает ваш домен.
2. Технические требования
Установка iRedMail v1.1 возможна на следующие операционные системы: Centos 7; Debian 9, 10 (Recommend); Ubuntu 18.04 LTS; FreeBSD 12.x; OpenBSD 6.6.
OpenLDAP, PostgreSQL, MariaDB, SOGo, netdata monitor доступны во всех перечисленных выше ОС, кроме OpenBSD 6.6, где поддержка netdata monitor отсутствует.
Для установки рекомендуется конфигурация сервера с минимум 2048Mb ОЗУ. Этого значения должно хватить для почтового сервера со средней нагрузкой. Если предполагается большое количество пользователей и объемов почты, рекомендуется использовать 4096Mb ОЗУ, большую роль в этом играет антивирус ClamAV, который требователен к ресурсам.
Процесс установки, который описан в этом руководстве, подразумевает, что вы устанавливаете систему на чистый сервер, на котором не установлено никаких уже работающих сервисов. При инсталяции, iRedMail установит свои необходимые версии MySQLPostgreSQL, NGINX, правила iptables и т. д. Если на этом сервере уже что-то настроено, то с большой долей вероятности это приведет к его неработоспособности.
3. Установка iRedMail
Первым делом отредактируем наши /etc/hostname и /etc/hosts. Удалите их содержимое и приведите записи к следующему виду:
Так же отредактируйте resolv.conf, в поле “domain” необходимо указать имя вашего домена.
После перезагрузки сервера проверьте результат:
Теперь перейдите на страницу загрузки iRedMail чтобы получить последнюю стабильную версию. По состоянию на февраль 2020 года, это версия 1.1. Загрузите её и извлеките с архива:
Перейдите в каталог с архивом и запустите исполняемый скрипт установки:
Вас поприветствует окно установки, выберите YES
Укажите местоположение где будут храниться все почтовые ящики. По умолчанию это /var/vmail/.
Список доступных web-серверов предлагает выбор без выбора, оставим NGINX.
Далее нам предложат выбрать бекенд. Между ними нет огромной разницы, рекомендуется выбрать ту базу данных, с которой вы больше всего знакомы в работе и оптимизации. В нашем примере мы выберем mariadb.
Зададим пароль. Он не может быть пустым и содержать двойные скобки. Придумайте сложный пароль, не менее 10 символов, используя буквы верхнего и нижнего регистра, а так же спец символы и цифры.
Укажем наш почтовый домен. Обратите внимание, важно указать не наш hostname сервера, а почтовый домен, с которого будет осуществляться отправка почты.
Зададим пароль на наш почтовый ящик. Пароль не может быть пустым, а так же содержать некоторые спец символы ($). Придумайте сложный пароль, не менее 12 символов, используя буквы верхнего и нижнего регистров, а так же цифры с спецсимволы кроме $. Эти данные будут так же использоваться для входа в панель управления iRedAdmin.
На следующем этапе нам предложат выбрать компоненты, которые будут предложены. Мы оставим значения по умолчанию. Пройдемся по этому списку:
Roundcubamail – популярный почтовый web-интерфейс. Из коробки идет в версии roundcube elastic, который по функционалу понравился больше предыдущего, рекомендуем ознакомиться. Он так же неплохо оптимизирован под работу с мобильных устройств.
SOGo – альтернативный web-клиент с календарем и адресной книгой.
Netdata – системный монитор для мониторинга постового сервера в реальном времени. В нем вы сможете настроить дедупликацию страниц памяти, установить срок хранения метрик, настроить структуру дашборда, а так же оповещения. Он имеет как плюсы, так и минусы. Ознакомиться с доступными функциями вы можете на GitHub https://github.com/netdata/netdata/wiki
iRedAdmin — официальная web-панель управления почтовым сервером.
Fail2Ban — защита от подбора паролей. Более подробно о защите сервера средством утилиты Fail2Ban вы можете ознакомиться в соответствующей статье, которую мы публиковали ранее.
Заключительный этап. Проверьте правильность всех настроек и подтвердите установку. Так же обратите внимание, на картинке ниже нас предупреждают, что в файле /root/iRedMail-1.1/config храниться информация, которая имеет некоторые привилегии (например логины и пароли в текстовом виде). После установки iRedMail переместите его в безопасное место, или запомните информацию и удалите.
Установка займет некоторое время, минут 10-15. Во время установки необходимо будет подтвердить для iptables правило для подключения по SSH. Если вы используете для подключения по SSH стандартный порт 22, на оба пункта можно ответить YES:
Установка iRedMail завершена, можно перезагрузить сервер. После перезагрузки, для настройки iRedMail будут доступны следующие web-интерфейсы:
Официальная панель управления почтовым сервером:
Почтовый web-интерфейс Roundcube:
Портал коллективной работы:
После перезагрузки войдите в почтовый web-интерфейс Roundcube. В нем вы увидите два важных письма, в которых будет вся необходимая постустановочная информация:
«How to configure your mail client applications (MUA)» – данные для настройки почтовых агентов (TheBat, Thunderbirt, Outlook etc)
«Details of this iRedMail installation» – в нем вы найдете всевозможные пароли, данные для подключения к базе данных, пути к конфигурационным файлам установленных компонентов и другие нюансы.
Проверим работоспособность почтового сервиса. Для этого в Roundcube отправим тестовое письмо на свой ящик, расположенный на Gmail. У Gmail довольно требовательные спам фильтры, за одно проверим, правильно ли все прописано, и не попадут ли письма в спам. Результат в нашу пользу, почта ходит без задержек и проходит все фильтры.
Статус отправки мы так же можем найти в логах почтового сервера:
Если мы хотим увидеть более подробную информацию по этому сообщению, выполним поиск по его идентификатору 48MLld2HMTz32fs
4. Настройка почтового сервера
Интерфейс управления iRedAdmin в бесплатной версии довольно лаконичный. В нем вы можете добавить дополнительный домен, создать почтовый ящик, добавить дополнительных администраторов и посмотреть системные логи администратора
О том как добавить свой первый почтовый ящик в iRedMail читайте в нашем FAQ.
Как говорилось ранее, iRedMail использует популярный почтовый сервер Postfix, потому в случае необходимости можете приступить к редактированию главного конфигурационного файла /etc/postfix/main.cf Предварительно скопируйте конфиг, чтобы в случае ошибочных правок мы всегда смогли восстановить первоначальный.
Например, если необходимо, изменим максимальный размер отправляемого письма. Значения указываются в байтах, по умолчанию оно равно 15Mb, увеличим его до 20Mb. Для этого находим строку «message_size_limit = 15728640» и меняем значение на 20971520. Файл настроек гибкий и вы можете настроить его ориентируясь на свои задачи. Его настройка развернуто описана в официальной документации.
5. Установка PostfixАdmin (опционально)
Вы можете использовать почтовый сервер iRedMail как он есть, однако, как упоминалось ранее, бесплатная версия имеет свои ограничения. В бесплатной версии через web-интерфейс вы не сможете создавать алиасы для почтовых ящиков и настраивать переадресацию. Это доступно только через правку базы данных. Единственный выход из ситуации – установить поверх PostfixAdmin. Когда-то на официальном сайте iRedMail присутствовала статья по интеграции с PostfixAdmin, но уже как пару лет она отсутствует по понятным причинам. Комментарий техподдержки:
«Maybe you can find the article with Google web archive, but we have no interest to support PostfixAdmin anymore due to so many SQL structure changes. You’re on your own. Sorry.»
PostfixAdmin – web-приложение для управления почтовыми ящиками и доменами в Postfix c удобным web интерфейсом. Если для вас критично создание алиасов и перенаправление почты, можете посмотреть в его сторону. По своей сути, и iRedMail, и PostfixAdmin обращаются к одной и той же базе данных, однако в новых версиях структура базы vmail несколько изменилась, что делает использование postfixadmin затруднительным. В случае каких либо существенных изменениях при обновлении, эти «костыли» могут подарить неприятный сюрприз на корпоративном почтовом сервере. Рекомендовать использовать эту связку мы не можем, но теоретически и практически она возможна.
Заключение
В этой статье была рассмотрена рассмотрена установка бесплатного почтового сервера iRedMail. Это стабильный почтовый сервер, который можно рекомендовать для использования в корпоративной среде. Несмотря на некоторые ограничения в бесплатной версии, в нем нет ничего лишнего и он справляется с базовыми требованиями к отправке и получении почты.
У нас Вы можете заказать облачный VPS сервер с предустановленным почтовым сервером iRedMail или заказать физический сервер, на который не составит труда его установить и приступить к работе. Наша техническая поддержка работает круглосуточно и в случае возникших вопросов готова проконсультировать с его настройкой.
Настройка NGINX для проксирования почты
NGINX можно использовать не только в качестве веб-сервера или http-proxy, но и для проксирования почты по протоколам SMTP, IMAP, POP3. Это позволит настроить:
- Единую точку входа для масштабируемой почтовой системы.
- Балансировку нагрузки между всеми почтовыми серверами.
В данной статье установка выполняется на операционной системе Linux. В качестве почтового сервиса, на который передаются запросы можно использовать postfix, exim, dovecot, exchange, сборку iredmail и другое.
Принцип работы
NGINX принимает запросы и выполняет аутентификацию на веб-сервере. В зависимости от результата проверки логина и пароля, прокси вернет ответ с несколькими заголовками.
В случае успеха:
Таким образом, сервер и порт почтового сервера мы определяем на основе аутентификации. Это дает много возможностей при соответствующих знаниях языков программирования.
В случае неудачи:
В зависимости от результата аутентификации и заголовком, клиент перенаправляется на нужный нам почтовый сервер.
Подготовка сервера
Внесем некоторые правки в настройки безопасности сервера.
SELinux
Отключаем SELinux, если используем CentOS или если используем данную систему безопасности на Ubuntu:
Брандмауэр
Если используем firewalld (по умолчанию в CentOS):
firewall-cmd –permanent –add-port=25/tcp –add-port=110/tcp –add-port=143/tcp
Если используем iptables (по умолчанию в Ubuntu):
iptables -A INPUT -p tcp –dport 25 -j ACCEPT
iptables -A INPUT -p tcp –dport 110 -j ACCEPT
iptables -A INPUT -p tcp –dport 143 -j ACCEPT
apt-get install iptables-persistent
- в данном примере мы разрешили SMTP (25), POP3 (110), IMAP (143).
Установка NGINX
В зависимости от операционной системы, установка NGINX немного отличается.
или Linux Centos:
yum install nginx
или Linux Ubuntu:
apt install nginx
Разрешаем автозапуск сервиса и запускаем его:
systemctl enable nginx
systemctl start nginx
Если в системе уже установлен NGINX, проверяем с какими модулями он работает:
Мы получим список опций, с которыми собран веб-сервер — среди них мы должны увидеть –with-mail. Если нужного модуля нет, нужно обновить nginx
Настройка NGINX
Открываем конфигурационный файл nginx и добавляем опцию mail:
vi /etc/nginx/nginx.conf
mail <
server_name mail.domain.local;
auth_http localhost:80/auth.php;
server <
listen 25;
protocol smtp;
smtp_auth login plain cram-md5;
>
server <
listen 110;
protocol pop3;
pop3_auth plain apop cram-md5;
>
server <
listen 143;
protocol imap;
>
>
- server_name — имя почтового сервера, которое будет отображаться при SMTP-приветствии.
- auth_http — веб-сервер и URL для запроса аутентификации.
- proxy_pass_error_message — разрешает или запрещает показ сообщения при неудачной аутентификации.
- listen — порт, на котором прослушиваются запросы.
- protocol — протокол приложения, для которого прослушивается соответствующий порт.
- smtp_auth — доступные методы аутентификации для SMTP.
- pop3_auth — доступные методы аутентификации для POP3.
В секции http – server дописываем:
server <
listen 80 default_server;
listen [::]:80 default_server;
.
.php$ <
set $root_path /usr/share/nginx/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
include fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
>
…
*в данном примере мы добавили правило обработки файлов php через FastCGI, который будет работать на локальном сервере, порту 9000. Домашняя директория для хранения скриптов — /usr/share/nginx/html.
Перезапускаем сервер nginx:
systemctl restart nginx
Установка и настройка PHP
Для выполнения аутентификации с помощью PHP, необходимо установить в систему следующие пакеты.
Если CentOS:
yum install php php-fpm
Если Ubuntu:
apt-get install php php-fpm
systemctl enable php-fpm
systemctl start php-fpm
Аутентификация
Проверка логина и пароля выполняется скриптом, путь до которого задается опцией auth_http. В нашем примере, это скрипт на PHP.
Пример официальной заготовки для скрипта проверки логина и пароля:
vi /usr/share/nginx/html/auth.php
*данный скрипт принимает любые логин и пароль и перенаправляет запросы на серверы 192.168.1.22 и 192.168.1.33. Чтобы задать алгоритм аутентификации, редактируем строки 61 – 64. За возврат серверов, на которые идет перенаправление отвечают строки 73 – 77 — в данном примере если логин начинается на символы “a”, “c”, “f”, “g”, то перенаправление будет на сервер mailhost01, иначе, на mailhost02. Сопоставление имен серверов с IP-адресами можно задать на строках 31, 32, в противном случае, обращение будет идти по доменному имени.
Настройка почтового сервера
Обмен данными между NGINX прокси и почтовым сервером идут в открытом виде. Необходимо добавить в исключение возможность аутентификации по механизму PLAIN. Например, для настройки dovecot, делаем следующее:
remote 192.168.1.11 <
disable_plaintext_auth = no
>
*в данном примере мы разрешили PLAIN-запросы на аутентификацию с сервера 192.168.1.11.
- если ssl будет иметь значение required, проверка не будет работать, так как получится, что с одной стороны сервер разрешает запросы в открытом виде, но требует шифрование ssl.
Перезапускаем Dovecot сервис:
systemctl restart dovecot
Настройка клиента
Можно перейти к проверки настройки нашего прокси. Для этого в настройках клиента в качестве IMAP/POP2/SMTP указываем адрес или имя сервера nginx, например:
*в данном примере почтовый клиент настраивается для подключения к серверу 192.168.1.11 по открытым портам 143 (IMAP) и 25 (SMTP).
Шифрование
Теперь настроим SSL-подключение. Nginx должен быть собран с модулем mail_ssl_module — проверяем командой:
При отсутствии необходимого модуля, пересобираем nginx.
После редактируем наш конфигурационный файл:
vi /etc/nginx/nginx.conf
mail <
server_name mail.domain.local;
auth_http localhost/auth.php;
ssl on;
ssl_certificate /etc/ssl/nginx/public.crt;
ssl_certificate_key /etc/ssl/nginx/private.key;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
server <
listen 110;
protocol pop3;
pop3_auth plain apop cram-md5;
>
server <
listen 143;
protocol imap;
>
>
mkdir -p /etc/ssl/nginx
openssl req -new -x509 -days 1461 -nodes -out /etc/ssl/nginx/public.crt -keyout /etc/ssl/nginx/private.key -subj “/C=RU/ST=SPb/L=SPb/O=Global Security/OU=IT Department/CN=test.dmosk.local/CN=test”
*где /etc/ssl/nginx/ — каталог хранения сертификатов, subj — индивидуальные настройки для сертификата.
systemctl restart nginx
Логирование
Для анализа ошибок включаем сохранение лога в файл:
vi /etc/nginx/nginx.conf
mail <
.
error_log /var/log/nginx/mail_proxy_error;
.
>
systemctl restart nginx
Просмотр лога запускаем командой:
tail -f /var/log/nginx/mail_proxy_error
Возможные проблемы
bind() to x.x.x.x:XXX failed (13: Permission denied)
Ошибка возникаем при попытке перезапустить службу nginx. При этом, проверка конфигурационного файла командой nginx -t проходит корректно.
Причина: срабатывает система безопасности SELinux.
