В ходе экспериментов всплыла странность в виде того что тунель рвется только от клиентов которые не за NAT-ом.
Собственно странность в том что обычно проблемы с теми кто как раз таки за NAT-ом.
Собственно и не свечу, вписал что в голову пришло. Увидел ваше сообщение решил пробить тот что 53 зарегистрирован на Daimler AG(Германия), а второй на Польское отделение Mondelez Europe Services GMBH. Одно печеньки другое тачки им не суждено быть в одном ipsec-e))
Собственно дифференциальный анализ показал следующее. При включении логов ipsec и наблюдением за ними было замечено следующее.
Когда используешь на Win Server тот же IP адрес для соеднинения с ipsec сервером что и является основным и на шлюз которого приходится defgetw. То как я писал до этого картина как в аптеке, все по полкам.
А вот когда используешь в качестве IP адрес резервного канала. То сначала все идет хорошо, логи один в один как при первом случаи. Соединение устанавливается пинги идут.
Но через примерно три минуты, если ничего не пересылать по сети. А если например пинговать какой-нибудь узел в офисе, то не через три минуты, а через шесть. Происходить следующая штука сообщение в логах - "peer ports changed: 4500 -> 28362"
Дальше минуту полторы логи как логи никаких отличий от контрольной группы.
После как мы все уже догадывались до этого эта собака действительно начинает слать пакеты по defgw, а не туда откуда они пришли.
Тоесть в какой-то момента цепочка mangle обрывается, и микротик начинает слать пакеты ipsec в defgw.
С одной стороны все хорошо, проблема стала более понятна.
Но осталось по прежнему не понятно что делать)) Есть идеи?
Дмитрий Шицков, И исходя из этой логике я не понимаю почему в случаи если вина всему что провайдер отвечает на запросы из частных сетей, то все замечательно работает если соединятся с тем провайдером что сейчас основной.
Дмитрий Шицков, Если я все правильно понимаю, то трафик то заворачивается в тунель. Так как в те недолгие минуты пока тунель еще не отвалился я могу пинговать Win server что является клиентом и это точно он(RDP работает).
Но да мне почему-то кажется что проблема именно в провайдере, правда я тогда не понимаю почему ситуация сохраняется если отзеркалить настройки и сделать основной резервным, а резервный основным. И соединятся уже с тем что резервный.
Решил проверить вашу историю применительно к моей ситуации, и о боже мой делаю arpping ip адреса из того пула адресов что я выделил для IKEv2 клиентов.
И что я вижу какой-бы адрес из 172.16.16.0/25 я не пробывал пинговать все отвечали. Вся подсеть.
Мои глаза начали сужаться, решил арппингануть другие подсети из "гражданского" сегмента так сказать, например 10.44.9.230 результат то-же.
И тут моих знаний перестало хватать для обьяснения, а что собственно происходит.
Потому как отвечал мне всегда один и тот-же MAC адрес.
Есть предположения как-так?
Но касательно проблемы, если делать все тоже самое но на интерфейсе другого провайдера картина совсем другая там мне никто не отвечает.
Да и описанная мною проблема актуально даже если поменять местами провайдеров.
В смысли если сделать резервный канал основным, но производить соединение с IPSec сервером по адресу основного. Тоесть обратить все зеркально, то проблема остается. Хотя арппинг для второго провайдера не работает на те адреса что я выделил.
И у нас есть победитель)) Спасибо огромное мил человек. Как это обычно и бывает, только напишешь что что-то не получается. Как тут-же находишь в чем беда. Да действительно буквально часа два назад таки заметил правило в FORWARD мешавшее корректной работе. Но все равно спасибо, еслиб не сам то с вашей подачи точно бы пересмотрел еще раз правила.
Спасибо огромное, реализация на "Питоне" как раз то что нужно. Это не решение(пока не проверил досконально), но идеальный пример. В купе с документацией, её я тоже что-то не нашел. Еще раз спасибо, сейчас погоняем.
Не та область знаний что-бы говорить о нереальном. Это драйвера, не более того. Я почему собственно так уверен в нереальности. Недавно(полгода назад) 1С выпустила тонкий и толстый клиент под Linux. Мне кажется нашлись пытливые умы которые таки написали или раздобыли драйвера. Но спасибо за мнение, это мой первый вопрос.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Собственно странность в том что обычно проблемы с теми кто как раз таки за NAT-ом.