Недружественные почтовые сервера

Всем привет. Долго думал, о чём здесь написать — к сожалению, редко находится на это время и желание. Но недавно случилась одна не очень хорошая история, из которой я сделал выводы и решил, что эта информация может быть кому-то полезна, поэтому хочу рассказать о том, что произошло. История эта связана с электронной почтой, а если быть более точным — с отказом сетевой инфраструктуры РЖД в обслуживании персонального почтового сервера из-за его «недружественности».

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

Введение

Начну издалека. Мне всегда было интересно, как работает электронная почта в интернете, особенно когда я узнал о том, что протокол SMTP очень старый и сохранился в текущем виде до настоящего времени практически без изменений. В конечном итоге я решил попробовать свои силы в настройке собственного почтового сервера. Кто-то скажет, что это не нужно, хотя лично для меня это был весьма интересный и полезный опыт. Но я не буду здесь излагать технические подробности, так как статья вообще не об этом. Могу лишь сказать, что «туториалов» по поднятию своей почтовой системы в интернете сейчас можно найти довольно много, но я бы не рекомендовал считать их абсолютной истиной в последней инстанции, ведь тонкая настройка в конечном итоге вам всё равно потребуется, и понимать, за что именно отвечает тот или иной параметр конфигурации, необходимо.

Следует заметить, что когда я выбирал хостинг-провайдера, я не рассматривал варианты размещения сервера на территории РФ (думаю, причины этого понятны). Изучая различные предложения, в конце концов я остановил свой выбор на небольшом не очень известном провайдере из страны ЕС, географически расположенной недалеко от России (чтобы пинг был поменьше) — здесь без конкретики, чтобы никто не подумал, что я занимаюсь рекламой. Конечно, всё это происходило ещё до начала всем известных событий, поэтому тогда я не мог даже предполагать, что в будущем могут возникнуть проблемы с оплатой. Интересно, что когда всё это началось, провайдер прислал мне уведомление с предложением внести предоплату за как можно больший период времени — и это было ещё до того, как Visa и MasterCard объявили об уходе из РФ. Не знаю, действительно ли они могли предвидеть будущее, но я им очень благодарен — у меня как раз было некоторое количество свободных средств, и я решил воспользоваться ими и продлить аренду сервера на несколько лет вперёд. О прекращении обслуживания российских клиентов, равно как и вообще о своей позиции по отношению к происходящему, провайдер до сих пор не сообщил — поэтому пока можно надеяться, что сервер будет оставаться доступным в ближайшие годы, если только нас не отключат от мирового интернета. А когда наступит время следующей оплаты, ситуация может измениться (хотелось бы, чтобы в лучшую сторону).

Проблема

До недавнего времени никаких серьёзных проблем с отправкой и получением почты я не испытывал — я не осуществляю массовых рассылок, сервер поднимал в первую очередь для личного и семейного пользования. Да, иногда письма у получателей могут попадать в спам, но это общеизвестная проблема для мелких серверов, и со временем она проходит, если всё настроено корректно. Но, как это обычно бывает, беда пришла оттуда, откуда не ждали.

Примерно с начала марта я стал замечать, что мне перестали приходить на почту бланки электронных билетов от РЖД — я люблю ездить по железным дорогам и нередко покупаю билеты онлайн. Само по себе отсутствие бланков не является чем-то катастрофическим, так как все билеты доступны в приложении, а на большинство поездов есть электронная регистрация и при посадке нужно показывать только паспорт. Но сам факт того, что письма раньше приходили, а теперь перестали, насторожил.

Я решил связаться с поддержкой РЖД, отправив письмо по электронному адресу ticket@rzd.ru... и столкнулся с невозможностью это сделать. Сначала в логах почтового сервера начали появляться сообщения об ошибке DNS-резолвинга MX-хостов для домена rzd.ru.

Важный технический момент: одной из мер по предотвращению спама является необходимость обращаться к публичным провайдерам чёрных (и белых) списков доменов и IP-адресов. Эти списки реализованы как DNS-сервера, и их владельцы обычно разрешают использовать их бесплатно в некоммерческих целях, если количество запросов не очень большое. Но при использовании открытых DNS-резолверов (таких как 1.1.1.1 или 8.8.8.8) отследить количество запросов невозможно, потому что этими резолверами пользуется огромное число людей по всему миру. Решением данной проблемы является установка на почтовый сервер локального рекурсивного DNS-резолвера (такого как, например, Unbound), который будет выполнять обращения к DNS-серверам самостоятельно.

Решить проблему с ошибкой резолвинга MX для rzd.ru было просто — Unbound позволяет перенаправлять запросы на другой DNS-сервер для любой зоны. Я добавил в конфигурацию следующие строчки:

forward-zone:
  name: "rzd.ru."
  forward-addr: 1.1.1.1

