Здравствуйте, подскажите пожалуйста по поводу корректной маршрутизации 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 и соответственно также корректно маршрутизируются.
Собственно и не свечу, вписал что в голову пришло. Увидел ваше сообщение решил пробить тот что 53 зарегистрирован на Daimler AG(Германия), а второй на Польское отделение Mondelez Europe Services GMBH. Одно печеньки другое тачки им не суждено быть в одном ipsec-e))
В ходе экспериментов всплыла странность в виде того что тунель рвется только от клиентов которые не за NAT-ом.
Собственно странность в том что обычно проблемы с теми кто как раз таки за NAT-ом.
Поделюсь личным опытом:
Был случай два микротика в разных офисах у каждого белый ип, между ними l2tp туннель (тип туннеля не важен)
Туннель тоже вот так отпадал.
сеть 1го микротика 192.168.0.0/24
сеть 2го микротика 192.168.99.0/24
адреса внутри туннеля миркотик1 10.10.10.1 <---> 10.10.10.2 микротик2
и прописаны роуты все работало но иногда падало.
Как оказалось с wan интерфейса микротик2 (на котором был белый ип) арпингом было видно ип 10.10.10.1 (он кемто использовался в сети провайдера) если этот адрес попадал в арп таблицу микротик2 с интерфейсом wan то все ломалось тк как пакеты шли не в туннель а в wan интерфейс. Проблему решил сменой ип адресов внутри туннеля.
Решил проверить вашу историю применительно к моей ситуации, и о боже мой делаю arpping ip адреса из того пула адресов что я выделил для IKEv2 клиентов.
И что я вижу какой-бы адрес из 172.16.16.0/25 я не пробывал пинговать все отвечали. Вся подсеть.
Мои глаза начали сужаться, решил арппингануть другие подсети из "гражданского" сегмента так сказать, например 10.44.9.230 результат то-же.
И тут моих знаний перестало хватать для обьяснения, а что собственно происходит.
Потому как отвечал мне всегда один и тот-же MAC адрес.
Есть предположения как-так?
Но касательно проблемы, если делать все тоже самое но на интерфейсе другого провайдера картина совсем другая там мне никто не отвечает.
Да и описанная мною проблема актуально даже если поменять местами провайдеров.
В смысли если сделать резервный канал основным, но производить соединение с IPSec сервером по адресу основного. Тоесть обратить все зеркально, то проблема остается. Хотя арппинг для второго провайдера не работает на те адреса что я выделил.
Michael, ситуация похожа на то, что у вас трафик не заворачивается в туннель, а идёт на шлюз провайдера, который ловит весь трафик из частного диапазона и отвечает на пинги.
Дмитрий Шицков, Если я все правильно понимаю, то трафик то заворачивается в тунель. Так как в те недолгие минуты пока тунель еще не отвалился я могу пинговать Win server что является клиентом и это точно он(RDP работает).
Но да мне почему-то кажется что проблема именно в провайдере, правда я тогда не понимаю почему ситуация сохраняется если отзеркалить настройки и сделать основной резервным, а резервный основным. И соединятся уже с тем что резервный.
Дмитрий Шицков, И исходя из этой логике я не понимаю почему в случаи если вина всему что провайдер отвечает на запросы из частных сетей, то все замечательно работает если соединятся с тем провайдером что сейчас основной.
Michael, провайдер здесь не виноват ни в чем. Нужно больше диагностическая инфы, конфиги ipsec и роутов, verbose логи ipsec - искать там причины падения
Собственно дифференциальный анализ показал следующее. При включении логов ipsec и наблюдением за ними было замечено следующее.
Когда используешь на Win Server тот же IP адрес для соеднинения с ipsec сервером что и является основным и на шлюз которого приходится defgetw. То как я писал до этого картина как в аптеке, все по полкам.
А вот когда используешь в качестве IP адрес резервного канала. То сначала все идет хорошо, логи один в один как при первом случаи. Соединение устанавливается пинги идут.
Но через примерно три минуты, если ничего не пересылать по сети. А если например пинговать какой-нибудь узел в офисе, то не через три минуты, а через шесть. Происходить следующая штука сообщение в логах - "peer ports changed: 4500 -> 28362"
Дальше минуту полторы логи как логи никаких отличий от контрольной группы.
После как мы все уже догадывались до этого эта собака действительно начинает слать пакеты по defgw, а не туда откуда они пришли.
Тоесть в какой-то момента цепочка mangle обрывается, и микротик начинает слать пакеты ipsec в defgw.
С одной стороны все хорошо, проблема стала более понятна.
Но осталось по прежнему не понятно что делать)) Есть идеи?
Есть мысли, что это может быть завязано с proxy arp. При этом не только на вашей стороне но и на стороне хостера. Смотрите трасером , куда оно уползает.
Так же смотрите , что у вас с ipsec на тиках
/system logging add topics=ipsec,!packet
Вообще ike2, да же в текущим варианте сырой.
Пока по старинке все на l2tp.
