http://mikrotik.moscow Новое в теме Странности с отслеживанием соединений IPv6 форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Wed, 12 Aug 2026 16:09:02 -0400 Странности с отслеживанием соединений IPv6 RouterOS в форуме RouterOS.
Я проверил в WinBox и через SSH, чтобы найти это правило no-track в IPv6 фаерволе, о котором вы говорите. Однако, такого правила, похоже, нет. Может, я что-то упускаю?
22.05.2018 13:13:00, WarMaster.]]> http://mikrotik.moscow/forum/forum57/84657-strannosti-s-otslezhivaniem-soedineniy-ipv6/message388827 http://mikrotik.moscow/forum/forum57/84657-strannosti-s-otslezhivaniem-soedineniy-ipv6/message388827 Tue, 22 May 2018 13:13:00 -0400 RouterOS Странности с отслеживанием соединений IPv6 RouterOS в форуме RouterOS.
Если заглянуть в исходную таблицу, то там есть правила, которые по умолчанию отключают отслеживание соединений для IPv6. У меня не существует упомянутого набора соединений /ipv6 firewall connection set enabled=, но если добавить правила с более высоким приоритетом, которые разрешают трафик до того, как сработает действие «no track», то отслеживание соединений будет работать как надо.
22.05.2018 10:55:00, jkroon.]]> http://mikrotik.moscow/forum/forum57/84657-strannosti-s-otslezhivaniem-soedineniy-ipv6/message388826 http://mikrotik.moscow/forum/forum57/84657-strannosti-s-otslezhivaniem-soedineniy-ipv6/message388826 Tue, 22 May 2018 10:55:00 -0400 RouterOS Странности с отслеживанием соединений IPv6 RouterOS в форуме RouterOS.
Наверное, мы не одни такие, у кого эти проблемы...?
25.11.2017 17:49:00, WarMaster.]]> http://mikrotik.moscow/forum/forum57/84657-strannosti-s-otslezhivaniem-soedineniy-ipv6/message388825 http://mikrotik.moscow/forum/forum57/84657-strannosti-s-otslezhivaniem-soedineniy-ipv6/message388825 Sat, 25 Nov 2017 17:49:00 -0500 RouterOS Странности с отслеживанием соединений IPv6 RouterOS в форуме RouterOS.
Я гуглил «Mikrotik IPv6 не отслеживается правильно» и наткнулся на этот пост. Поведение моего IPv6-файрвола похоже на то, что описывает автор оригинального поста, хотя сами правила отличаются. Суть в том, что, похоже, что-то не так с отслеживанием IPv6-соединений, или существует куча серверов (а может, и маршрутизаторов?), у которых реализовано это криво.
28.10.2017 12:18:00, WarMaster.]]> http://mikrotik.moscow/forum/forum57/84657-strannosti-s-otslezhivaniem-soedineniy-ipv6/message388824 http://mikrotik.moscow/forum/forum57/84657-strannosti-s-otslezhivaniem-soedineniy-ipv6/message388824 Sat, 28 Oct 2017 12:18:00 -0400 RouterOS Странности с отслеживанием соединений IPv6 RouterOS в форуме RouterOS.
Это меня тоже озадачивает, и всё, что я узнал, — отключение IPv6 на проблемных сайтах решает проблему. Я не эксперт по IPv6, но добавил пару правил в цепочку forward, которые принимают related и established соединения, однако это не работает. Похоже, что отслеживание соединений, которое отлично работает в IPv4, в IPv6 либо не работает, либо не реализовано. В итоге приходится, как я и говорил, отключать IPv6 на некоторых сайтах, в основном на Google и Facebook, потому что они отправляют пакеты RST и ACK, которые не подтверждаются. Не знаю, есть ли стандарт для отслеживания соединений в IPv6, но если есть, то Mikrotik его полностью игнорирует (как и с DHCPv6). Ещё одна возможная причина — Google и Facebook действительно отправляют пакеты с отсутствующими флагами, из-за чего они считаются недействительными. Очень хотелось бы получить больше информации по этому поводу, особенно о стандартах, но похоже, сейчас на этот счёт почти нет никакой реакции.
05.10.2017 18:49:00, bobob.]]> http://mikrotik.moscow/forum/forum57/84657-strannosti-s-otslezhivaniem-soedineniy-ipv6/message388823 http://mikrotik.moscow/forum/forum57/84657-strannosti-s-otslezhivaniem-soedineniy-ipv6/message388823 Thu, 05 Oct 2017 18:49:00 -0400 RouterOS Странности с отслеживанием соединений IPv6 RouterOS в форуме RouterOS.
Недавно я развернул IPv6 в сети и заметил, что несколько устройств в LAN не имели нормально настроенного фаервола, и сервисы были доступны из интернета. Попытался исправить это, добавив фильтр, который сбрасывает все новые входящие соединения, кроме ICMPv6, по следующему правилу:  
/ipv6 firewall filter add action=drop chain=forward connection-state=new dst-address-list=!exempt-firewall in-interface=ether1 log=yes out-interface=ether2-master protocol=!icmpv6  

Это правило действительно блокирует входящие подключения, но при этом я вижу, что обычный трафик тоже иногда сбрасывается:  
mar/07 14:01:52 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK), [2607:f8b0:401c:18::a]:443->[my_prefix:c5de:f2fe:dbee:784b]:56565, len 1240
mar/07 14:02:20 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK), [2607:f8b0:401c:18::a]:443->[my_prefix:c5de:f2fe:dbee:784b]:56565, len 1240
mar/07 14:28:08 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK), [2607:f8b0:4007:17::8]:443->[my_prefix:c5de:f2fe:dbee:784b]:57550, len 1240
...  

IP-адреса источников — Google и Facebook, и, судя по всему, это части легитимных соединений (с флагами ACK и PSH). Я понимаю, что conntrack может закрыть запись трека соединения, когда видит, например, FIN, и тогда в логах обычно появляются ложные FIN,ACK пакеты. Но в моём случае я нигде не вижу логов с FIN, и некоторые пакеты явно содержат полезные данные (len 1240 / len 657), поэтому боюсь, что это реально ломает IPv6 трафик для клиентов.  

Думаю перейти на два отдельных правила: одно для блокировки SYN, другое — для блокировки новых UDP-соединений. Но мне интересно, почему это вообще происходит.
08.03.2017 00:49:00, R1CH.]]> http://mikrotik.moscow/forum/forum57/84657-strannosti-s-otslezhivaniem-soedineniy-ipv6/message388822 http://mikrotik.moscow/forum/forum57/84657-strannosti-s-otslezhivaniem-soedineniy-ipv6/message388822 Wed, 08 Mar 2017 00:49:00 -0500 RouterOS