Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.UNIX.BSD
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.UNIX.BSD с датами от 18 Jan 11 22:51:00 до 18 Jan 24 18:16:22, всего сообщений: 10753
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 10005 из 10753 ==================================== RU.UNIX.BSD =
От   : Eugene Grosbein                  2:5006/1           28 Sep 20 10:42:06
Кому : Dmitry Dolzenko                                     28 Sep 20 10:42:06
Тема : Re: Аварийный вход в LAN через сотовый модем
FGHI : area://RU.UNIX.BSD?msgid=grosbein.net+596ce57a
На   : area://RU.UNIX.BSD?msgid=ddt.demos.su+46c80932
= Кодировка сообщения определена как: IBM866 =================================
Ответ: area://RU.UNIX.BSD?msgid=<1187514739@ddt.demos.su>+af6196e4
==============================================================================
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
--- slrn/1.0.3 (FreeBSD)
* Origin: RDTC JSC (2:5006/1@fidonet)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.078477 секунды