Вход в панель управления Кинетик настроен по https через обратный прокси Synology. После очередного обновления ОС Кинетика невозможно авторизоваться в веб-панели, ошибка Неверное имя пользователя или пароль.

Решение:

Допустим доменное имя Кинетика router.aaaa.com, локальный адрес 192.168.1.1 и слушает порт 81

Вход в него был настроен через обратный прокси Synology:

Источник:

Протокол HTTPS

Имя router.aaa.com

Порт 443

Назначение:

Протокол HTTP

Имя хоста 192.168.1.1

Порт 81

В настройках обратного прокси нужно создать пользовательский заголовок Origin со значением http://router.aaa.com

Применить изменения и все снова заработает, авторизация будет проходить успешно.

В файле /var/packages/MailServer/target/etc/template/opendkim.template ищите параметр RequireSafeKeys. По умолчанию он имеет значение Yes. Меняем значение на No, сохраняем файл, выключаем и снова включаем DKIM на Mailserver. Убеждаемся, что письма уходят и идем искать какие же именно права должны быть у файлов ключей.

Все дело в том, что Microsoft SMTP Server может использовать устаревшие версии TLS (например, TLS 1.0 или 1.1 или 1.2) в то время как на Synology в настройках безопасности по умолчанию включена “промежуточная совместимость”, исключающая использование устаревших протоколов.

Для того, чтобы успешно получать почту от Microsoft SMTP Server необходимо включить “совместимость со старыми версиями”.

Для этого нужно перейти в панель управления – безопасность – дополнительно и выбрать режим совместимости со старыми версиями. Эта настройка будет применяться ко всем службам Synology. Если нужно применить режим совместимости со старыми версиями только для почтового сервера, то нужно перейти в пользовательские настройки включить этот режим конкретно для почтового сервера.

После этого Synology Mail Server будет принимать почту от Microsoft SMTP Server без проблем.

Проблема с Microsoft Outlook достаточно известная, но не будешь же убеждать каждого такого клиента пересаживаться на другой почтовый софт. Таким образом, решать задачу предстоит на стороне сервера. Приступим:

1. Необходимо подключиться к Synology по SSH с правами администратора.
2. Открываем файл @appstore/MailServer/etc/template/opendkim.template
3. Ищем в нем параметр On-BadSignature. Он находится обычно в 383 строке или где-то рядом
4. Заменяем On-BadSignature reject на On-BadSignature accept
5. Перезапускаем почтовый сервер

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

В результате произведенных манипуляций все письма от Microsoft Outlook проходят успешно.

А вот что говорит про параметр On-BadSignature документация по Opendkim

On-BadSignature (строка)
Выбор действия, которое будет выполнено в случае, если подпись не прошла проверку. Возможные значения (с сокращенными формами в скобках):

1. accept (a) — принять сообщение;
2. discard (d) — отклонить сообщение;
3. quarantine (q) — поместить сообщение в карантин;
4. reject (r) — отклонить сообщение;
5. tempfail (t) — временно отклонить сообщение. Обратите внимание, что флаг «t» (тестирование) в ключе DKIM обходит это ограничение. Неверная подпись, ссылающаяся на флаг тестирования, всё равно будет доставлена, хотя в добавленном поле «Результаты аутентификации» будет указан как неудачный результат, так и режим тестирования, чтобы получатели сообщения могли принять соответствующие меры.

В какой-то момент я стал замечать, что все больше почты проходит через запасной почтовик, а не через основной. Пошел смотреть логи postfix и увидел, что очень много писем отклоняются сервером при проверке SPF с ошибкой Policy action=DEFER_IF_PERMIT SPF-Result=mail.xxxxxxx.ru: ‘SERVFAIL’ error on DNS ‘TXT’ lookup. Из чего следует, что сервер отказывается принять письмо, потому что не смог спросить запись SPF у DNS сервера, обслуживающего mail.xxxxxxx.ru. Диагностика по ssh подтвердила проблему. Несмотря на то, что nslookup отдает ip адрес mail.xxxxxxx.ru, далее следует все та же SERVFAIL. Стоило прописать почтовому серверу в качестве DNS не адрес роутера, а реальные адреса DNS серверов, как ошибки улетучились и вся почта пошла на основной сервер.

С левой стороны все прошло куда успешнее. Ничего ломать не пришлось, барабан с трудом, но снялся:

С виду все не так плохо и колодки совсем не вглядят изношенными. Но есть некоторые но… Собранные колодки на левой стороне выглядят так:

На левой стороне все цело, поэтому использовались штатные пружины и крепеж.

 А теперь, собственно, в чем была проблема. С обеих сторон заклинило рычаги. Если с правой стороны рычаг еще можно сдвинуть с большим усилием, то слева рычаг сдвинуть с места не удалось совсем. Если бы не заклинило рычаги колодки могли запросто проходить еще столько же. Не пренебрегайте регулярным обслуживанием задних тормозных механизмов.

Загружаем на Микротик routeros-7.13.5-arm.npk и wireless-7.13.5-arm.npk, затем идем в system -> packages, нажимаем Downgrade и ждем перезагрузки. Роутер загрузится с прошивкой 13.5. После нужно зайти в System -> RouterBoard и нажать там кнопочку Upgrade. Роутер снова перезагрузится. На этом откат к предыдущей прошивки завершен.

После возврата к 13.5 Микротик снова подключился к удаленному серверу WireGuard без всяких проблем.

Указанный рецепт точно работает на Mikrotik RB4011iGS+5HacQ2HnD

Внезапно выяснилось, что очень многие домены не содержат в DNS записи DMARC.

Это приводит к тому, что MailServer, пытаясь проверить подлинность отправителя, получает в ответ информацию об ошибках проверки подлинности и не пропускает входящую почту.

Если со включенным DMARC к вам не доходит почта, попробуйте выключить эту опцию в настройках проверки подлинности на вкладке “Безопасность”.

Админам почтовых серверов рекомендую добавить запись DMARC  в DNS записи домена.