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

[Sir_Prikol]

Полную поддержку ipv6 они обещают в ros7, до этого момента это просто фича, которая в режиме тестирования

По поводу 6to4 туннеля - это самый простой вариант, могу и через bgp подать, но тогда мне нужен номер AS чтоб стыконуться

У мнея всё равно /29 крутится, мне этого за глаза

[ns88ns]

до этого момента это просто фича, которая в режиме тестирования

А, наверно, и не факт. Оффициальная документация этому утверждению возражает. Я еще раз, нарочно, перечитал оффициальную документацию, и там ни слова о том, что IPv6 - в режиме тестирования. И я думаю - это правильно. Релизы - они же для релизов. Для тестов - есть тестовые сборки и бетки/альфы. Возможно, логически, каким-то образом, можно прийти к выводу о "тестовом" характере IPv6 в ROS6, но пока это не подтверждено официально - увы, домыслы и предположения остаются всего лишь домыслами и предположениями.

Тут стоит сразу переходить к развязке, и я соглашусь, тут возможно такое возражение, что IPv6 connection state tracking вообще никак не фигурирует в оффициальной документации и его можно вообще обьявить undocumented feature. Глупость, конечно, но такая формулировка позволила бы избежать некрасивой ситуации. И если бы саппорт мне так и ответил бы - никаких вопросов бы не возникло. Но они начали варить воду на ровном месте, утверждая, что у них все работает.

[Sir_Prikol]

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

[ns88ns]

IPv6 до конца не сделано, они это признают, и честно говорят что весь функционал ipv6 будет реализован в ROS7

Да ну такое... Где "конец" - не понятно. Нет регламента. Если по форуму походить - там много интересных вопросов было. В частности о том надо ли в IPv6 NAT64/NAT66/NPT. Сколько-то лет назад, местная гуру-туса, любого, кто осмеливался говорить "надо" - чуть ли не анафеме предавали. Ну вы можете поискать - найдете. Там весьма спорные дискуссии поднимались. А сейчас и сами переобулись. Из тех (не буду называть), кто громче всех там буянил, что любой НАТ в IPv6 - это от лукавого, начали признавать, что надо. А что в финальный состав функциональности войдет - никому не известно. Спецификации нет. А если и появится - то нет гарантии, что ее в самый последний момент не сократят. Да и не факт, что ROS7 выйдет в релизе. Да, все ждут, но не факт. А случись чудо, и выйдет, то баги фиксить, все одно, до марковкина заговеня будут. Все равно, в bugless releases они не умеют.

Впрочем, это уже оффтоп.

[ns88ns]

Вот же черт... Что-то мне с этой проблемой не давало покоя и... Похоже, я сразу неправильный вопрос задал.

Слушай, а как доставляются пакеты на multicast MAC'и? Например, отправил кто-то ICMPv6 пакет type 135 на ff02::1. Этому адресу соответствует MAC 33-33-00-00-00-01. И доставляется такой пакет на микротик. Что будет у этого пакета в destination mac ? Если такой трафик идет через умный свитч, то он, если отслеживает мультикастные группы, может сделать биндинг multicast MAC на unicast MAC (т.е. 33-33-00-00-00-01 -> 00-0c-32-22-34-a2 [например]), по этому биндингу заменить desctination mac на юникастный и пакет будет доставлен как ... юникастный, что-ли? А если такой пакет идет через глупый свитч, который не умеет в мультикаст-группы?

У меня сегодня эта мысль возникла... Стал я дампить. По ICMPv6 в untracked высыпаются всякие type 130..136 которые заходят по multicast IPv6 адресам, а тут возможен такой сценарий, когда не получится однозначно отследить состояние соединения. Да, вобщем-то, там даже может и не быть никакого соединения. Пакеты, доставленные через multicast IPv6 адреса в таблицу контреккера не попадают. А в дампах нет никаких пакетов с мультикастными мак'ами, хотя трафик доставлен через мультикаст IPv6 адрес.

Может, я и напрасно крошек на сапорт накрошил...

[Sir_Prikol]

В своё время я ловил трейс ipv6 (чтоб отследить рутер) следующими правилами

Код: Выделить всё

/ipv6 fi fi
add action=accept chain=input comment="traceroute \ED\E0 \EC\E8\EA\F0\EE\F2\E8\EA" disabled=yes dst-port=33434-33464 in-interface-list=IPv6 protocol=udp
add action=accept chain=forward comment="traceroute \E2 \EB\EE\EA\E0\EB\EA\F3" disabled=yes dst-port=33434-33464 in-interface-list=IPv6 protocol=udp

[Sir_Prikol]

Естественно дизаблить не надо, я просто скопировал

[Sir_Prikol]

Есть ещё одна хрень, после обновления винды (десятки), вроде как 10 дней назад, у меня начали появлятся порты teredo в upnp, до этого не было.

Откуда пингуешь и смотришь (OS?)

[ns88ns]

С винды отправляю пакеты, дамп делаю на CHR и на винде. Тут есть еще нюанс - это все крутится под VMware Workstation и несовсем понятно, что там творит VMWare soft switch. По заявлениям ВМварного саппорта - их софт свитч никак не обрабатывает мультикаст трафик. Но, из того, что я вижу - он таки что-то делает.

UPnP у меня выключен.

В общем, я понял, надо еще и на untracked смотреть. Пометил себе проблему на детальное тестирование попозже. Сейчас другие задачи появились. Посмотреть в код и понять алго - было бы проще, но нет кода.

[Chupaka]

Conntrack не должен обращать внимания на MAC-адреса, по идее. Он либо трекает по IP то, что ему прилетело, либо не трекает...

[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 - самый доступный из всех, то тестировался на нем. Ну и возникли вопросы.

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