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

GRE over IPSec перестаёт работать, когда интерфейс PPPoE дергается.

GRE over IPSec перестаёт работать, когда интерфейс PPPoE дергается., RouterOS

loca995

Guest

01.09.2021 17:37:00

Всем привет! Ситуация следующая (если нужен сетевой график, могу предоставить).
HQ: два WAN.
BO: два и более WAN.

Чтобы обеспечить VPN-соединение с резервированием, для каждого WAN-подключения в BO установлены по два GRE-туннеля с HQ. В данном конкретном случае в BO три WAN, значит 6 GRE-туннелей. Каждый туннель имеет статический маршрут с разным расстоянием.

Всё работает нормально, пока не начинает «флапать» интерфейс PPPoE одного из WAN в BO. С этого момента GRE-туннель падает. Я даже не могу пропинговать удалённый адрес, использующийся для GRE-туннеля, с указанием правильного исходного адреса.

GRE-интерфейсы — сторона BO
Tunnel configuration — сторона BO
GRE-интерфейсы на HQ (имена интерфейсов такие же с обеих сторон)
Tunnel configuration — сторона HQ

Я начал тесты с первой фазы IPSec: состояние установлено, но значение RX равно 0. Вторая фаза тоже установлена. IPSec настроен в режиме туннеля.

Если пытаюсь пропинговать удалённый адрес с исходным адресом, как определено в политике Phase2, пинг не проходит. Это наводит меня на мысль о проблеме с IPSec, но следующие шаги ещё больше сбивают с толку.

Пинг с BO на HQ по loopback-интерфейсам

На скриншоте выше в трекинге соединений показано GRE-соединение. Таймаут GRE-соединения — 3 минуты. Если отключить GRE-интерфейсы с обеих сторон на три минуты, таймаут истекает. С этого момента я могу пропинговать loopback-интерфейсы на другой стороне.

Тогда я поднимаю GRE-интерфейсы с обеих сторон, и всё снова начинает работать отлично.

Ручное решение срабатывает всегда, но мне хотелось бы понять, в чём причина этой проблемы. У меня много GRE-туннелей, и каждое утро приходится проверять, проявилась ли эта проблема, и фиксить её. Очень сбит с толку.

Сначала думал, что проблема с IPSec при флапе PPPoE-интерфейса. Сейчас склоняюсь к мысли, что во время флапа что-то происходит в таблице маршрутизации, и каким-то образом GRE keepalive пакеты идут по другому маршруту и по какой-то причине остаются активными.

Очень буду признателен, если поможете решить эту проблему. Могу предоставить любую информацию или провести любые тесты по необходимости.

Спасибо,
Лоренцо

loca995 Guest	#2 0 27.09.2021 14:48:00 Привет, у кого-нибудь есть предложения? Я могу вызвать проблему когда угодно, но мне нужно решение, чтобы GRE не переставал работать. Спасибо.

sindy

Guest

27.09.2021 15:25:00

Тебе будет слишком больно поменять туннели с GRE на IPIP? Дело в том, что, как минимум с исправления какой-то уязвимости, связанной с GRE, в версии 6.45.x, описанная тобой проблема существует, и что забавно — только на некоторых архитектурах процессоров. Я перевёл все свои затронутые туннели на IPIP (в правилах файрвола включай ipencap, а не ipip!) и с тех пор всё работает отлично. Плюс в нагрузку — немного выигрываешь в MTU, ведь заголовки GRE больше, чем у IPIP, но Mikrotik не умеет их использовать, так что нельзя настроить несколько GRE-туннелей между двумя узлами, различая их по Tunnel-ID. Я так и не смог собрать достаточно доказательств, чтобы открыть тикет в поддержку Mikrotik, потому что воспроизвести проблему на своих лабораторных машинах так и не удалось, а вот отправлять supout.rif с продакшн-серверов с PSK-аутентификацией на IPsec не собираюсь, хотя Mikrotik утверждает, что PSK не сохраняется в supout.

loca995

Guest

28.09.2021 09:06:00

Привет, Синди! Спасибо за ответ. По крайней мере, теперь я знаю, что если перейти с GRE на IPIP, то эту проблему удастся решить! Конечно, это не просто, ведь речь идёт о более чем 200 туннелях… Но я могу попробовать на одном сайте и посмотреть. В любом случае было бы интересно разобраться именно с этой проблемой у GRE. В лаборатории воспроизвести её не получилось (что заставило меня задуматься, не связана ли она с каким-то правилом фаервола в HQ?), но в рабочей среде угадать это можно и воссоздать когда угодно. Было бы здорово, если бы техподдержка могла подключиться удалённо и увидеть, что происходит... Пока что я открыл тикет в Mikrotik и отправил туда эту переписку. Посмотрим, что из этого выйдет.

sindy Guest	#5 0 28.09.2021 09:52:00 Чтобы внести свою лепту — если я правильно помню, у меня была такая проблема, когда CHR был на одном конце, а RB1000AHx4 — на другом.

pe1chl

Guest

28.09.2021 11:01:00

Я использую такую конфигурацию и не вижу никаких проблем. Обратите внимание на ошибки брандмауэра (как уже упомянула Sindy, в последних версиях RouterOS есть баг. Входящий трафик GRE помечается как «недействительный» вместо «установленного» или «нового», и если вы блокируете недействительный трафик до того, как разрешите GRE, это вызывает проблемы с NAT на других роутерах. Когда IPsec проходит через NAT и сессия прерывается, она может перейти в неисправимое состояние. Это часто происходит, если ваш роутер стоит за каким-то другим устройством, например, AVM Fritzbox. Часто помогает настроить «проброс» трафика, в данном случае UDP портов 500 и 4500 на роутер.

sindy

Guest

28.09.2021 11:46:00

@pe1chl, к сожалению, та головная боль, которую описал автор письма, существует дополнительно к двум, которые ты упомянул. Я проделал домашнюю работу, чтобы обойти эти проблемы (исключение GRE из «drop invalid», меры для правильного восстановления IPsec после прерывания или перезапуска маршрутизатора на пути, правило фильтрации, позволяющее пропускать GRE-пакеты, исходящие из GRE-туннеля — твоя любимая тема с keepalive, — это правило нужно только для параноидальных файрволов), и всё равно иногда возникают проблемы. После сбоя или при первоначальной настройке GRE-туннеля, если больше ничего не трогать, приходится просто на 10 минут отключить GRE на обоих концах, а потом заново включить, чтобы всё заработало. Если этого не сделать, туннель остаётся сломанным навсегда, и это никак не связано даже с переустановкой SA.

pe1chl

Guest

28.09.2021 12:02:00

Понимаю, что это происходит только когда между ними есть ещё один NAT-маршрутизатор. NAT-маршрутизатор переводит исходную сессию на другой адрес, но с теми же номерами портов (500 и 4500). После сбоя NAT думает, что это новое подключение и ещё не удалил старое, поэтому решает изменить номер порта, потому что видит сессию на тот же IP/порт (500). В итоге правило NAT переводит на какой-то случайный порт, и стороны так и не встречаются. Отключение на 10 минут удаляет эту запись из таблицы NAT, и сессии снова становятся возможными. Когда я делаю «проброс портов» на NAT-маршрутизаторе, такого обычно не происходит, потому что роутер знает, что менять нужно только адрес, а не номер порта. На роутерах, которые напрямую в интернете без дополнительного NAT-маршрутизатора между ними, этой проблемы не наблюдаю, даже если один из них использует PPPoE.

Иногда встречаю другую проблему с PPPoE: если в магистральной сети происходит сбой, и PPPoE не закрывается и не открывается корректно, иногда интерфейс PPPoE не получает IPv4-адрес. IPv6-адрес он получает. Так как я настраиваю два туннеля — один GRE и один GRE6 — между каждой точкой, то вижу, что GRE6 функционирует нормально, а GRE — нет. У меня есть скрипт, который обнаруживает эту проблему и перезапускает интерфейс PPPoE, что восстанавливает оба туннеля без дополнительного вмешательства с моей стороны.

loca995

Guest

29.09.2021 07:53:00

У меня новости: я попробовал на одном сайте, но проблема та же! Может ли это означать, что у меня где-то проблема с файрволом в штаб-квартире? У меня CCR1036 в штабе и RB3011 в филиале… Я прочитал твои классные размышления по этой теме, и могу сказать, что у меня всегда публичный IP на интерфейсах PPPoE. У меня есть еще другие окружения с другими моделями Mikrotik, и там такой проблемы никогда не бывает. Единственное отличие — в других окружениях туннель GRE-IPIP не является основным шлюзом в филиале: может ли в этом дело? Но даже так, я не могу воспроизвести проблему в лабораторной среде.

Что касается того, что сказал @pe1chl, это довольно интересно, но я сосредоточусь на одном моменте: IPsec настроен в режиме туннеля, фаза 2 установлена. Политика второй фазы такова: src: x.x.x.x dst: y.y.y.y, где эти два адреса — удаленный и локальный, использующиеся для инициализации GRE-интерфейса. Я оставил CLI-сессию с пингом с x.x.x.x на y.y.y.y.

СЛУЧАЙ 1: GRE-туннель запущен и включен. Я специально отключаю и включаю интерфейс PPPoE. Пинг перестает работать и больше не восстанавливается, пока я не отключу два GRE-интерфейса (один в филиале, другой в штаб-квартире).

СЛУЧАЙ 2: GRE-туннель отключен. Я специально отключаю и включаю интерфейс PPPoE. Пинг перестает работать, но когда PPPoE поднимается, пинг начинает работать нормально.

Мне кажется, что неверная сессия GRE как-то ломает IPsec. Но все-таки, возможно, дело в файрволе штаба?

sindy

Guest

#10

29.09.2021 08:11:00

Надеюсь, одна из этих причин именно такова, иначе это означало бы, что обработка IPIP тоже работает с ошибками. Пожалуйста, пришлите анонимизированную конфигурацию обоих устройств (BO, где сейчас запущен IPIP, и HQ), смотрите мой автоматический подпись ниже для подсказки.

pe1chl

Guest

#11

29.09.2021 08:29:00

Если это та же самая проблема, что и у меня, то дело не в GRE или другом туннеле, а именно в IPsec. Любой stateful-файрвол (включая NAT, пример которого я приводил, и твой файрвол) может вызывать проблемы с IPsec, которые исчезают, если сессию на время «приглушить». Я даже написал скрипт, который запускаю на роутере, когда возникают такие проблемы:

/system script
add dont-require-permissions=no name=ipsecerrorhandler owner=admin policy=ftp,read,write,policy,test source="# сканируем буфер лога на ошибки IPsec
\n# когда ошибка «phase1 negotiation failed due to time up», временно блокируем отправителя
\n# это обход проблемы с некоторыми NAT-роутерами
\n\n:global lastTime;
\n\n:local currentBuf [ :toarray [ /log find topics=ipsec,error and message~\"phase1 negotiation failed due to\" ] ] ;
\n:local currentLineCount [ :len $currentBuf ] ;
\n\n:if ($currentLineCount > 0) do={
\n :local currentTime [/log get [ :pick $currentBuf ($currentLineCount -1) ] time ] ;
\n if ($currentTime != $lastTime) do={
\n :set lastTime $currentTime ;
\n :local currentMessage [/log get [ :pick $currentBuf ($currentLineCount -1) ] message ] ;
\n :if ($currentMessage~\"due to time up\") do={
\n :local ipaddress [:pick $currentMessage ([:find $currentMessage \"<=>\" ]+3) 99 ] ;
\n :set ipaddress [:pick $ipaddress 0 [:find $ipaddress \"[_\" ] ];
\n :local activepeers [ /ip ipsec active-peers find where remote-address=$ipaddress and state=established ] ;
\n :if ( [ :len $activepeers ] = 0 ) do={
\n :log info \"Временно блокируем $ipaddress из-за ошибок\" ;
\n /ip firewall address-list add list=blocked address=$ipaddress timeout=\"00:05:00\" ;
\n }
\n }
\n }
\n}"

Скрипт настроен запускаться каждые 2 минуты, и когда он находит удалённый адрес, испытывающий проблемы с установкой соединения, добавляет его в список. В файрволле нужно блокировать пакеты с адресов из этого списка. Через 5 минут (можно увеличить до 10 минут при необходимости) блокировка снимается, и соединение устанавливается снова.

loca995

Guest

#12

29.09.2021 11:06:00

Очень благодарен за помощь, но в данный момент конфигурация HQ — полный провал, мы её исправляем, но, думаю, понадобится несколько недель, чтобы получить точную настройку. Если проблема возникнет после исправления конфигурации, я все равно пришлю её вам.

Кстати, есть новости: @pe1chl, я провел еще тесты с коллегами, и, похоже, ты угадал. Мы создали новый IPIP-ТУННЕЛь с того же BO на другой Mikrotik (назовем его HQ-TEST), который не является HQ. Так что можно исключить проблему из-за маршрута по умолчанию в BO (то есть сам IPIP-туннель к HQ).

Проблема всё равно проявляется. Я отключил новый IPIP-ТУННЕЛь с HQ-TEST, выключил и включил интерфейсы PPPoE, но фаза 2 не работает. Для Mikrotik’ов BO и HQ-TEST состояние политики — «established», но пинг с источника до назначения не проходит.

Мой коллега попробовал уменьшить таймаут DPD на фазе 1 (очень жестко: примерно 1-1), и тогда фаза 2 всегда восстанавливается после переподключения PPPoE. Так что я начинаю думать, что причина связана именно с IPsec... но конкретно что — пока не понятно.

Какую конфигурацию DPD вы бы порекомендовали?

P.S. Похоже, если между BO и HQ-TEST нет трафика, когда PPPoE переподключается, IPsec фаза 2 работает. Если же трафик есть, например, IPIP keep alive или просто пинг, то при переподключении PPPoE фаза 2 остается «established», но перестаёт работать.

loca995 Guest	#13 0 02.10.2021 19:08:00 @sindy: после других тестов поведение полностью совпадает с описанным в теме IPSec становится повреждённым после переподключения PPPOE. Я видел, что ты уже заходил туда, есть какие-то советы по этому поводу?

sindy

Guest

#14

03.10.2021 11:21:00

Как написал @pe1chl, возможны проблемы с firewall/NAT, связанные с прерыванием PPPoE. Если между пирингами есть NAT, то и IKE (или IKEv2), и транспортные пакеты используют один и тот же UDP-поток, и как NAT Mikrotik, так и NAT на устройствах провайдера могут вести себя неожиданно, когда на одном конце меняется адрес и порт, а на другом по-прежнему помнят старые. При наличии нескольких WAN появляется ещё одна сложность — были случаи, когда SA после перезагрузки или сбоя маршрута выбирали неправильного пира локально, и удалённый пир игнорировал транспортные пакеты, так как они приходили через неверный SA. Для предложения шагов анализа нужна анонимизированная конфигурация. Возможно, стоит начать с публикации конфигурации со стороны BO, где работает IPIP-туннель (он не такой «катастрофический», как на HQ), и указать, получает ли каждый WAN одинаковый IP при каждом подключении PPPoE и является ли этот IP публичным или нет.

loca995

Guest

#15

04.10.2021 15:43:00

Привет, Синди! Сейчас у меня в дата-центре два тестовых WAN, поэтому я взял RB2011 для испытаний, настроил простую конфигурацию и симулировал, что это TEST-HQ. Потом подключился к рабочему BO через один IPSEC-туннель. Если я отключаю PPPoE на стороне TEST-HQ без настройки какого-либо туннеля (IPIP, GRE или другого), то флапы никак не влияют на статус IPsec Phase2. Но если я настраиваю IPIP или даже GRE-туннель между TEST-HQ и BO, то при отключении и повторном включении PPPoE на стороне HQ IPsec Phase 2 перестаёт работать. Прикрепил конфигурацию TEST-HQ — она довольно простая и понятная по сравнению с продакшен-HQ. Можешь, пожалуйста, глянуть и сказать, не вижу ли я чего-то не так? Я сейчас работаю над конфигурацией BO, но она будет готова только через пару дней. HQ-TEST.rsc (6.12 KB)

loca995

Guest

#16

12.10.2021 12:43:00

Привет, есть новости? Пока что я настроил тестовую среду с одним RB2011 и одним RB3011, у каждого из которых есть интернет-соединение от одного и того же провайдера. На RB2011 WAN-соединение организовано через интерфейс PPPoE. На RB3011 WAN-соединение тоже через PPPoE.

Если отключить и заново включить интерфейс PPPoE на RB2011, IPSec работает нормально. Если сделать то же самое на RB3011, IPSec перестаёт работать, и его приходится вручную перезапускать. Я приложил обе конфигурации. Очень простой сетап, не могли бы вы взглянуть?

Единственная разница между двумя настройками в том, что на RB2011 интернет подключён через беспроводное соединение, а на RB3011 — через FTTC-модем в режиме моста. Но для роутербордов это не должно играть роли, всё должно быть прозрачно…
HQ-2011.rsc (4.86 KB)
BO.rsc (4.87 KB)

markmcn

Guest

#17

13.10.2021 22:11:00

Не очень помогает, но ты не один с проблемами IPSec при сбоях PPPoE. У меня на RB1100AH4 IPSec ломается каждый раз, когда срабатывает PPPoE, и установленные SA очищаются. После этого IPSec не работает, пока не перезагрузишь устройство или не отключишь PPPoE примерно на 3-5 минут. Сейчас у меня идет обращение в техподдержку Tik. Возможно, стоит тоже связаться с поддержкой. Если у меня будут новости, поделюсь здесь. Спасибо, Марк.

loca995 Guest	#18 0 14.10.2021 11:01:00 Я подожду новостей, сейчас я уже довольно отчаян. А если попробовать выключить и снова включить политику phase2 на Mikrotik, что произойдет?

markmcn

Guest

#19

14.10.2021 12:52:00

У меня был неоднозначный опыт с отключением всех элементов конфигурации ipsec — peer, policy и так далее — и их длительным неактивным состоянием, но это срабатывает не всегда. Единственные надёжные способы, которые у меня работают, — удерживать PPPoE нажатым в течение 3-5 минут при появлении проблемы или просто перезагружать устройство. Это настоящая морока, и я очень надеюсь, что скоро исправят. Для меня это особенно странно, ведь проблема проявляется только на некоторых устройствах. Например, я вижу её на RB1100AH4, хотя у меня стоит пара таких рядом, и проблема возникает только на одном, даже после полного сброса к заводским настройкам и настройки только базовой конфигурации.

pe1chl Guest	#20 0 14.10.2021 13:26:00 Все эти устройства подключены к интернету одинаковым способом? То есть всегда используется обычное PPPoE-соединение с провайдером, который выдает реальный и статический внешний IP, без использования cg-nat? Спрашиваю потому, что поведение может сильно зависеть от NAT, который происходит вне роутеров MikroTik, или от изменения IP после перезапуска PPPoE-интерфейса. Это бы объясняло, почему одни пользователи сталкиваются с проблемой, а другие нет, или почему на одном роутере она проявляется, а на другом — нет.

Читают тему

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