Назад | Перейти на главную страницу

Шлюз 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

На нерабочих машинах проверка связи gw или workd возвращает "Destination unreachable".

Все машины могут связываться друг с другом по локальной сети.

Не знаю, актуально ли это, но

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-адресом. О, мой бог Рабочие IPv6 - нет.

OVH не знает, как правильно использовать IPv6, их настройка работает только в определенных ситуациях, а не везде.

Он работает без особых проблем только тогда, когда серверы открыты для всего мира и также имеют публичные IPv4-адреса.

Они не могут предоставить один общедоступный ipv6 и маршрутизируемую к нему подсеть, что необходимо, если кто-то хочет запускать виртуальные машины за собственным брандмауэром.

Пока они не начнут работать, лучше поискать в другом месте, если вас интересует IPv6.

OVH обеспечивает безопасность портов коммутаторов на своих коммутаторах, поэтому только MAC-адреса из белого списка могут использовать любой заданный порт. Это не относится к vRack; Безопасность порта коммутатора отключена на vRack. Но OVH пока не позволяет маршрутизировать подсети IPv6 в vRack. И ты не можешь аварийное переключение подсеть IPv6 на другой сервер. Это критическая оплошность; пока не появятся обе эти возможности, рассматривается поддержка OVH IPv6. ограниченное.

Итак, вот как я настроил сервер 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).