на главнуюВсе эхи RU.UNIX.BSD
войти ?

Re: Аварийный вход в LAN через сотовый модем

От Dmitry Dolzenko (2:5020/400) к Eugene Grosbein

В ответ на Заголовок предыдущего сообщения в треде (Имя Автора)


From: Dmitry Dolzenko <dol@mig.phys.msu.ru>

28.09.2020 10:42, Eugene Grosbein пишет:
> 26 сент. 2020, суббота, в 14:03 NOVT, Dmitry Dolzenko написал(а):
>
> DD> Арендую VPS, к нему сделаю туннель через tp-link, и резервный mx на этом
> DD> VPS с пропихиванием почты в случае чего по vpn тоннелю на основной MX.
>
> Вообще конкретно с SMTP это не особая проблема, потому что очереди
> на доставку есть у всех серверов отправителей, в крайнем случае
> почта полежит там, при условии что у тебя зарезервирован DNS.
>
> А если не зарезервирован DNS, ты хоть делай себе доступный резервный MX,
> хоть не делай - почта на него даже не пойдет.
>
> И, допустим, ты сделал себе резервный MX и он принимает почту и льёт
> её через резервный канал поверх LTE. А LTE идёт через операторские соты и
> конкурирует за полосу с другими клиентами оператора, которые смотрят
> футбол на ютубчике или киношечки. И вполне может случиться так,
> что почта с резервного MX тебе станет забивать доступную тебе ширину.
>
> А кроме того, ты очень быстро столкнёшься с тем фактом,
> что спамеры очень любят слать спам через низкоприоритетные
> (резервные) MX вместо основного, даже когда основной нормально
> доступен, потому что наивно настроенный резервный MX легче
> принимает всякий мусор. Hапример, основной MX может сразу отбивать
> почту на несуществующие локальные ящики, а резервный MX
> может принимать на любые адреса домена, затем при попытке доставки
> на основной сервер получит отлуп из-за несуществования имени,
> так что будет сгенерирован DSN на скорее всего подставной
> адрес отправителя и твой резервный MX отправит спам-письмо
> в виде возврата невинной жертве. За такое ты сам быстро попадёшь
> в черные списки.
>
> Это можно пытаться решить с помощью milter-ahead (в случае sendmail)
> или ещё каких наворотов, но я бы вообще сильно не парился
> созданием резервного MX для LTE, почта спокойно полежит в очередях
> серверов отправителей. А вот вторичный внешний DNS завести обязательно.
>
> DD> Плюс скрипт на основном роутере конторы, который переключает роутинг в
> DD> случае проблем на tp-link.
> DD> Есть еще нерешенная проблема с вебсервером конторы, который не виден в
> DD> случае падения канала.
> DD> Первое что приходит на ум - поставить на VPS nginx в режиме reverse
> DD> proxy с работой по 2 каналам. В случае падения основного переключение на
> DD> резерв.
> DD> Или может есть способ лучше?
>
> Обратный прокси на VPS добавит тебе заметных задержек при обращении
> к сайту, а интерактивный HTTP(S) к задержкам чувствителен.
>
> Да, есть способ лучше - подключить второго оператора фиксированной связи :-)
> Это, кстати, кардинально решает проблему с почтой и с DNS:
> почта будет приходить по "резервной" записи MX реально на основной
> почтовый сервер, и DNS будет зарезервирован так же второй записью NS.
>
> А сайт можно вообще вынести на внешний хостинг.
> Качественное резервирование без затрат скорее утопия.
>
> Eugene

Да, сайт надо на внешний хостинг, ты прав.

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

По поводу почты - при падении канала ее критично важно получать и
отправлять, поэтому вариант с лежанием в очереди не подходит.

А если на резервном VPS 25 порт пробросить через туннель на основной
почтовый сервер какой то затычкой. Может тем же ipfw получится?

IP_VPS:25 ---vpn ---- IP_MAILSERV:25

это не решит проблему с валом отбойников?

/D
--- ifmail v.2.15dev5.4
* Origin: Demos online service (2:5020/400)

Ответы на это письмо:

From: Username
Заголовок следующего сообщения в треде может быть длинным и его придется перенести на новую строку

From: Username
Или коротким

FGHI-url этого письма: area://RU.UNIX.BSD?msgid=<1187514739@ddt.demos.su>+af6196e4