Nós temos um servidor dedicado na OVH, atribuído em 2001: 41d0: a: 72xx :: / 64
Eu configurei as máquinas em um segmento conectado ao wan, conforme Roteamento público IPv6 de máquinas virtuais do host
O gateway é 2001: 41d0: a: 72ff: ff: ff: ff: ff, fora da rede
Estamos executando um monte de servidores Debian virtuais.
Alguns de nossos servidores (mais antigos) ficam felizes em rotear o ipv6 para o gateway, mas o novo que estou tentando configurar está dizendo: "Destino inacessível; Endereço inacessível" ao pingar o gw.
O firewall é configurado igualmente (regras para / 64, não no nível do host) e / etc / network / interfaces são iguais; ipv6 são definidos estáticos. (diferentes endereços de causa)
Na máquina que trabalha ou não, 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
Nas máquinas que não funcionam, o ping do gw ou do workd retorna "Destino inacessível".
As máquinas podem se encontrar na lan local.
Não sei se é relevante, mas
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!)
No não funcionamento
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!)
O: fffd amd: fffe endereços ausentes.
Todos os endereços ipv6 foram atribuídos no painel de controle da OVH.
TL; DR: algo deve ser diferente entre os servidores antigo e novo, mas não consigo encontrá-lo.
UPDATE: um clone de uma máquina em funcionamento não funciona.
Na parte externa do pfsense, configurada como bridge, a máquina envia isto:
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
Mas nada nunca volta. Pings do lado de fora não passam por qualquer um.
Como a máquina é um clone exato de uma máquina em funcionamento, com exceção dos endereços IP, deve ser um problema a montante na OVH.
UPDATE 2 Agora, a OVH afirma que, para obter dados roteados para um IPv6, o mac precisa estar associado a um endereço IPv4. OMG Os IPv6 de trabalho não são.
OVH não sabe como fazer o IPv6 corretamente, sua configuração só funciona em certas situações, não aplicável em todos os lugares.
Ele só funciona sem saltos especiais quando os servidores são expostos ao mundo e também possuem endereços IPv4 públicos.
Eles não podem fornecer um ipv6 público e uma sub-rede roteada para ele, o que é necessário se alguém quiser executar o próprio firewall da VM.
Até que eles consigam trabalhar, é melhor procurar em outro lugar, se você estiver interessado em IPv6.
O OVH executa a segurança da porta do comutador em seus comutadores, de modo que somente endereços MAC na lista de permissões possam usar qualquer porta especificada. Isso não se aplica ao vRack; A segurança da porta do switch está desativada no vRack. Mas a OVH não permitirá que você rotear sub-redes IPv6 para vRack ainda. Nem você pode failover uma sub-rede IPv6 para outro servidor. Esta é uma supervisão crítica; até que ambas as capacidades existam, o suporte IPv6 da OVH é considerado limitado .
Então, é assim que configurei um servidor OVH executando algumas dúzias de máquinas virtuais:
No servidor host, br3 é uma ponte que contém eno3 e interfaces de rede virtual nas quais eu roteio o IPv6. O host está configurado como:
# 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"
Eu tenho rotas estáticas configuradas como:
# 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
Eu, então, executo ndppd , que responde às consultas de solicitação do vizinho NDP para qualquer endereço no meu / 64. Está configurado como tal:
# cat /etc/ndppd.conf
route-ttl 30000
proxy br3 {
router yes
timeout 500
ttl 30000
rule 2001:db8:1f3:c187::/64 {
static
}
}
Isso faz com que o endereço MAC do host seja usado para todos os endereços IPv6 na sub-rede, que eu, então, roteio para as interfaces virtuais no libvirt, divididas em / 80 redes. Um exemplo é configurado como tal:
# 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>
Todas as VMs nessa rede específica recebem endereços IPv6 manuais, mas você pode configurar o DHCPv6, se desejar. Isso seria parecido com:
<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>
Em seguida, roteio os endereços de failover IPv4 para o vRack, que é vinculado a uma única ponte br4 on eno4 que todas as minhas VMs obtêm de uma NIC virtual segundo . Assim, eles têm IPv6 em uma interface e IPv4 em outra. Isso é opcional; você poderia manter apenas os endereços de failover do IPv4 na sua interface principal (se você não tiver um vRack, por exemplo).