Недавно я развернул 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-соединений. Но мне интересно, почему это вообще происходит.
/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-соединений. Но мне интересно, почему это вообще происходит.
