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

[ns88ns]

Приветствую.

Наткнулся на странную работу трекера соединений в ROS. Ну, в последней стабильной ROS6 воспроизводится.

Собственно, кейс:

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

/ipv6 firewall filter
add chain=input protocol=icmpv6 connection-state=new action=accept log=no
add chain=input connection-state=established action=accept log=no
add chain=input connection-state=related action=accept log=no
add chain=input action=drop log=yes

В chain=output никаких правил нет.

Ну и начинаем сыпать ICMPv6 (types 128, 135,136) c одного стороннего источника (неизменный SRC) в ROS с адресами назначения - юникастный IPv6 роутера и мультикастные FF02::

Если я все правильно знаю - то весь трафик должен провалиться в первые два правила. Ну потому что SRC и DST не меняются. Но по факту, много трафика проваливается в правило 3 и 4 (совсем сорприз).

Как такое может происходить? Это я не понимаю каких-то фундаментальных основ или это ROS прикалывается?

С уважением.

[Chupaka]

Здравствуйте.

А там точно только icmpv6? Я вижу log=no и отсутствие protocol=icmpv6 в остальных правилах, поэтому берут некоторые сомнения

Ну и добавьте для теста connection-state=invalid, что ли... Вдруг сюда что-нибудь уйдёт

[ns88ns]

В этом тесте я там умышленно в правилах 2 и 3 не указал протокол, потому что другого трафика просто нет, да и без указания протокола в правилах 2 и 3 - весь ICMPv6 должен проваливаться в них по connection-state. ICMPv6 - он же stateless протокол и никакого специального хелпера в ROS для этого протокола нет, значит пакеты могут быть либо NEW, либо ESTABLISHED. По логике, там даже RELATED появится не может.

connection-state=invalid ничего не ловит.

Вот такую штуку увидел:

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

/ipv6 firewall filter
add chain=input connection-state=established action=accept log=yes
add chain=input connection-state=related action=accept log=yes
add chain=input protocol=icmpv6 action=accept log=yes
add chain=input action=drop log=yes

через такие правила, работает как ожидается - первый пакет проходит через правило 3, а остальные через правило 1. Правила 2 и 4 ничего не регистрируют. Т.е. connection-state определяется правильно.

Но если в правило 3 добавить connection-state=new - начинается ерунда: часть пакетов лезет через правило 1, част начинает лезть в правило 2, и часть - дропается правилом 4.

Как по мне - такого не бывает. Это похоже на какой-то глюк. Не может connection-state=new ломать все connection-states. И даже, не должен, скорей всего.

Я отписал в саппорт, но они - парни, традиционно, очень не торопливые. У меня там есть пара реквестов, которые уже 4-й месяц загорают без ответа.

[Chupaka]

Да, совершенно загадочно. Видимо, поэтому IPv6 ещё им пилить и пилить...

[ns88ns]

Таки мы разговаривали долго. Увы, поддержка продемонстрировала абсолютное отсутствие какого-либо интереса к проблеме. Там репрокейс был на 5 минут, но они вместо чтоб потратить 5 минут на воспроизвести проблему и отправить ее на фикс - три недели морочили мне мозги своими идеями и предположениями. Ни одно из них не сработало. Ну и понятно - цели не было у них фиксить. Цель была задолбать. В результате я плюнул и забил. А сам я себе так думаю: раз оно даже разработчику не надо - то мне-то че парится?

Хотя, я даже и растерялся от такого подхода. Когда я им сказал, что кейс можно закрыть ка нерешенный - за пять минут его уже не было в системе. На закрыть кейс - да, это они очень быстро среагировали.

Полагаю, нормального IPv6 тут не будет. Хотя, возможно, у них и цели-то нет развиваться. Пилят себе для интреса и пилят. Никому ничего не должны, денег на борщ хватает. 7-ка, вот уж который год в бете без сдвига. Знал бы заранее - внимательней смотрел бы по сторонам.

Ну, ок.

[ns88ns]

Ну и да - по сути вопроса же:

В ходе тестов выяснилось, что после NEW, следующее состояние для ICMPv6 в ROS - это UNTRACKED. Именно на untracked все последующие после NEW пакеты и ловятся. Такое же точно поведение демонстрируют многие другие staless IPv6 протоколы. В соответствии с документацией, состояние соединения не отслеживается только если есть правило с NO-TRACK.Но, в данном случае, NO-TRACK отсутствует и UNTRACKED невозможны в принципе. И поскольку в документации это поведение никаким образом не отражено - это, определено, баг. Но, донести эту мысль не удалось.

[Chupaka]

Эх, когда-нибудь будет и у меня IPv6 дома, и я смогу это всё проверять и писать в поддержку...

Спасибо за информацию!

[ns88ns]

а белый IPv4 есть?

Давно было... Я когда за двойным натом сидел, а IPv6 был надо - я через PPTP (PPTP/GRE через оба ната проходил) ходил на внешний линуксячий сервак, поднятый у хостера, который давал белые IPv4, там ловил IPv6 туннель от HE и через PPTP прокидывал IPv6 домой.

[Sir_Prikol]

Могу дать нативный ipv6 через 6to4 туннель, нахаляву

По теме, у меня проблем с ipv6 не наблюдается, юзаю его на микротике уже 5 лет. Бесит немного другое, пока с ipv6 невозможно сделать routing mark, и, соответственно, получить балансировку, но, посредством BGP они уже её реализовали, хоть и немного кривовато

Ну и бесит, что до сих пор не реализовано pppoe-pd. Вот именно это и мешает мне нормально внедрить ipv6 своим абонентам

[ns88ns]

Могу дать нативный ipv6 через 6to4 туннель, нахаляву

Так а смысл? HE делает ровно то же самое. Через 6to4 и на халву.

Ну, собственно, да, в самом базовом виде - IPv6 у них реализован и таки работает. Если не заморачиваться со всякими штуками вроде connection-state-based management, BPR (да, собственно, и все) - то, вполне себе даже. В описанном случае, если убрать connection-state-based management - то все гуд. Но, мне надо. К ним вообще б не было бы вопросов, если бы они эти нюансы описали в документации. Отсутствие PBR у них таки задекларировано. А вот кривой connection state traсking - нет.

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

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