Таким образом, как я могу заставить интерфейс использовать глобальный IPv6-адрес в качестве источника для сообщений запроса соседей, а не адрес ссылки?
Задний план: Многие провайдеры VPS не выделяют маршрутизируемый IPv6/64, а просто назначают блок на /48. Шлюз — это глобальный IPv6-адрес в /48, но вне /64. Шлюз отвечает на сообщения NS, отправленные с глобального адреса, но не отвечает на сообщения NS по адресу ссылки (ни на сообщения RS из любого источника). Это нормально, когда на VPS генерируется глобальный трафик. Однако, когда трафик возникает внутри контейнера LXC на [KVM] VPS, адрес ссылки используется для NS на шлюз, и обнаружение соседей не работает.
Основная проблема (пример из реальной жизни):
Происхождение LXC -> lxcbr0 -> eth0 -> Шлюз провайдера VPS -> Интернет
Начиная с eth0. Базовая настройка KVM VPS выглядит следующим образом:
# IP-адрес шоу-разработчика eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast состояние UP группа по умолчанию qlen 1000
ссылка/эфир 00:16:3c:a8:db:1b brd ff:ff:ff:ff:ff:ff
inet6 2a01:8888:1:5555::4444/64 глобальная область действия
valid_lft навсегда
ссылка на область inet6 fe80::216:3cff:fea8:db1b/64
valid_lft навсегда
# ип -6 р
2a01:8888:1::1 dev eth0 metric 1024 pref средний
2a01:8888:1:5555::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref средний
по умолчанию через 2a01:8888:1::1 dev eth0 metric 1024 pref medium
Это работает в следующем смысле:
# пинг ipv6.google.com -c 3
PING ipv6.google.com (2a00:1450:400e:810::200e): 56 байт данных
64 байта из 2a00:1450:400e:810::200e: seq=0 ttl=117 time=36,298 мс
64 байта из 2a00:1450:400e:810::200e: seq=1 ttl=117 time=33,580 мс
64 байта из 2a00:1450:400e:810::200e: seq=2 ttl=117 time=33,112 мс
--- Статистика пинга ipv6.google.com ---
3 пакета передано, 3 пакета получено, 0% потери пакетов
туда-обратно мин./средн./макс. = 33,112/34,330/36,298 мс
# ndisc6 -s 2a01:8888:1:5555::4444 2a01:8888:1::1 eth0
Запрос 2a01:8888:1::1 (2a01:8888:1::1) на eth0...
Целевой адрес канального уровня: 3C:61:04:A4:1F:7C
из 2a01:8888:1::1
Теперь LXC имеет следующее lxcbr0 настраивать:
# IP-адрес шоу-разработчика lxcbr0
3: lxcbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
ссылка/эфир 00:16:3e:a7:17:58 брд ff:ff:ff:ff:ff:ff
inet6 2a01:8888:1:5555:216::ffff/64 глобальная область действия
valid_lft навсегда
ссылка на область inet6 fe80::216:3eff:fea7:1758/64
valid_lft навсегда
и внутри контейнера (с помощью вет ссылка к lxcbr0) выглядит так:
# IP шоу eth0
2: eth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
ссылка/эфир 00:16:3e:2f:82:a7 brd ff:ff:ff:ff:ff:ff ссылка-netnsid 0
inet6 2a01:8888:1:5555::1238/64 глобальная область действия
valid_lft навсегда
inet6 fe80::216:3eff:fe2f:82a7/64 ссылка на область видимости
valid_lft навсегда
# ип -6 р
2a01:8888:1:5555::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref средний
по умолчанию через fe80::216:3eff:fea7:1758 dev eth0 metric 1024 pref medium
Однако это не работает:
# пинг ipv6.google.com -c 3
PING 2a00:1450:400e:810::200e (2a00:1450:400e:810::200e): 56 байт данных
--- 2a00:1450:400e:810::200e статистика пинга ---
3 пакета передано, 0 пакетов получено, 100% потери пакетов
Причина проблемы
Если я сделаю tcpdump на хосте я наблюдаю, что когда трафик исходит из контейнера LXC, сообщение NS на шлюз приходит с адреса ссылки:
# tcpdump ip6
tcpdump: подробный вывод подавлен, используйте -v[v]... для полного декодирования протокола
прослушивание на eth0, тип канала EN10MB (Ethernet), длина снимка 262144 байт
08:41:55.229077 IP6 fe80::216:3cff:fea8:db1b > ff02::1:ff00:1: ICMP6, запрос соседа, у кого есть 2a01:8888:1::1, длина 32
08:41:56.305550 IP6 fe80::216:3cff:fea8:db1b > ff02::1:ff00:1: ICMP6, запрос соседа, у кого есть 2a01:8888:1::1, длина 32
08:41:57.345548 IP6 fe80::216:3cff:fea8:db1b > ff02::1:ff00:1: ICMP6, запрос соседа, у кого есть 2a01:8888:1::1, длина 32
# ip -6 n показать разработчику eth0
2a01:8888:1::1 маршрутизатор СБОЙ
...
Напротив, тот же tcpdump когда пинг выполняется вне контейнера LXC:
# tcpdump ip6
tcpdump: подробный вывод подавлен, используйте -v[v]...для полного декодирования протокола
прослушивание на eth0, тип канала EN10MB (Ethernet), длина снимка 262144 байт
10:06:33.926756 IP6 2a01:8888:1:5555::4444 > ff02::1:ff00:1: ICMP6, запрос соседа, у кого есть 2a01:8888:1::1, длина 32
10:06:33.929886 IP6 2a01:8888:1::1 > 2a01:8888:1:5555::4444: ICMP6, объявление соседа, tgt 2a01:8888:1::1, длина 32
10:06:33.929917 IP6 2a01:8888:1:5555::4444 > ams17s12-in-x0e.1e100.net: ICMP6, эхо-запрос, идентификатор 52543, последовательность 0, длина 64
10:06:33.962581 IP6 ams17s12-in-x0e.1e100.net > 2a01:8888:1:5555::4444: ICMP6, эхо-ответ, идентификатор 52543, последовательность 0, длина 64
10:06:34.926947 IP6 2a01:8888:1:5555::4444 > ams17s12-in-x0e.1e100.net: ICMP6, эхо-запрос, идентификатор 52543, последовательность 1, длина 64
10:06:34.959682 IP6 ams17s12-in-x0e.1e100.net > 2a01:8888:1:5555::4444: ICMP6, эхо-ответ, идентификатор 52543, последовательность 1, длина 64
10:06:35.927166 IP6 2a01:8888:1:5555::4444 > ams17s12-in-x0e.1e100.net: ICMP6, эхо-запрос, идентификатор 52543, последовательность 2, длина 64
10:06:35.959820 IP6 ams17s12-in-x0e.1e100.net > 2a01:8888:1:5555::4444: ICMP6, эхо-ответ, идентификатор 52543, последовательность 2, длина 64
# ip -6 n показать разработчику eth0
2a01:8888:1::1 dev eth0 lladdr 3c:61:04:a4:1f:7c маршрутизатор ДОСТУПНО
...
Провайдер не дает IP шлюза ссылки. я пытался использовать lxcbr0глобальный адрес в качестве шлюза внутри контейнера LXC без какой-либо разницы. Эта конфигурация, по-видимому, распространена среди провайдеров, поэтому обращение к ним с просьбой изменить/исправить их архитектуру вряд ли приведет к решению.
Как я могу решить основную проблему подключения IPv6 из контейнера LXC, все еще используя вет? Предложения очень приветствуются.
