ICMPv6 connection tracking - как оно в действительности работает?
-
- Сообщения: 560
- Зарегистрирован: 14 апр 2018, 15:21
- Откуда: СССР
Re: ICMPv6 connection tracking - как оно в действительности работает?
Полную поддержку ipv6 они обещают в ros7, до этого момента это просто фича, которая в режиме тестирования
По поводу 6to4 туннеля - это самый простой вариант, могу и через bgp подать, но тогда мне нужен номер AS чтоб стыконуться
У мнея всё равно /29 крутится, мне этого за глаза
По поводу 6to4 туннеля - это самый простой вариант, могу и через bgp подать, но тогда мне нужен номер AS чтоб стыконуться
У мнея всё равно /29 крутится, мне этого за глаза
Дома: CCR2004 (7-ISP(GPON)белый IP)
-
- Сообщения: 54
- Зарегистрирован: 16 дек 2019, 13:40
Re: ICMPv6 connection tracking - как оно в действительности работает?
А, наверно, и не факт. Оффициальная документация этому утверждению возражает. Я еще раз, нарочно, перечитал оффициальную документацию, и там ни слова о том, что IPv6 - в режиме тестирования. И я думаю - это правильно. Релизы - они же для релизов. Для тестов - есть тестовые сборки и бетки/альфы. Возможно, логически, каким-то образом, можно прийти к выводу о "тестовом" характере IPv6 в ROS6, но пока это не подтверждено официально - увы, домыслы и предположения остаются всего лишь домыслами и предположениями.до этого момента это просто фича, которая в режиме тестирования
Тут стоит сразу переходить к развязке, и я соглашусь, тут возможно такое возражение, что IPv6 connection state tracking вообще никак не фигурирует в оффициальной документации и его можно вообще обьявить undocumented feature. Глупость, конечно, но такая формулировка позволила бы избежать некрасивой ситуации. И если бы саппорт мне так и ответил бы - никаких вопросов бы не возникло. Но они начали варить воду на ровном месте, утверждая, что у них все работает.
-
- Сообщения: 560
- Зарегистрирован: 14 апр 2018, 15:21
- Откуда: СССР
Re: ICMPv6 connection tracking - как оно в действительности работает?
IPv6 до конца не сделано, они это признают, и честно говорят что весь функционал ipv6 будет реализован в ROS7, многие вещи тупо не работают или не сделаны, поэтому у меня и стоит отдельный nat64 для абонентов, иначе нормально не реализовать все плюшки. Плюс там где необходим чистый ipv6 для абонентов (у меня есть такие сегменты), мне пришлось джун ставить.
Дома: CCR2004 (7-ISP(GPON)белый IP)
-
- Сообщения: 54
- Зарегистрирован: 16 дек 2019, 13:40
Re: ICMPv6 connection tracking - как оно в действительности работает?
Да ну такое... Где "конец" - не понятно. Нет регламента. Если по форуму походить - там много интересных вопросов было. В частности о том надо ли в IPv6 NAT64/NAT66/NPT. Сколько-то лет назад, местная гуру-туса, любого, кто осмеливался говорить "надо" - чуть ли не анафеме предавали. Ну вы можете поискать - найдете. Там весьма спорные дискуссии поднимались. А сейчас и сами переобулись. Из тех (не буду называть), кто громче всех там буянил, что любой НАТ в IPv6 - это от лукавого, начали признавать, что надо. А что в финальный состав функциональности войдет - никому не известно. Спецификации нет. А если и появится - то нет гарантии, что ее в самый последний момент не сократят. Да и не факт, что ROS7 выйдет в релизе. Да, все ждут, но не факт. А случись чудо, и выйдет, то баги фиксить, все одно, до марковкина заговеня будут. Все равно, в bugless releases они не умеют.IPv6 до конца не сделано, они это признают, и честно говорят что весь функционал ipv6 будет реализован в ROS7
Впрочем, это уже оффтоп.
-
- Сообщения: 54
- Зарегистрирован: 16 дек 2019, 13:40
Re: ICMPv6 connection tracking - как оно в действительности работает?
Вот же черт... Что-то мне с этой проблемой не давало покоя и... Похоже, я сразу неправильный вопрос задал.
Слушай, а как доставляются пакеты на 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 адрес.
Может, я и напрасно крошек на сапорт накрошил...
Слушай, а как доставляются пакеты на 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 адрес.
Может, я и напрасно крошек на сапорт накрошил...
-
- Сообщения: 560
- Зарегистрирован: 14 апр 2018, 15:21
- Откуда: СССР
Re: ICMPv6 connection tracking - как оно в действительности работает?
В своё время я ловил трейс 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
Дома: CCR2004 (7-ISP(GPON)белый IP)
-
- Сообщения: 560
- Зарегистрирован: 14 апр 2018, 15:21
- Откуда: СССР
Re: ICMPv6 connection tracking - как оно в действительности работает?
Естественно дизаблить не надо, я просто скопировал
Дома: CCR2004 (7-ISP(GPON)белый IP)
-
- Сообщения: 560
- Зарегистрирован: 14 апр 2018, 15:21
- Откуда: СССР
Re: ICMPv6 connection tracking - как оно в действительности работает?
Есть ещё одна хрень, после обновления винды (десятки), вроде как 10 дней назад, у меня начали появлятся порты teredo в upnp, до этого не было.
Откуда пингуешь и смотришь (OS?)
Откуда пингуешь и смотришь (OS?)
Дома: CCR2004 (7-ISP(GPON)белый IP)
-
- Сообщения: 54
- Зарегистрирован: 16 дек 2019, 13:40
Re: ICMPv6 connection tracking - как оно в действительности работает?
С винды отправляю пакеты, дамп делаю на CHR и на винде. Тут есть еще нюанс - это все крутится под VMware Workstation и несовсем понятно, что там творит VMWare soft switch. По заявлениям ВМварного саппорта - их софт свитч никак не обрабатывает мультикаст трафик. Но, из того, что я вижу - он таки что-то делает.
UPnP у меня выключен.
В общем, я понял, надо еще и на untracked смотреть. Пометил себе проблему на детальное тестирование попозже. Сейчас другие задачи появились. Посмотреть в код и понять алго - было бы проще, но нет кода.
UPnP у меня выключен.
В общем, я понял, надо еще и на untracked смотреть. Пометил себе проблему на детальное тестирование попозже. Сейчас другие задачи появились. Посмотреть в код и понять алго - было бы проще, но нет кода.
-
- Сообщения: 3914
- Зарегистрирован: 29 фев 2016, 15:26
- Откуда: Минск
Re: ICMPv6 connection tracking - как оно в действительности работает?
Conntrack не должен обращать внимания на MAC-адреса, по идее. Он либо трекает по IP то, что ему прилетело, либо не трекает...
-
- Сообщения: 54
- Зарегистрирован: 16 дек 2019, 13:40
Re: ICMPv6 connection tracking - как оно в действительности работает?
Тогда, возможно, так и есть... Например, опрос рутеров через мультикаст адрес выполняется по паре адресов (скажем) 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 - самый доступный из всех, то тестировался на нем. Ну и возникли вопросы.
Надлежит сделать акцент, что цель была не уличить разработчика в кривости продукта, а разобраться как работает компонент в конкретной реализации.
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 - самый доступный из всех, то тестировался на нем. Ну и возникли вопросы.
Надлежит сделать акцент, что цель была не уличить разработчика в кривости продукта, а разобраться как работает компонент в конкретной реализации.