С данного компьютера с интерфейсом enp3s0 на 192.168.2.0/24 и 2001:44b8:4112:8a02::/64, если я сделаю следующее:

canidae# ip link add dummy0 type dummy
canidae# ip addr add dev dummy0 2001:44b8:4112:8a02::55 
canidae# ip addr add dev dummy0 192.168.2.55
canidae# ip link set dummy0 up

Следующий вывод ip addr подтверждает, что оба IP-адреса являются глобальными:

46: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 02:d1:a1:a4:7d:a6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.55/32 scope global dummy0
       valid_lft forever preferred_lft forever
    inet6 2001:44b8:4112:8a02::55/128 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::d1:a1ff:fea4:7da6/64 scope link 
       valid_lft forever preferred_lft forever

Теперь с другого компьютера в сети я могу пропинговать 192.168.2.55. Это не имеет значения, что пакеты приходят на enp3s0, а не на dummy0 потому что IP-адрес является глобальным.

Но я не могу пропинговать 2001:44b8:4112:8a02::55 с удаленного хоста. Хост отправляет запросы NDP, чтобы найти 2001:44b8:4112:8a02::55, но не получает ответа. Таким образом, кажется, что адреса на самом деле не глобальные, а специфичные для интерфейса.

Если я вручную добавлю тот же адрес IPv6 в enp3s0. Это работает. На самом деле он продолжает работать некоторое время, если я удалю назначение IPv6-адреса из enp3s0, предположительно потому, что результат NDP был кэширован. Компьютер знает, как обращаться с пакетами для адреса, если он их получает, но просто любит держать это в секрете.

Насколько я понимаю, это должно работать для IPv6 так же, как и для IPv4, но это не так.

На этом компьютере нет iptables или ip6tables, которые могут что-то блокировать.

Этот компьютер:

canidae# uname -a
Linux canidae 5.9.0-3-amd64 #1 SMP Debian 5.9.9-1 (2020-11-19) x86_64
GNU/Linux

Но я видел подобное поведение с:

root@kube-node-3:~# uname -a
Linux kube-node-3 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 GNU/Linux

Кто-нибудь может объяснить такое поведение? Можно ли это исправить, чтобы он работал так, как я ожидал?

PS. приносим свои извинения за неидеальный тестовый IP-адрес 192.168.2.55/32 - это правильно, как написано, и не путать с широковещательным адресом 255. То же самое с IPv6-адресом.

2
Penguin Brian 7 Дек 2020 в 11:40
1
Я недостаточно знаю, чтобы написать ответ, но я знаю, что он должен работать таким образом для IPv6 для целей множественной адресации, в отличие от IPv4. (Примерно по той же причине, по которой маршруты IPv6 могут совпадать как по источнику, так и по месту назначения.)
 – 
user1686
7 Дек 2020 в 17:38
Я нашел ошибку? Если да, то куда я должен сообщить об этом? Как я могу связаться с кем-то, кто мог бы помочь?
 – 
Penguin Brian
13 Дек 2020 в 12:46
1
Ошибка? Нет, как я уже сказал, так оно и должно работать.
 – 
user1686
13 Дек 2020 в 13:13
О, извините, я думал, вы имели в виду, что поведение, которое я ожидал, было тем, как оно должно работать. В отличие от поведения, которое я наблюдал. Моя установка Kubernetes с двумя стеками, похоже, полагается на это. У вас есть какие-либо ссылки, чтобы поддержать вас в этом?
 – 
Penguin Brian
14 Дек 2020 в 03:17
Подождите, Kubernetes действительно использует фиктивные интерфейсы? Для какой части Kubernetes?
 – 
dirkt
15 Дек 2020 в 01:15

1 ответ

Вот очень похожий вопрос, заданный для IPv4:

https://serverfault.com/questions/834512/why-does-linux-answer-to-arp-on-incorrect-interfaces

Я считаю, что это также известно как «строгий арп». Я считаю, что «строгий arp» включен по умолчанию, но «строгий ndp» по умолчанию отключен (на самом деле даже не уверен, что вы можете это изменить).

Поэтому, хотя я не могу найти никаких ссылок, я подозреваю, что это предполагаемое поведение.

1
Penguin Brian 15 Дек 2020 в 00:19