Шлюз IPv6 вне сети (OVH)
Мы выделенный сервер в OVH, назначенный 2001:41d0:a:72xx::/64
Я установил машины в сегмент, соединенный с WAN, согласно публичной маршрутизации IPv6 виртуальных машин от хоста.
Шлюз 2001:41d0:a:72ff:ff:ff:ff:ff, вне сети
У нас работает куча виртуальных серверов Debian.
Некоторые из наших (старых) серверов готовы маршрутизировать ipv6 к шлюзу, но я пытаюсь настроить новый: "Пункт назначения недоступен; адрес недоступен" при проверке связи с gw.
Брандмауэр настроен одинаково (правила для /64, а не на уровне хоста), и /etc/network/interfaces равны; IPv6 установлены статические. (разные адреса причины)
На работающем и нерабочем компьютере netstat -rn6|grep eth1 show
2001:41d0:a:72xx::/64 :: U 256 2 40 eth1
2001:41d0:a:7200::/56 :: UAe 256 2 71 eth1
2001:41d0:a1:72xx::/64 :: UAe 256 0 0 eth1
2000::/3 2001:41d0:a:72ff:ff:ff:ff:ff UG 1024 2 63479 eth1
fe80::/64 :: U 256 0 0 eth1
::/0 fe80::205:73ff:fea0:1 UGDAe 1024 1 2 eth1
::/0 fe80::20c:29ff:fe22:60f8 UGDAe 1024 0 0 eth1
ff00::/8 :: U 256 2108951 eth1
На нерабочих машинах pinging gw или workd возвращает "Пункт назначения недоступен".
Все машины могут достигать друг друга по локальной сети.
Я не знаю, насколько это актуально, но
ping -c3 ff02::2%eth1
64 bytes from fe80::20c:29ff:fedb:a137%eth1: icmp_seq=1 ttl=64 time=0.240 ms
64 bytes from fe80::20c:29ff:fe22:60f8%eth1: icmp_seq=1 ttl=64 time=0.250 ms (DUP!)
64 bytes from fe80::2ff:ffff:feff:fffd%eth1: icmp_seq=1 ttl=64 time=3.57 ms (DUP!)
64 bytes from fe80::2ff:ffff:feff:fffe%eth1: icmp_seq=1 ttl=64 time=5.97 ms (DUP!)
На нерабочих
ping -c3 ff02::2%ens34
PING ff02::2%ens34(ff02::2%ens34) 56 data bytes
64 bytes from fe80::20c:29ff:fedb:a137%ens34: icmp_seq=1 ttl=64 time=0.130 ms
64 bytes from fe80::20c:29ff:fe22:60f8%ens34: icmp_seq=1 ttl=64 time=0.138 ms (DUP!)
Адреса: fffd amd: fffe отсутствуют.
Все ipv6-адреса были назначены на панели управления OVH.
TL; DR: Что-то должно отличаться между старым и новым серверами, но я не могу найти это.
ОБНОВЛЕНИЕ: клон работающей машины не работает.
На внешней стороне pfsense, настроенного как мост, машина отправляет это:
12:33:23.087778 IP6 test1.example.org > fe80::2ff:ffff:feff:fffe: ICMP6, neighbor advertisement, tgt is test1.example.org, length 32
12:33:24.106302 IP6 test1.example.org > par10s28-in-x0e.1e100.net: ICMP6, echo request, seq 451, length 64
Но ничего не вернется. Пингс снаружи тоже не проходит.
Поскольку машина является точным клоном работающей машины, за исключением IP-адресов, она должна быть проблемой восходящего потока в OVH.
ОБНОВЛЕНИЕ 2 Теперь OVH утверждает, что для передачи данных в IPv6, Mac должен быть связан с адресом IPv4. OMG Работающие IPv6 не являются.
2 ответа
OVH не знает, как правильно выполнять IPv6, их настройка работает только в определенных ситуациях и не везде применима.
Он работает только без специальных скачков, когда серверы доступны миру и также имеют публичные IPv4-адреса.
Они не могут предоставить один общедоступный ipv6 и маршрутизируемую к нему подсеть, что необходимо, если вы хотите запустить виртуальную машину за собственным брандмауэром.
Пока они не заработают, лучше поискать в другом месте, если вы заинтересованы в IPv6.
OVH обеспечивает безопасность порта коммутатора на своих коммутаторах, так что только один MAC-адрес из белого списка может использовать любой данный порт. Это не относится к vRack; Защита порта коммутатора отключена на vRack. Но OVH пока не позволит вам направить подсети IPv6 в vRack. Также вы не можете переключать подсеть IPv6 на другой сервер. Это критический контроль; пока обе эти возможности не существуют, поддержка IPv6 в OVH считается ограниченной.
Вот как я настроил сервер OVH, на котором запущено несколько десятков виртуальных машин:
На хост-сервере br3 - это мост, содержащий eno3 и виртуальные сетевые интерфейсы, по которым я маршрутизирую IPv6. Хост настроен как:
# cat /etc/sysconfig/network-scripts/ifcfg-br3
DEVICE="br3"
TYPE="Bridge"
STP="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_FAILURE_FATAL="no"
NAME="br3"
ONBOOT="yes"
ZONE="public"
BOOTPROTO="static"
IPADDR="203.0.113.24"
PREFIX="24"
GATEWAY="203.0.113.1"
IPV6_AUTOCONF="no"
IPV6ADDR="2001:db8:1f3:c187::/64"
У меня статические маршруты настроены так:
# cat /etc/sysconfig/network-scripts/route6-br3
2001:db8:1f3:c187::/64 dev br3
2001:db8:1f3:c1ff:ff:ff:ff:ff dev br3
default via 2001:db8:1f3:c1ff:ff:ff:ff:ff dev br3
Я тогда бегу ndppd
, который отвечает на запросы запроса соседей NDP для любого адреса в my /64. Это настроено так:
# cat /etc/ndppd.conf
route-ttl 30000
proxy br3 {
router yes
timeout 500
ttl 30000
rule 2001:db8:1f3:c187::/64 {
static
}
}
Это приводит к тому, что MAC-адрес хоста будет использоваться для всех адресов IPv6 в подсети, которые я затем маршрутизирую на виртуальные интерфейсы в libvirt, разбитые на сети /80. Один пример настроен так:
# cat /etc/libvirt/qemu/networks/v6bridge_1.xml
<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
virsh net-edit v6bridge_1
or other application using the libvirt API.
-->
<network>
<name>v6bridge_1</name>
<uuid>7007a2b2-08b8-4cd5-a4aa-49654ae0829b</uuid>
<forward mode='route'/>
<bridge name='v6bridge_1' stp='on' delay='0'/>
<mac address='52:54:00:fc:d4:da'/>
<ip family='ipv6' address='2001:db8:1f3:c187:1::' prefix='80'>
</ip>
</network>
Всем виртуальным машинам в этой конкретной сети назначаются адреса IPv6 вручную, но вы можете настроить DHCPv6, если хотите. Это будет выглядеть так:
<ip family='ipv6' address='2001:db8:1f3:c187:1::' prefix='80'>
<dhcp>
<range start="2001:db8:1f3:c187:1::100" end="2001:db8:1f3:c187:1::1ff"/>
</dhcp>
</ip>
Затем я направляю адреса отработки отказа IPv4 в vRack, который соединен с одним мостом. br4
на eno4
что все мои виртуальные машины получают второй виртуальный сетевой адаптер. Таким образом, у них есть IPv6 на одном интерфейсе и IPv4 на другом. Это необязательно; Вы можете просто сохранить адреса отработки отказа IPv4 на своем главном интерфейсе (например, если у вас нет vRack).