И поверх нестандартного порта ещё повесить fail2ban, ибо в последнее время боты часто, от нечего делать, видимо, тыкаются всеми известными протоколами во все открытые порты.
Я бы ещё посмотрел, для очистки совести, что говорит про диски smart вообще и smartctl -l scterc. Но, учитывая аналогичное поведение SSD RAID1, это вероятно ничего не даст.
Идей больше нет, кроме проблем именно этого контроллера на именно этой платформе с именно этим ядром.
Если есть такая возможность, я бы проверил в сингл. Ибо если у вас там одновременно идёт активная запись или, что ещё хуже, лежит на пятом рейде база, то контроллер, сам по себе не самый шустрый, может основательно подтупливать.
Имя почтового сервера (в MX) может быть любым, лишь бы его можно было преобразовать в IP адрес через DNS. Хоть чайником назовите. Но оно не должно полностью совпадать с именем домена. Если хотите, чтобы совпадала, тогда используйте вариант с А-записью для домена (первый пример).
CNAME-записей вам для почты вообще не надо, я описание привёл просто для информации, ибо в других ответах упоминалось.
PTR вам надо создавать не в вашем домене, а в зоне in-addr.arpa., которой управляет хостинг-провайдер.
На самом деле, я привёл не совсем корректный пример с PTR, "1.2.3.4 PTR myserver.com." на практике означает запись "4 PTR myserver.com." в зоне 3.2.1.in-addr.arpa. и для того, чтобы создать там запись, вам надо поискать где-то параметрах сервера "reverse dns/reverse DNS record" или "обратная зона ДНС". Ну или как-то так :-)
MTA -- это mail transfer agent, программа доставки электронной почты, postfix/qmail/sendmail/десятки их (https://ru.wikipedia.org/wiki/Почтовый_сервер).
Чтобы проверить -- узнайте, какой у вас стоит (чтением документации по установленной ОС), если никакого, то поставьте (тот, что, согласно документации, используется в вашей ОС по умолчанию), а потом прочитайте документацию/how-to по настройке и проверьте, правильно ли и работает ли :-)
Старая трансляция сохранится, но, для того, чтобы она применилась, необходимо не только совпадение отправителя/получателя по адресам/портам/протоколам, но и (колдунство route-map) прохождение пакета через тот же интерфейс, чего не будет вследствие изменения маршрута по track.
Если в маршрутизаторе не наблюдается резкого дефицита памяти, то и фиг с ним, пусть висит, пока не отсохнет, никому не мешает :-) Опять же, меньше лишних действий -- меньше глюков :-)
Ещё момент, если переключение между провайдерами было кратковременным и потом вернулось к основному варианту, то всё, что ещё не отвалилось по тайм-аутам, продолжит работать с того же места и это хорошо.
Ну и на сладкое -- лично я дефолтные тайм-ауты трансляции считаю слегка расточительными и предложил бы их подрезать, но это сугубо IMHO.
Проблема-то как раз понятна. Менеджеры закачек тоже качают с одного IP, но открывают несколько TCP соединений. Т.е., согласно описанию топикстартера, получается, что провайдер режет скорость по потокам. Либо у него такая технология предоставления услуг.
Соответственно, объединение нескольких VPN линков в один виртуальный канал, с распределением пакетов типа round-roubin по ним должно увеличить скорость скачивания при условии только одного потока.
По tplink'у ничего посоветовать не могу. Может тогда вам воспользоваться схемой hotspot'а, т.е. открытая сеть, но для получения доступа к интернету необходимо авторизоваться через веб-страницу? Тогда можно посмотреть в сторону почти готового решения типа pfSense Captrive Portal.
Я никогда не сталкивался с оборудованием tplink (или как правильно?), поэтому ничем не могу помочь в плане его настройки.
DD-WRT точно работает.
Вот тут товарищи из зала еще про wiki.openwrt.org/toh/start подсказывают.
А модель роутера, собственно, какая? :-)
