add eth0 type dummy
# ip addr add 2a0d:8480:3:31f::1:0/128 dev eth0
# ip route add 2a0d:8480:3:31f::1:0/112 dev eth0
nftables inet input:
ct state invalid drop
ct state {related, established} accept
ip protocol icmp accept
ip6 nexthdr ipv6-icmp accept
nftables inet forward:
iifname eth0 oifname ens3 accept
iifname ens3 oifname eth0 accept
nftables inet output:
icmpv6 type nd-neighbor-advert counter
Пингуем адрес на физическом интерфейсе - радуемся, всё хорошо
Пингуем с самого себя адрес на виртуальном интерфейсе - радуемся, всё хорошо
Пингуем извне адрес на виртуальном интерфейсе - приходит neighbor solicitation, advert не уходит, НО!:
# nft list ruleset | grep counter
И видим, как количество пакетов растёт с количеством прибывающих nd-neighbor-solicitation
Вопрос, что не так?
Нашёл про то, что надо ставить ndp proxy, нашёл реализацию - ndppd, соответственно вопрос: надо ли это? Если да, надо ли включать net.ipv6.conf.ens3.proxy_ndp=1?
И ещё, нашёл, якобы на каждый ip надо писать ip -6 neigh add proxy $IPV6 dev ens3
В общем, надо ли заморачиваться с проксированием ndp и до какой степени?
Я проверил в любом случае, ndppd получает пакеты, понимает, что надо проксировать, судя по логам, даже успешно, и отсылает пакет (лог о том, что nd-advert отправлен совпадает с увеличением количества пакетов в nft), но tcpdump не видит эти пакеты
Как назначить ip на виртуальный интерфейс и сделать его доступным извне?
А фаера у тебя нет?
output весь разрешён, если вы про это
А инпут? У вас же входящее правило на то чтоб пускало к клиентам
В сообщении указано: ct state invalid drop ct state {related, established} accept ip protocol icmp accept ip6 nexthdr ipv6-icmp accept
Dummy условно локальный интерфейс, не делай пока так, вешай на lo. Читай мое сообщение про nd демона
Обсуждают сегодня