Comments 30
Мы будем использовать эллиптические кривые, поэтому алгоритм DHE можно отключить
И где у вас в настройках параметр tls-cipher для которого используются эллиптические кривые?
Проверил всё ещё раз. Единственное, что я выяснил — файл VARS для EasyRSA нужно называть vars (маленькими буквами), иначе он не подхватывает настройки. Поправил этот момент в статье.
Параметр tls-cipher управляет наборами шифров на канале управления. Я его не настраивал, но, судя по логу, эллиптические кривые используются:
xxxxx openvpn[22488]: xxxxx:yyyy Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 521 bit EC, curve secp521r1, signature: RSA-SHA256Если это на самом деле не так — прошу знающих людей подсказать, и я внесу исправления, т.к. в криптографии не очень силён, и это не основной момент данной статьи. Приношу извинения.
Если и клиент и сервер поддерживают эллиптические кривые тогда все нормально, но если на клиенте что-то не так, например он старый или пользователь сам что-то поменял написав строку tls-cipher в своем конфиге, тогда не будут работать ваши эллиптические кривые. Если хотите их использовать то лучше жестко их прописать через параметр tls-cipher. Запустите в консоли сервера команду:
sudo openvpn --show-tls Так можно посмотреть полный список всех поддерживаемых алгоритмов шифрования данных когда в самом начале устанавлливается соединние и проверяется подлинность, выберете что-то нужно для вас и перечислите в своем конфиге через двоеточие, например так:
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256
Для вашей цели (прокинуть 1 туннель между серверами) openvpn делается значительно проще, на симметричных ключах. Easyrsa и сертификаты - это из пушки по воробьям. Хотя можно и без VPN, просто расположить в дружественной сети простой smtp relay. И пляски с iptables не нужны тогда.
Действительно, есть вариант сделать статический симметричный ключ, здесь описано, как это делается. Там же упоминаются и недостатки:
Ограничение на один клиент — если вам вдруг понадобиться подключить ещё одного клиента к VPN-серверу, то всё равно придётся перенастраивать;
Отсутствие совершенной прямой секретности — если ключ скомпрометирован, то весь уже перехваченный трафик можно взломать;
Необходимо передавать секретным ключ между машинами (желательно по безопасному каналу), т.е. ключ покидает пределы машины, на которой он сгенерирован.
Вывод: для параноиков, скорее всего, не подойдёт. Но если лень возиться с EasyRSA, то вполне.
Про smtp relay написал ниже.
Ограничение на один клиент — если вам вдруг понадобиться подключить ещё одного клиента к VPN-серверу, то всё равно придётся перенастраивать;
не совсем так.
каждый туннель может связывать две точки, но туннелей может быть много.
Необходимо передавать секретным ключ между машинами (желательно по безопасному каналу), т.е. ключ покидает пределы машины, на которой он сгенерирован.
ssh отлично решает эту проблему.
не совсем так. каждый туннель может связывать две точки, но туннелей может быть много.
Вы имеете в виду работу нескольких экземпляров OpenVPN на сервере, каждого со своей конфигурацией? Наверное, можно и так — тогда для каждого клиента будет свой ключ. В таком режиме как минимум будет проблема организации трафика между клиентами, если это по какой-то причине необходимо. Хотя в данном конкретном случае, описанном в статье, это всё же не нужно.
В целом, как я уже тут говорил, я не очень силён в вопросах криптографии, но вижу, что практически везде пишут, что static key менее безопасен, чем классический вариант с сертификатами. Хотя, возможно, на практике разница не слишком существенная.
Ограничение на один клиент
Для второго клиента поднимается второй экземпляр сервера ;) Сертификаты осмысленны, если клиентов десятки, и каждый день нужно кого то подключать или отключать.
если ключ скомпрометирован
Как, например?
Необходимо передавать секретным ключ между машинами
scp? Если кто-то слушает ваше ssh соединение - game over , пожалуй.
не правильнее было бы поставить на машине с vpn отдельный smtp-сервер?
Да, я упоминал, что как вариант можно сделать второй SMTP-сервер, который будет заниматься пересылкой сообщений. Преимущество в том, что он ещё будет работать как резервный (backup MX). Но мне кажется, что по сравнению с поднятием VPN это всё же менее тривиальная задача — как минимум из-за того, что в идеале такой промежуточный сервер должен иметь такие же настройки антиспама (включая антиспам-систему), что и основной — иначе, если он будет полагаться на нижестоящий спам-фильтр, то в случае отклонения им письма как спамерского он вынужден будет послать NDN (уведомление о недоставке) оригинальному отправителю по адресу MAIL FROM, так как он уже принял это письмо в очередь и закрыл соединение. А спамеры обычно подделывают адреса MAIL FROM, поэтому наш сервер сам превратится в источник спама. Чтобы этого не произошло, есть множество вариантов (отправка писем в чёрную дыру вместо возврата отправителю, синхронизация настроек антиспама, удалённый доступ к основной антиспам-системе и т.д.), но лично мне это кажется дополнительным геморроем, когда можно просто развернуть туннель и перенаправлять все соединения напрямую на основной сервер.
Дополню также, что такой промежуточный сервер, скорее всего, будет хранить временные данные в незашифрованном виде на диске — как минимум тот же Postfix это делает. Кому-то этот момент может быть важен, особенно если сервер находится на территории РФ.
У меня для подобных unfriendly серверов настроен отдельный postfix именно как backup MX на российском сервере. Но я решаю только задачу получения почты, а отправляю всё через mailgun.org - и, вроде, не было таких случаев, чтобы до кого-то не доходило (хотя тут всё меняется, очень быстро и не в лучшую сторону).
Именно backup MX всё-таки очень нужен, т.к. шанс потерять связь с зарубежным сервером сильно ненулевой (VPN отвалился, на зарубежном хостинге меня забанили, сервер тот упал и т.п.), время на устранение этой досадной неприятности может исчисляться часами, - а рассчитывать на то, что вся входящая почта за это время будет потом доставлена серверами отправителей при повторных попытках, не приходится, некоторые в этом плане ведут себя весьма странно (или не предпринимают повторных попыток вообще, или предпринимают дня через 3, когда письмо уже неактуально).
bounces на этом российском postfix'е пришлось отключить, да. Учитывая, что почта там только принимается, это не критично (хотя любопытства ради пытался разобраться, как отключить их только для внешних отправителей, а для своих доменов оставить - не осилил).
Хранение почты на российском сервере как раз в этом случае не напрягает, т.к. она (а) только входящая и (б) почти исключительно от российских госорганов и иже с ними, которые общаться с основным зарубежным SMTP-сервером, несмотря на более высокий приоритет его записи, не хотят по идеологическим соображениям.
Именно backup MX всё-таки очень нужен, т.к. шанс потерять связь с зарубежным сервером сильно ненулевой (VPN отвалился, на зарубежном хостинге меня забанили, сервер тот упал и т.п.), время на устранение этой досадной неприятности может исчисляться часами, - а рассчитывать на то, что вся входящая почта за это время будет потом доставлена серверами отправителей при повторных попытках, не приходится, некоторые в этом плане ведут себя весьма странно (или не предпринимают повторных попыток вообще, или предпринимают дня через 3, когда письмо уже неактуально).
Всё-таки, если провайдер решит забанить российских пользователей, скорее всего, он сообщит об этом заранее, и будет достаточно времени на перенос сервера в другое место. Уж сколько я новостей прочитал о прекращении обслуживания зарубежными компаниями клиентов из РФ, но не помню такого, чтобы отрубали мгновенно и без предупреждения (как минимум, если речь идёт о хостинг-провайдерах).
Насчёт даунтайма — лично у меня пока не было с этим проблем, видимо, повезло с провайдером. По идее, в дата-центре уровня TIER III и выше простой не может быть более пары часов в год (по моему опыту это пока что подтверждается). За такое время письма не должны теряться, даже если сервер не соблюдает RFC (которое, на минуточку, предусматривает максимальный период доставки аж до 5 дней — конечно, наверняка не все так делают, но повторные попытки доставки предприниматься обязаны). Если сервер недоступен несколько дней, то, вероятно, случилась какая-то катастрофическая ситуация (например, нас отключили от мирового интернета) и об этом будет известно почти сразу или даже заранее, так что будет время подготовиться.
В конечном итоге для резервирования я выбрал лайт-вариант — сихронизация архива писем с домашним сервером плюс резервная копия всех конфигов. В чрезвычайных обстоятельствах можно будет относительно быстро (пара часов плюс-минус) развернуть сервер заново на другой машине, и данные не пропадут. Пока что никаких проблем с приёмом почты, за исключеним описанной ранее «недружественности», я не испытывал.
ИМХО, вообще идеальный вариант — не backup MX, а полноценное зеркало с синхронизацией ящиков, антиспамом, IMAP-сервером и пр., но это задача не моего уровня опыта, и времени заниматься ей у меня в любом случае сейчас нет.
Ну забанить могут не только как российского пользователя (тем более, что по имеющимся у провайдера данным, пользователь я вообще не российский :) ), но и из-за какого-нибудь абьюза по причине того же спама (у меня пользователей мало и осознанно они точно спам рассылать не будут, но такие вещи иногда прилетают и совершенно на ровном месте).
Даунтайм, опять же, может случиться (и случался-таки, пока я всё это изначально настраивал) из-за моих собственных косяков с настройкой софта или проблем с этим софтом, а не из-за проблем в дата-центре.
Полный бэкап основного почтового сервера, конечно, делается. И полные снэпшоты виртуалки по расписанию, и онлайн бэкап в стороннее объектное хранилище всех писем и настроек... Но если неприятность случится, увы, у меня физически может уйти до суток на её устранение, даже в такой неприятной ситуации не всегда получается прям моментально бросить всё и заниматься только ей.
А вот настройки повторной отправки, повторюсь, по опыту бывают у людей очень странные. Знаю, что сервер был недоступен максимум пару часов. А письмо, отправленное в этот промежуток времени, приходит реально через 3 дня. Что особенно приятно, если это запрос клиента по договору, в котором электронка - официальный канал связи и срок ответа на такой запрос - 2 дня...
Зеркалом надо заняться, и не только почтового сервера, но и файлового хранилища (частного облака), LDAP-сервера, к которому оба предыдущих и не только за авторизацией ходят и т.п.... Надеюсь, никаких серьёзных проблем до момента, когда я это таки сделаю, не возникнет, потому что всё сразу в идеале построить физически невозможно успеть. И так только закончил процесс экстренного переноса всего со ставших неожиданно недоступными внешних сервисов на self-hosted решения...
Ну забанить могут не только как российского пользователя, но и из-за какого-нибудь абьюза по причине того же спама (у меня пользователей мало и осознанно они точно спам рассылать не будут, но такие вещи иногда прилетают и совершенно на ровном месте).
Разве что если кого-то взломают, и опять же, вряд ли будут банить сразу же, по крайней мере, если это нормальный провайдер. Ещё в Postfix на такой случай есть различные ограничения, например, на количество отправляемых писем в единицу времени с одного IP, так что как минимум масштабы проблемы можно попытаться таким образом сдержать.
Даунтайм, опять же, может случиться (и случался-таки, пока я всё это изначально настраивал) из-за моих собственных косяков с настройкой софта или проблем с этим софтом, а не из-за проблем в дата-центре
Вот что я люблю в Linux — один раз можно долго провозиться с настройкой, зато когда всё уже настроено, то работает как часы.
А вот настройки повторной отправки, повторюсь, по опыту бывают у людей очень странные. Знаю, что сервер был недоступен максимум пару часов. А письмо, отправленное в этот промежуток времени, приходит реально через 3 дня. Что особенно приятно, если это запрос клиента по договору, в котором электронка - официальный канал связи и срок ответа на такой запрос - 2 дня...
Вообще это действительно странно, потому что очень многие провайдеры (тот же Яндекс) используют грейлистинг, из-за которого сервер получателя вначале выдаёт 400-ю ошибку, которая считается временным сбоем — ровно таким же, каковым должно считаться для отправителя и отсутствие соединения с сервером. Я слышал, что проблемы с грейлистингом бывают (например, когда отправитель использует несколько серверов), но чтобы из-за него письма доходили через 3 дня — ни разу. Скорее всего, опять же, дело в криво написанном SMTP-клиенте, который по-разному воспринимает отсутствие связи и 400-е коды ответа SMTP.
Тогда как минимум у mail.ru криво написанный клиент. Уже пару раз приходилось ловить ситуацию: отправитель на mail.ru, получатель — обычный сервер свой, у сервера получателя проблемы с сетью на несколько часов и даже по smtp не отвечает, mailru присылает отправителю отбивку что retry timeout exceeded хотя дня не прошло даже.
И вот что с такими делать?
Ну в общем-то в такой настройке есть логика. Сегодня уже никто не ожидает, что письмо дойдёт через сутки
Не всегда почта — замена чата.
В том примере где это всплыло у меня — задержка с ответом в пару суток — допустима.
Почему они это не документировали никак?
У меня вот после этого появилось желание принять меры чтобы при вылете конкретной виртуалки с MTA или провайдера — не падало все нафиг.
виртуалка с secondary MX на другом канале интернета (но при этом физический хост тот же).
- http://www.junkemailfilter.com/spam/free_mx_backup_service.html как еще Backup MX с минимальным приоритетом для случая когда на основных вообще все лежит. Junkemailfilter работает с некоторыми особенностями на почте с ру-серверов но схема работоспособна (а то что через него задержка доставки ОТ 40 минут — уже не важно, раз дошло до этого). В процессе кстати и платные нашлись сервисы для Backup MX и даже в России но вот только из описания на сайте не все очевидно про сервис.
Поставить нормальный secondary MX на (например) Selectel тот же в данном случае не было возможности.
Backup MX нужен не вам, а РЖД ;). Вам (для решения задачи из статьи) нужен SMTP relay (с авторизацией какой нибудь, конечно) и дополнительное правило маршрутизации на вашем postfix. 1 строчка в transport_maps и 1 в smtp_sasl_password_maps.
-A POSTROUTING… разрешает исходящие соединения из локальной VPN-сети на интерфейс eth0 (в интернет) путём настройки SNAT для исходящих пакетов."
Вам по уму надо настроить не маскарад (он для динамически изменяющегося IP, хотя с ним и работает, но это не корректно, подробнее можно посмотреть здесь mum.mikrotik.com/presentations/EU17/presentation_4058_1490948376.pdf), а src-nat. В IP tables это делается так:
iptables -t nat -A POSTROUTING -s 172.16.0.0/24 -o eth0 -j SNAT --to IP_eth0
Реальных отличий я не заметил (скорее всего, в моём случае они если и есть, то несущественны), а вот то, что тут надо лишний раз прописывать внешний IP, мне не очень понравилось. С одной стороны, вряд ли он может измениться, с другой — если это всё-таки по каким-то причинам случилось, то можно забыть, что прописал его там, и потом удивляться, почему всё сломалось.
За ссылку спасибо, полезный материал, т.к. с iptables я знаком лишь на базовом уровне.
Недавно настраивал Wireguard. Задача была примерно такая же - обеспечить связь между сервером в интернете и другим "сервером" - домашним компом, например. На сервере стоит nginx и перебрасывает запросы на домашний компьютер, который отвечает. Всё делается не просто, а очень просто с помощью Wireguard. Никаких доступов в интернет через другой сервер - только локалка между двумя машинами. Я даже шпаргалку для себя сделал как это делается https://tavda.net/wireguard
Основные заморочки в настройке сервисов, чтобы данные уходили через "правильный" путь и не блокировались.
Ну а тем, кому нужен интернет и NAT и чтобы не заморачиваться со скриптами можно просто поставить Firewalld на Ubuntu. На 20.04 точно ставится и работает. Настраивается куда проще, чем iptables, например.
Спасибо большое за статью!
А не осилите заодно рассказать про собственный postfix и настройки? Вот сколько искал, более-менее современных и продуманных гайдов про свою почту на хабре вроде как нет. А это очень актуально, учитывая, например, принудительное закрытие гуглом Google Suite для старых пользователей.
Я вижу, что у вас очень много опыта (я бы например про bounce вообще не додумался, что его нужно отключать, так как сам почту никогда не поднимал), о котором я, и, думаю, многие, очень хотели бы узнать.
Какая связка сейчас считается надежной? Какой антиспам юзать? Какие настройки критичны для первоначальной работоспособности, чтобы все подряд не слали твои письма в спам и чтоб самому не стать случайно спамером, как с тем же bounce; обращались ли в конторы типа Spamhaus, чтобы восстановить справедливость, или у вас теплый ламповый прогретый мейл из тех времен, когда трава была зеленее, а сервера не требовали повально DMARC и т.д.
И еще один оффтопный вопрос не толко к автору, а ко всем: если у меня сейчас почта на домене, например, example.com, но гугловская, а я создам еще один поддомен, например, test.example.com, почту на нем, пропишу все записи для поддомена и начну его причесывать (добиваться, чтоб не попадало в спам), это зачтется, если я перенесу потом основную почту на домен второго уровня? Что вообще «самое важное» с точки зрения антиспама, домен, айпишник, может, записи какие?
Добрый день!
А не осилите заодно рассказать про собственный postfix и настройки? Вот сколько искал, более-менее современных и продуманных гайдов про свою почту на хабре вроде как нет. А это очень актуально, учитывая, например, принудительное закрытие гуглом Google Suite для старых пользователей.
К сожалению, у меня редко находится время и желание (особенно именно в такой комбинации) на то, чтобы что-то писать, а в ближайший месяц точно не получится. На создание этой и предыдущей статьи меня, можно сказать, вдохновили последние события, так что это скорее исключение, чем правило. Вообще, я не очень люблю этим заниматься.
Я вижу, что у вас очень много опыта (я бы например про bounce вообще не додумался, что его нужно отключать, так как сам почту никогда не поднимал), о котором я, и, думаю, многие, очень хотели бы узнать.
На самом деле не так много. Мой почтовый сервер работает чуть более полугода, и первые два месяца я практически каждый день что-то подкручивал в настройках, чтобы добиться того, чтобы всё работало именно так, как мне надо, а не как-то ещё.
Какая связка сейчас считается надежной?
Я использую Postfix + Dovecot, потому что лично мне показалось, что по этим двум программным продуктам больше всего документации. Ещё вроде бы часто используют Exim в качестве MTA и Cyrus в качестве IMAP-сервера. Но я не проводил сравнения используемого мной ПО с аналогами. Просто взял их потому, что в интерете именно по ним очень много руководств, от которых можно отталкиваться, если вообще ничего не понимаешь (а я, когда начинал настраивать, действительно мало что понимал).
Какой антиспам юзать?
Очень часто в туториалах упоминается SpamAssassin, но лично я использовал Rspamd, так как слышал, что у SpamAssassin'а могут быть проблемы с анализом писем в кодировке UTF-8. Но не могу сказать на 100%, актуальна ли данная проблема на сегодняшний день. Возможно, придётся потанцевать с бубном, чтобы её обойти. У Rspamd, с другой стороны, таких проблем нет, но и документации по нему явно меньше, как мне показалось.
Какие настройки критичны для первоначальной работоспособности, чтобы все подряд не слали твои письма в спам и чтоб самому не стать случайно спамером, как с тем же bounce; обращались ли в конторы типа Spamhaus, чтобы восстановить справедливость, или у вас теплый ламповый прогретый мейл из тех времен, когда трава была зеленее, а сервера не требовали повально DMARC и т.д.
Ранше я использовал почту для домена от Яндекса, так что домен остался. IP-адрес новый. По поводу попадания в спам лично у меня сложилось такое мнение, что даже если настроить всё абсолютно на 100% корректно, первое время всё равно такое возможно, если речь идёт об отправке почты крупным провайдерам (Gmail, Outlook etc). Складывается впечатление, что их антиспам-системы требуют какого-то минимального объёма отправляемой почты (суммарного или в единицу времени), чтобы этого избежать, но в случае с персональным сервером такие объёмы вряд ли достижимы. Однако со временем, скорее всего, ситуация наладится, особенно если просить получателей помечать ваши письма как не спам.
Самому стать спамером, если только не намеренно, возможно, если кто-то подберёт пароль к вашему аккаунту на сервере. Насколько я знаю, по умолчанию все современные почтовые сервера настроены так, чтобы не допускать пересылку писем на сторонние домены без авторизации. Также есть сервисы вроде MxToolbox, которые позволяют выявить многие потенциальные проблемы с почтой, включая и открытый релей (т.е. возможность неавторизованной пересылки).
обращались ли в конторы типа Spamhaus, чтобы восстановить справедливость
В чёрных списках моего IP не было изначально, но Spamhaus (и многие другие провайдеры) позволяют удалять IP из чёрных списков в автоматическом или ручном режиме (с подтверждением), особенно если написать им что-то вроде "IP был не мой, возможно с него раньше рассылали спам" и указать, что сейчас всё настроено корректно (в первую очередь PTR-запись и обратный её резолвинг по A/AAAA-записям).
сервера не требовали повально DMARC и т.д.
И сейчас не требуют - многие письма, которые я получаю (а получаю я в основном всякие уведомления, чеки и пр.) не авторизуются по DMARC из-за отсутствия DMARC-записи. По умолчанию Rspamd не добавляет за это штраф к спам-рейтингу письма. Это, конечно, не означает, что DMARC не стоит включать.
И еще один оффтопный вопрос не толко к автору, а ко всем: если у меня сейчас почта на домене, например, example.com, но гугловская, а я создам еще один поддомен, например, test.example.com, почту на нем, пропишу все записи для поддомена и начну его причесывать (добиваться, чтоб не попадало в спам), это зачтется, если я перенесу потом основную почту на домен второго уровня? Что вообще «самое важное» с точки зрения антиспама, домен, айпишник, может, записи какие?
Не уверен здесь на 100%, но, насколько мне известно, в первую очередь играют роль IP-адреса отправителя, а не домены. Но для доменов есть свои спам-листы. Ну и стоит не забывать про все эти SPF, DKIM, DMARC, чтобы не допускать возможности отправлять письма от имени вашего домена без авторизации.
Хороший гайд. У нас тоже один из почтовиков находится в "не дружественной" стране (а дружественные у нас беларусь, уганда, казахстан ?) - сейчас то одно отвалится, то другое. Последний "тренд" - перестали резолвится некоторые российские публичные почтовые системы -). DNS стояли гугловые и явно не гугл что то там намутил. Беда блин.
Можно поднять на VPN-шлюзе DNS-резолвер и использовать его с основного сервера в качестве резервного. Я так и сделал, но мне эта идея пришла в голову уже после написания статьи, и поскольку она и так получилась довольно длинной, решил не добавлять об этом упоминание. В целом, с этим всё довольно тривиально, когда туннель уже поднят. Я ставил в качестве резолвера Unbound, по нему хорошая документация на официальном сайте.
Как сделать VPN-туннель для недружественного почтового сервера