ICMPv6 connection tracking - как оно в действительности работает?

Базовая функциональность RouterOS
ns88ns
Сообщения: 52
Зарегистрирован: 16 дек 2019, 13:40

Re: ICMPv6 connection tracking - как оно в действительности работает?

Сообщение ns88ns »

Тогда, возможно, так и есть... Например, опрос рутеров через мультикаст адрес выполняется по паре адресов (скажем) fd43::a1 -> ff02::2 (new), а ответ дает дает пару fd43::b1 -> fd43::a1 (untracked). Multicast Type 128, 129 - такое же поведение. Тут вопросов нет.

ICMPv6 type 135, 136 (neigbor discovery) в таблицу контреккера не попадают ни при каких обстоятельствах, даже если являются юникастными и матчатся по парам адресов. Unicast Type 128, 129 отслеживаются нормально.

В целом, я уже понял, что делаю неправильно. Задача, из-за которой вся эта байда всплыла, была такой: разрешить рутеру принимать входящие соединения и отвечать на них, но не разрешать инициировать исходящие соединения. Эта задача была поставлена для другого оборудования, но тестил я ее на микротике. Для statefull протоколов это делается просто: на вход разрешить new, established, на выход - только established. Для stateless протоколов это так не работает. С ICMP - ну, тоже, ладно, можно фильтовать по типам/кодам. А как с другими stateless протоколами?

Например (ну, пусть будет) протокол GREv6 или IPv6-TUN. Это стейтлесс протоколы. GREv6 трекается криво (все пакеты без connection state, в таблицу контреккера не попадает), IPv6-TUN трекается правильно (new+established). Ну и вот, когда туннельный интерфейс настроен - он тут же начинает слать пакеты второй стороне. Мне надо, чтоб от роутера был только ответ. Если на вход разрешить new+established и на выход только established - это не работает из-за неопределенных тайм-аутов для стейтлесс протоколов. После отправки последнего пакета внешней стороной туннеля - соединение какое-то время остается установленным (до истечения тайм-аутов) и тунельный интерфейс рутера может иницировать повтороне соединение к другой стороне - исходящие пакеты пройдут как established.

Ну не суть. К этому топику это не имеет никакого отношения. Там надо еще подумать над самой задачей. Смысл в том, что стал смотреть, как отслеживаются стейтфулл и стейтлесс протоколы. А поскольку, ICMP - самый доступный из всех, то тестировался на нем. Ну и возникли вопросы.

Надлежит сделать акцент, что цель была не уличить разработчика в кривости продукта, а разобраться как работает компонент в конкретной реализации.