После этого резолвинг заработал, но письмо на ticket@rzd.ru всё равно не шло. На этот раз причина была в том, что соединение с сервером входящей почты РЖД не устанавливалось из-за таймаута. Сначала я решил, что это какая-то временная проблема, и оставил письмо в очереди. Через 5 дней (да, тогда у меня ещё было терпение) письмо вернулось обратно как недоставленное — соединиться с серверами РЖД так и не удалось.

Переписка с РЖД

Здесь я вспомнил, что в новостях некоторое время назад сообщали о DDoS-атаках на инфраструктуру РЖД, и предположил, что подсеть, где находится мой почтовый сервер, была заблокирована в целях защиты от этих атак. Я не знаю, действительно ли велись из данной подсети какие-то атаки или нет, но мне точно известно, что мой сервер в них не участвовал — наверное, если я напишу об этом в РЖД, его разблокируют? С этими наивными мыслями я решил составить обращение через форму обратной связи РЖД. Ответ они обещали дать в течение 30 дней, но, как ни странно, он пришёл относительно быстро — за 9 дней. Только вот либо я недостаточно подробно изложил суть проблемы, либо сами РЖД решили не заморачиваться, поэтому весь их ответ свёлся к просьбе проверить папку «Спам»:

Интересно, что в контактной форме я указывал обратный адрес, обслуживаемый моим почтовым сервером. И ответ пришёл именно на него, но не с серверов РЖД, а с серверов Google. С серверами РЖД связи всё ещё не было (спойлер: и нет до сих пор). Какое-то время я ждал, надеясь, что проблема всё-таки временная и разрешится через несколько дней — но, конечно же, этого не произошло, поэтому я написал ещё одно письмо уже непосредственно в поддержку на ticket@rzd.ru, где постарался изложить ситуацию как можно подробнее. По понятным причинам мне пришлось делать это с аккаунта Gmail, который раньше был моим основным почтовым аккаунтом, а теперь используется как резервный. Для солидности я представился не единственным владельцем почтового сервера, а одним из его системных администраторов, и сообщил, что на нём зарегистрировано несколько пользователей, которые тоже клиенты РЖД и испытывают аналогичные проблемы. Также я поблагодарил их за предложение проверить папку «Спам», но отметил, что оно является бессмысленным, поскольку мне доступны все логи соединений на сервере. И ещё я напомнил им про то, что письма не только не приходят, но и не отправляются.

В этот раз ответ пришёл быстрее, но ничего полезного в нём опять не было. Сотрудники РЖД просто попробовали соединиться с моим сервером, у них это сделать не получилось, и они сказали, что проблема на моей стороне:

Такой вариант действительно не исключается — ровно до тех пор, пока не установлено, где именно происходит обрыв соединения. Но раз сотрудники РЖД решили не заниматься выяснением подробностей, мне пришлось делать это самостоятельно. Для этого я использовал утилиту traceroute в TCP-режиме, указав порт 25 (основной порт SMTP-соединений между почтовыми серверами) в качестве целевого. Результат трассировки можно видеть ниже — я скрыл IP-адреса некоторых узлов в начале маршрута, чтобы не выдавать информацию о провайдере:

$ traceroute -T -O info -p 25 gvc-cggw-cgfe-01.rzd.ru
traceroute to gvc-cggw-cgfe-01.rzd.ru (217.175.155.64), 30 hops max, 60 byte packets
 1  <REDACTED>  0.184 ms  0.124 ms  0.111 ms
 2  <REDACTED>  0.363 ms  0.352 ms  0.351 ms
 3  <REDACTED>  0.458 ms  0.449 ms  0.439 ms
 4  <REDACTED>  0.370 ms  0.354 ms  0.340 ms
 5  <REDACTED>  13.133 ms  13.120 ms  13.092 ms
 6  GW-TransTeleCom.retn.net (87.245.249.47)  23.123 ms  22.941 ms  22.923 ms
 7  spb14ra.transtelecom.net (188.43.208.50)  21.852 ms spb14ra.transtelecom.net (188.43.208.82)  21.727 ms spb14ra.transtelecom.net (188.43.208.50)  21.761 ms
 8  spb14ra.transtelecom.net (188.43.208.78)  23.299 ms spb14ra.transtelecom.net (188.43.208.86)  24.061 ms  23.582 ms
 9  mskn17ra.transtelecom.net (188.43.235.34)  30.704 ms  30.695 ms  30.725 ms
10  CSS-gw.transtelecom.net (188.43.235.33)  29.512 ms  29.702 ms  30.975 ms
11  * * *
...
30  * * *

Здесь видно, что трафик доходит до узла CSS-gw.transtelecom.net (188.43.235.33) и дальше попадает в чёрную дыру. Чтобы понять, что происходит, я попробовал провести аналогичную трассировку, но уже с сервера, расположенного на территории РФ. Результаты для сравнения ниже — всё ещё не хочу рекламировать провайдеров, поэтому скрываю начальные адреса и в этот раз:

