Проблема NFTABLE: IPv6 не ведет себя как IPv4 с зеркальной конфигурацией

Проблема NFTABLE: IPv6 не ведет себя как IPv4 с зеркальной конфигурацией

У меня проблема с IPv6 на моем сервере. Я настроил nginx на прослушивание порта 443 с IPv4 и IPv6. И это прекрасно работает: мой веб-сайт доступен из Интернета с включенным TLS.

Все усложняется, когда я активирую nftables:когда я захожу на свой сайт по IPv4, он работает, но когда я захожу по IPv6, соединение прерывается :(

Вывод sudo nft list ruleset:

table inet filter {
        chain INPUT {
                type filter hook input priority filter; policy drop;
                meta nftrace set 1
                ct state established,related accept comment "allow established connections"
                iif "lo" accept comment "allow all from localhost"
                iif != "lo" ip daddr 127.0.0.0/8 counter packets 0 bytes 0 drop comment "drop connections to loopback not coming from loopback"
                iif != "lo" ip6 daddr ::1 counter packets 0 bytes 0 drop comment "drop connections to loopback not coming from loopback"
                iifname "tunnel0" accept comment "allow all from VPN"
                udp dport 12345 accept comment "allow VPN on port 12345"
                tcp dport { 22, 80, 443 } accept comment "allow HTTP, HTTPS and SSH on classic ports"
        }

        chain OUTPUT {
                type filter hook output priority filter; policy accept;
        }

        chain FORWARD {
                type filter hook forward priority filter; policy drop;
        }
}

Вывод sudo nft monitor trace | grep 443:

trace id 76d7cb1a inet filter INPUT packet: iif "eth0" ether saddr AA:AA:AA:AA:AA:AA ether daddr BB:BB:BB:BB:BB:BB ip6 saddr 2a01:cb09:804b:cd61:CCCC:CCCC:CCCC:CCCC ip6 daddr 2001:CCCC:CCCC:CCCC::CCCC ip6 dscp cs0 ip6 ecn not-ect ip6 hoplimit 45 ip6 flowlabel 0 ip6 nexthdr tcp ip6 length 40 tcp sport 53184 tcp dport 443 tcp flags == syn tcp window 22240

Обратите внимание, что у меня нет этой проблемы с ssh на порту 22. Я работаю nftables v0.9.8 (E.D.S.)на Debian 11.

Я почти целый день потратил на поиск решения. Любая помощь приветствуется! Спасибо

решение1

ICMPv6, который является протоколом поверх IPv6, реализует разрешение на уровне канала с использованием многоадресной и одноадресной передачи. Отказ от ICMPv6 означает, что больше нет доступного разрешения: узлы не могут найти другие узлы в той же локальной сети. Это включает в себя маршрутизатор IPv6 восходящего потока, который не может взаимодействовать с системой Linux с помощью IPv6, если ICMPv6 отключен.

В отличие от этого IPv4 полагается на другой протокол: ARP (использующий широковещательную и одноадресную рассылку), который не является протоколом IPv4. Таким образом, можно отказаться от всего ICMP и не страдать от проблем с подключением к локальной сети, поскольку ARP не затронут (но все еще можно страдать отЧерная дыра ПМТУи другие подобные проблемы при отключении всех ICMP, особенно при использовании туннелей).

Итак, начните с включения всех протоколов ICMPv6, а затем, во второй раз, как только вы убедитесь, что IPv6 снова работает, если вы не хотите включать все, проверьте, что следует выборочно принимать вПротокол обнаружения соседей(для немаршрутизирующего узла я бы сказал, как минимум, типы 134, 135, 136 и 137):

nft add rule inet filter INPUT 'icmpv6 type { 134, 135, 136, 137 } accept'

решение2

Мне это помогло:

table inet filter {
    chain INPUT {
        type filter hook input priority 0; policy drop;

        meta l4proto ipv6-icmp accept
        ip6 ecn not-ect accept

        # Although I used the slightly more restrictive:
        # ip6 ecn not-ect ip6 hoplimit 1 accept
    }
}

Обратите внимание, что пакет, который вы перехватили, является пакетом ECN, как и мой (за исключением того, что у меня ip6 hoplimit 1 от link-local fe80::/10 saddr, а у вас ip6 hoplimit 45). Похоже, этот пакет должен быть принят, чтобы мой провайдер (Spectrum Broadband) назначил мне блок IPv6, и, возможно, у вас возникли похожие трудности с этими пакетами ECN.

Связанный контент