+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Проблема с IPsec после обновления до версии 6.42

Проблема с IPsec после обновления до версии 6.42, RouterOS

mikruser

Guest

04.07.2018 12:40:00

Привет! После обновления с версии 6.41.4 на 6.42.5 трафик перестал проходить через туннель (туннель установлен, но трафик не идет). После отката обратно на 6.41.4 всё снова работает нормально. Что изменилось в версии 6.42, из-за чего такое произошло?

mikruser Guest	#2 0 20.08.2018 10:26:00 6.42.7 тоже столкнулся с этой проблемой!

mikruser Guest	#3 0 25.09.2018 16:47:00 6.43.2 тоже столкнулся с этой проблемой!

mikruser Guest	#4 0 18.10.2018 10:46:00 6.43.4 тоже с такой проблемой!

Chupaka Guest	#5 0 18.10.2018 16:03:00 Ты это сделал?

mikruser Guest	#6 0 18.10.2018 16:56:00 Это поведение легко воспроизвести в тестовой лаборатории.

sindy

Guest

18.10.2018 17:23:00

Главное — отправить письмо в поддержку с чётким описанием проблемы, ты хотя бы это сделал? Потому что размещать пост на форуме — не способ сообщить Mikrotik о проблеме, они не читают каждый пост на форуме, а вот каждое письмо, которое приходит на support@mikrotik.com, они точно читают. Отправка supout.rif облегчает (а иногда и вообще делает возможным) анализ для ребят из поддержки, потому что в этом файле собрана вся нужная информация в одном месте; им действительно нужна полная конфигурация, включая динамические элементы, которых нет в экспорте (например, динамически назначенный адрес может конфликтовать с вручную настроенным), а также данные о модели routerboard, версии RouterOS и актуальной версии прошивки. Если описание проблемы чёткое, то supout.rif может быть и не нужен, но формальный процесс, который поддержка обязана соблюдать, заставляет их его запрашивать, так как альтернативные способы сбора информации занимают у них больше времени. Поэтому я нашёл удобнее менять пароли и адреса (или лучше сразу настроить среду без публичных адресов) и сгенерировать supout.rif, чем спорить с ними, зачем он вообще нужен. Но повторюсь, главное — чётко описать проблему и использовать правильный канал связи.

Chupaka Guest	#8 0 18.10.2018 19:39:00 Ты им написал, чтобы они могли попытаться воспроизвести проблему?

emils

Guest

19.10.2018 08:11:00

Раз уж ты так не хочешь обращаться в поддержку, не мог бы объяснить свою настройку и логику за конфигурацией политики здесь? Я не могу представить ни одного случая, когда повторяющий устройство должен создавать динамическую политику с dst-address=0.0.0.0/0. В более поздних версиях (6.42+) есть мера безопасности, которая запрещает это, чтобы инициатор не мог случайно нарушить работу сети на стороне ответчика.

mikruser

Guest

#10

19.10.2018 09:45:00

Можешь объяснить, как у тебя устроена настройка и логика за конфигурацией политики здесь? Я не могу придумать ни одного случая, когда резондер должен создавать динамическую политику с dst-address=0.0.0.0/0. У нас много подсетей, и вместо того, чтобы создавать отдельную политику для каждой подсети, мы сделали одну на 0.0.0.0/0. В более новых версиях (6.42+) появилась мера безопасности, которая запрещает это, чтобы не дать инициатору возможность нарушить работу сети на стороне резондера. Моя конфигурация работала отлично семь лет, и только 6.42 сломала мою сеть. Почему вы не написали про эти фундаментальные изменения в changelog 6.42??

F1le Guest	#11 0 27.11.2018 00:39:00 Подтверждаю. Та же проблема с IPSec… Есть какие-нибудь решения?

DaveNISC

Guest

#12

15.04.2019 16:39:00

Похоже, у ipsec много проблем. Один из моих клиентов обновил роутер и потерял соединение ipsec и NAT. А сейчас у меня проблема с другим ipsec: он проработал неделю, а потом перестал работать. Пока никому не удалось найти решение. Ipsec устанавливается без проблем, два роутера Mikrotik видят LAN, но хосты не могут пинговать друг друга, и при этом правило NAT не нарушено. Вот это загвоздка.

sindy Guest	#13 0 15.04.2019 17:11:00 Жалобы без технических подробностей ни к чему; помогает только анализ. Сетевое окружение — вещь динамичная, с кучей автоматических обновлений, которые иногда происходят без ведома пользователя, если производитель ОС считает их «критическими». Поэтому делать вывод, что проблема в Mikrotik, если вы его не обновляли (то есть когда он неделю работал, а потом перестал), — преждевременно без пошагового анализа трафика. Я не говорю, что проблема не может быть в Mikrotik, просто есть большая вероятность, что нет, и ее можно решить. Если же дело действительно в Mikrotik, это надо оформить так, чтобы R&D могло исправить баг. Рекомендую использовать /tool sniffer или /tool torch, чтобы проверить: доходят ли ICMP-пакеты до Mikrotik от хоста на одной стороне, приходят ли они в зашифрованном виде через WAN на другую сторону и уходят ли с LAN-интерфейса в сторону целевого хоста на другой стороне. То же самое нужно сделать для ответных пакетов. Также стоит проверить, показывает ли команда /ip ipsec installed-sa print вообще какие-то передаваемые пакеты. Всё это поможет понять, какой из устройств сбрасывает пакеты, и станет основой для выяснения причины. Если хотите, можете выложить конфигурационные экспорты обоих устройств, следуя подсказке в моей автоматической подписи.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры