LINUX.ORG.RU
ФорумAdmin

IKEv2 и два WAN интерфейса Mikrotik

 , ,


0

2

Здравствуйте, подскажите пожалуйста по поводу корректной маршрутизации IPSec на Mikrotik или в целом.
Имеем:
- Офис (Mikrotik, 192.168.55.0/24)
- Два WAN интерфейса в Офисе (ISP1 - 78.11.33.69, ISP2 - 53.16.99.7)
- Удаленная машина ( Win Server)

На микротике в офисе подняты два канала с default route до них с разными метриками.
Никаких сложных failover конфигурации с netwatch скриптами или внешним мониторингом пока не накручены, просто тупо два маршрута по умолчанию с разными метриками.

Настроен mangle соединений, дабы пакеты уходили на тот-же ISP с которого пришли.

И все отлично работает, в рамках потребностей.

Но вдруг нам захотелось прикрутить удаленные серваки в домен и не просто прикрутить, а по модному IKEv2.
И все вроде бы хорошо, настроили - работает.
Но потом мне захотелось утилизировать резервный канал, а то что он «лежит» себе ничего не делает.
Решил я попробовать сделать так что-бы IKEv2 туннели поднимались через ISP2, и они поднялись.
И вроде даже работают какое-то время. Но потом тупо ложаться.
Но если поменять метрики и сделать основным каналом резервный, то все работает.
Причем со стороны микротика это очевидно peer берет и пропадает.
А вот на стороне Win server все выглядит как-будто соединение установленно. Вот только пакеты не проходят больше.
Пере подключаешься опять работает от силы минут пять и снова привет.

Притом через ISP2(резервный канал) спокойно работает смотрелка для камер и RDP и по большому счету все что смогли попробывать, а вот IPSec нет.

Вопрос куда копать? Если я все правильно понимаю в сторону роутинга, в том смысле что смотрелка для камер и RDP работают в рамках одной сессии соединений и они корректно обрабатываются в mangle и соответственно также корректно маршрутизируются.

Чуть повангую. У вас ipsec сервер поднят локально на Mikrotik, а «смотрелка для камер и RDP» это dnat на девайсы в локальной сети за микротиком?

anc ★★★★★
()
Ответ на: комментарий от anc

Именно так.

И почему то мне кажется что при таком моем ответе, я сейчас получу мощную затрещину ликбеза. Из-за незнания чего-то банального))

alter78rus
() автор топика
Ответ на: комментарий от alter78rus

Это не я сказал

this version has nothing stable even after updating ipv6 died! I >had to go back to version 6.44.5 for ipv6 to work again

Но хочу сразу предупредить что с откат на старые версии будут проблемы.

SergeySVold ★★★★★
()
Последнее исправление: SergeySVold (всего исправлений: 1)
Ответ на: комментарий от SergeySVold

По поводу проблем с откатом я в курсе, это не большая проблема для меня.

Но на версии 6.45.1 ситуация была аналогичная. Про 6.44.5 не скажу, так как на ней не пробовал.

Справедливости ради хочу заметить что ipv6 тут не причем, наличие ошибок в работе с ним не как не означает что вообще все не работает.
Правда это нам намекает что могли не допилить ни только ipv6, но и еще что-то. Возможно поторопились.

alter78rus
() автор топика
Ответ на: комментарий от alter78rus

Я не знаю микрота. Но предположил что вот это «Настроен mangle соединений, дабы пакеты уходили на тот-же ISP с которого пришли.» относиться только к forward (транзитным пакетам). Но не к input/output локальных процессов. Таким образом с учетом «два канала с default route до них с разными метриками.» ответ на пакет скорее всего улетает через defgw с меньшей метрикой. Проверить можете легко запустив тот же tcpdump (надеюсь в микрот его завезли).

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)

Собственно дифференциальный анализ показал следующее. При включении логов ipsec и наблюдением за ними было замечено следующее.

Когда используешь на Win Server тот же IP адрес для соеднинения с ipsec сервером что и является основным и на шлюз которого приходится defgetw. То как я писал до этого картина как в аптеке, все по полкам.

А вот когда используешь в качестве IP адрес резервного канала. То сначала все идет хорошо, логи один в один как при первом случаи. Соединение устанавливается пинги идут. Но через примерно три минуты, если ничего не пересылать по сети. А если например пинговать какой-нибудь узел в офисе, то не через три минуты, а через шесть. Происходить следующая штука сообщение в логах - «peer ports changed: 4500 -> 28362» Дальше минуту полторы логи как логи никаких отличий от контрольной группы. После как мы все уже догадывались до этого эта собака действительно начинает слать пакеты по defgw, а не туда откуда они пришли.

Тоесть в какой-то момента цепочка mangle обрывается, и микротик начинает слать пакеты ipsec в defgw.

С одной стороны все хорошо, проблема стала более понятна. Но осталось по прежнему не понятно что делать))

И почему обрывается маркировка пакетов, собственно как и почему она этого не делает сразу, а работает какое-то время. Есть идеи?

alter78rus
() автор топика
Ответ на: комментарий от alter78rus

Но осталось по прежнему не понятно что делать))

Микротику вопрос задай.

SergeySVold ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.