$ traceroute -T -O info -p 25 gvc-cggw-cgfe-01.rzd.ru
traceroute to gvc-cggw-cgfe-01.rzd.ru (217.175.155.64), 30 hops max, 60 byte packets
 1  <REDACTED>  0.274 ms  21.345 ms  0.324 ms
 2  <REDACTED>  0.303 ms  0.578 ms  0.643 ms
 3  <REDACTED>  0.654 ms  0.605 ms <REDACTED>  1.602 ms
 4  <REDACTED>  1.344 ms * *
 5  * mskn17ra.transtelecom.net (188.43.235.34)  1.360 ms  1.330 ms
 6  mskn17ra.transtelecom.net (188.43.235.34)  1.464 ms  1.363 ms CSS-gw.transtelecom.net (188.43.235.33)  1.772 ms
 7  CSS-gw.transtelecom.net (188.43.235.33)  1.693 ms * *
 8  * * *
 9  gvc-cggw-cgfe-01.rzd.ru (217.175.155.64) <syn,ack>  2.190 ms * *

Здесь с соединением всё в порядке, и более того — видно, что после CSS-gw.transtelecom.net (188.43.235.33) трафик почти сразу попадает на почтовый сервер РЖД. Между ними есть ещё один узел, который нам не ответил, но можно предположить, что это какой-то межсетевой экран. В любом случае, если сравнить эти результаты с предыдущими, то становится ясно, что источник проблемы находится гораздо ближе к РЖД, чем к моему провайдеру.

Результаты обеих проверок (которые, вообще говоря, должны были делать сотрудники РЖД) я отправил в очередном обращении, попросив также по возможности провести обратную трассировку, чтобы получить ещё одно свидетельство о том, на чьей стороне проблема. Очередной ответ был получен в течение нескольких дней. В этот раз без комментариев, просто читайте:

На этом шаге мне надоело вести переписку с РЖД, хотя, в теории, её можно было продолжать и дальше, например, таким образом: США — недружественная страна, а сервера Gmail находятся в ней, так почему же тогда доступ к серверам Gmail не закрыт? Лично мне было бы интересно посмотреть, что они ответят на это, но у меня больше нет желания тратить своё время. И вне зависимости от их ответа, мы и так знаем, в чём причина: если перестанут приходить письма от РЖД на Gmail, то жалобы посыпятся уже тысячами. Поэтому заблокировать Gmail они не могут, а вот личный независимый почтовый сервер — вполне. Конечно, я не думаю, что они блокируют конкретные сервера по IP-адресам: скорее всего, такая блокировка осуществляется по подсетям или даже по страновой принадлежности из WHOIS-данных, а подсеть Gmail просто внесена в белый список.

Выводы

Какой вывод можно сделать из всей этой истории? Если вы можете обойти проблемы с оплатой и продолжаете использовать сервера за границей, нужно быть готовым к появлению аналогичных ситуаций в будущем. И речь здесь идёт не только об электронной почте, так как эти блокировки вряд ли затрагивают лишь один протокол. В частности, это может касаться, например, того же DNS — на моём сервере в последние два месяца такое тоже происходило (помните про проблему с резолвингом MX?).

Чтобы обойти блокировку, мне пришлось арендовать дополнительный виртуальный сервер на территории РФ и добавить его с низким приоритетом в список MX-хостов для своих почтовых доменов. На этом сервере никакая почта не хранится — он соединён с основным через VPN-туннель, в который перенаправляются все входящие SMTP-соединения. Пришлось повозиться с настройками, чтобы при подключении через VPN был виден реальный IP-адрес удалённой стороны, а не локальный адрес сервера в туннеле (это важно для антиспам-проверок), но в конце концов таким способом мне всё-таки удалось получить письмо от РЖД. В теории, через этот же сервер можно также и отправлять письма в РЖД, но, как я уже говорил, вести с ними дальнейшую переписку я не планирую.

Кто-то скажет, что описанной здесь проблемы можно было бы избежать, изначально выбрав сервер на территории РФ. На первый взгляд это действительно так, да и проблем с оплатой такого сервера сейчас бы не было. Но даже если не рассматривать вопросы, связанные с безопасностью хранения личной переписки на сервере в РФ, остаётся ещё такой момент: а вы точно уверены, что подобные блокировки могут осуществляться только со стороны российских сервисов? К примеру, ограничение веб-трафика по географическому признаку всегда являлось весьма распространённой практикой — это я говорю по своему опыту, так как нередко наблюдал сообщение «Access Denied» или просто таймауты при попытке зайти на какой-либо иностранный веб-сайт, и началось это задолго до 24 февраля 2022 года. А уж после этой даты я не вижу никаких препятствий к расширению подобных ограничений и на другие виды интернет-трафика — и затронуть они могут не только электронную почту.