Serveur Debian OVH Proxmox : IPv6 sur hôte (Wheezy)

C9H8O4 · Février 21, 2016, 9:31pm

Bonjour,

Mon serveur est installé chez OVH avec la distribution Proxmox d’OVH (Debian 7).

J’ai suivi les instructions sur la page guides.ovh.net/bridgeclient pour configurer les IP failover des VM, ça marche.

J’ai ensuite voulu configurer l’adressage IPv6, mais même sur l’hôte seul cela ne fonctionne pas. J’ai suivi ce guide guide.ovh.com/Ipv4Ipv6 .

Mon fichier /etc/network/interfaces est le suivant :

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# for Routing
auto vmbr1
iface vmbr1 inet manual
	post-up /etc/pve/kvm-networking.sh
	bridge_ports dummy0
	bridge_stp off
	bridge_fd 0


# vmbr0: Bridging. Make sure to use only MAC adresses that were assigned to you.
auto vmbr0
iface vmbr0 inet static
	address 37.59.48.27
	netmask 255.255.255.0
	network 37.59.48.0
	broadcast 37.59.48.255
	gateway 37.59.48.254
	bridge_ports eth0
	bridge_stp off
	bridge_fd 0

iface vmbr0 inet6 static
	address 2001:41D0:8:6B1b::1
	netmask 64
	post-up /sbin/ip -f inet6 route add 2001:41D0:8:6Bff:ff:ff:ff:ff dev vmbr0
	post-up /sbin/ip -f inet6 route add default via 2001:41D0:8:6Bff:ff:ff:ff:ff dev vmbr0
	pre-down /sbin/ip -f inet6 route del 2001:41D0:8:6Bff:ff:ff:ff:ff dev vmbr0
	pre-down /sbin/ip -f inet6 route del default via 2001:41D0:8:6Bff:ff:ff:ff:ff dev vmbr0

La commande “ifconfig” me retourne :

[code]dummy0 Link encap:Ethernet HWaddr 32:be:e1:ed:68:4d
adr inet6: fe80::30be:e1ff:feed:684d/64 Scope:Lien
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:873 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 B) TX bytes:57630 (56.2 KiB)

eth0 Link encap:Ethernet HWaddr 74:d0:2b:27:d6:d0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10539198 errors:0 dropped:0 overruns:0 frame:0
TX packets:5599033 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:15050630197 (14.0 GiB) TX bytes:491189327 (468.4 MiB)

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:279 errors:0 dropped:0 overruns:0 frame:0
TX packets:279 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:34935 (34.1 KiB) TX bytes:34935 (34.1 KiB)

tap100i0 Link encap:Ethernet HWaddr 4a:7b:e3:b6:7c:ce
adr inet6: fe80::487b:e3ff:feb6:7cce/64 Scope:Lien
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:5284130 errors:0 dropped:0 overruns:0 frame:0
TX packets:10168271 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:500
RX bytes:461061787 (439.7 MiB) TX bytes:15012083823 (13.9 GiB)

tap101i0 Link encap:Ethernet HWaddr 9e:b4:05:ee:4b:3a
adr inet6: fe80::9cb4:5ff:feee:4b3a/64 Scope:Lien
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:142824 errors:0 dropped:0 overruns:0 frame:0
TX packets:133180 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:500
RX bytes:14615221 (13.9 MiB) TX bytes:23649072 (22.5 MiB)

venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
adr inet6: fe80::1/128 Scope:Lien
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:3 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

vmbr0 Link encap:Ethernet HWaddr 74:d0:2b:27:d6:d0
inet adr:37.59.48.27 Bcast:37.59.48.255 Masque:255.255.255.0
adr inet6: 2001:41d0:8:6b1b::1/64 Scope:Global
adr inet6: fe80::76d0:2bff:fe27:d6d0/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:215845 errors:0 dropped:0 overruns:0 frame:0
TX packets:128084 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:10553078 (10.0 MiB) TX bytes:12615701 (12.0 MiB)

vmbr1 Link encap:Ethernet HWaddr 32:be:e1:ed:68:4d
adr inet6: fe80::30be:e1ff:feed:684d/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 B) TX bytes:578 (578.0 B)[/code]

Ma table de routage renvoyé par la commande “ip -6 route” est la suivante :

2001:41d0:8:6b1b::/64 dev vmbr0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 2001:41d0:8:6bff:ff:ff:ff:ff dev vmbr0 metric 1024 mtu 1500 advmss 1440 hoplimit 0 fe80::1 dev venet0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 fe80::/64 dev dummy0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 fe80::/64 dev vmbr1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 fe80::/64 dev vmbr0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 fe80::/64 dev venet0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 fe80::/64 dev tap100i0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 fe80::/64 dev tap101i0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 default via 2001:41d0:8:6bff:ff:ff:ff:ff dev vmbr0 metric 1024 mtu 1500 advmss 1440 hoplimit 0

A noter que je n’ai pas (encore) activé le forwarding IPv6 dans systcl.conf, en fait je n’ai même pas touché au sysctl, je cherche déjà à faire fonctionner l’hôte en IPv6.

Je n’arrive pas à pinguer la gateway :

PING 2001:41d0:8:6bff:ff:ff:ff:ff(2001:41d0:8:6bff:ff:ff:ff:ff) 56 data bytes ^C --- 2001:41d0:8:6bff:ff:ff:ff:ff ping statistics --- 16 packets transmitted, 0 received, 100% packet loss, time 15008ms

Ni un hôte en IPv6 :

PING google.com(par10s10-in-x03.1e100.net) 56 data bytes ^C --- google.com ping statistics --- 16 packets transmitted, 0 received, 100% packet loss, time 14999ms

Le plus étrange étant les lignes “no IPv6 routers present” dans le syslog (récupérées après reboot) :

Apr 1 10:40:37 ns3001019 kernel: Loading kernel module for a network device with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev-dummy0 instead Apr 1 10:40:37 ns3001019 kernel: device dummy0 entered promiscuous mode Apr 1 10:40:37 ns3001019 kernel: vmbr1: port 1(dummy0) entering forwarding state Apr 1 10:40:37 ns3001019 kernel: device eth0 entered promiscuous mode ... Apr 1 10:40:37 ns3001019 kernel: r8169 0000:03:00.0: eth0: link up Apr 1 10:40:37 ns3001019 kernel: vmbr0: port 1(eth0) entering forwarding state Apr 1 10:40:37 ns3001019 kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready ... Apr 1 10:40:43 ns3001019 kernel: dummy0: no IPv6 routers present Apr 1 10:40:43 ns3001019 kernel: device tap100i0 entered promiscuous mode Apr 1 10:40:43 ns3001019 kernel: u32 classifier Apr 1 10:40:43 ns3001019 kernel: Performance counters on Apr 1 10:40:43 ns3001019 kernel: input device check on Apr 1 10:40:43 ns3001019 kernel: Actions configured Apr 1 10:40:43 ns3001019 kernel: HTB: quantum of class 10001 is big. Consider r2q change. Apr 1 10:40:43 ns3001019 kernel: vmbr0: port 2(tap100i0) entering forwarding state Apr 1 10:40:44 ns3001019 kernel: vmbr0: no IPv6 routers present Apr 1 10:40:44 ns3001019 kernel: vmbr1: no IPv6 routers present ... Apr 1 10:40:48 ns3001019 kernel: device tap101i0 entered promiscuous mode Apr 1 10:40:48 ns3001019 kernel: HTB: quantum of class 10001 is big. Consider r2q change. Apr 1 10:40:48 ns3001019 kernel: vmbr0: port 3(tap101i0) entering forwarding state ... Apr 1 10:40:50 ns3001019 kernel: venet0: no IPv6 routers present ... Apr 1 10:40:54 ns3001019 kernel: tap100i0: no IPv6 routers present Apr 1 10:40:58 ns3001019 kernel: tap101i0: no IPv6 routers present

Avez-vous des pistes pour faire fonctionner l’adressage IPv6 ?

C9H8O4 · Février 21, 2016, 9:31pm

Je me réponds à moi-même : étant donné que ça semblait être un problème de NDP, j’ai vérifié la capacité “autoconf” des différentes interfaces dans /prox/sys/net/*/autoconf, et là surprise, la seule qui avait le autoconf désactivé était vmbr0 c’et à dire mon interface bridge

Je l’ai activée dans le sysctl :

net.ipv6.conf.vmbr0.autoconf = 1

J’ai redémarré, et tout s’est mis à marcher tout seul, du moins l’hôte est maintenant accessible en IPv6.

Du coup je vais m’intéresser à l’adressage des VMs maintenant (proxy NDP, forwarding et tout ça).

Le seul problème que je vois c’est que si j’active le forwarding sur l’hôte en IPv6, ça va désactiver l’autoconf de l’hôte, non ?

PascalHambourg · Février 21, 2016, 9:31pm

Oui.
En quoi est-ce un problème, quelle est la topologie réseau de l’ensemble ?
Je n’ai pas lu le premier message.

C9H8O4 · Février 21, 2016, 9:31pm

Bonjour et merci pour votre réponse.

Si j’ai bien compris, OVH me branche sur eth0, et me propose d’utiliser le bridge vmbr0 pour y brancher les failover des VMs. L’interface vmbr1 est réservée au mode “routed” et l’interface vmbr0 au mode “bridge” sur proxmox.

Le problème c’est que j’ai dût activer explicitement l’autoconf sur vmbr0 pour que l’hôte puisse router ses paquets en IPv6.

Si j’active le forwarding sur vmbr0 et que j’installe un proxy NDP pour adresser les VM (parce que OVH exige que les machines derrière le /64 soient sur un modèle “plat”), le forwarding va (re-)désactiver l’autoconf, et donc l’hôte ne pourra plus router ses paquets en IPv6 vers l’extérieur donc les VMs non plus. Du moins c’est ce que je suppose.

Après, si ça marche sur les VM mais pas sur l’hôte, ça m’embêterait mais c’est un moindre mal.

PascalHambourg · Février 21, 2016, 9:31pm

Si les machines virtuelles sont directement pontées avec le réseau extérieur à travers vmbr0, alors l’hôte n’a pas besoin d’avoir le forwarding activé. Il se comporte comme un switch, pas comme un routeur.

Par contre il n’est pas normal d’avoir dû activer l’autoconf pour que la connectivité IPv6 fonctionne. Qu’affichent [mono]ip -6 addr[/mono] et [mono]ip -6 route[/mono] avec l’autoconf à 1 ?

Je suis dubitatif quand tu évoques un problème de NDP, car dans ce cas il aurait dû y avoir des messages d’erreur “destination host unreachable” à cause de l’échec de la résolution d’adresse IPv6.

C9H8O4 · Février 21, 2016, 9:31pm

Il y en avait, si j’attendais assez longtemps (3 secondes) au moment où je lançais mes pings, j’avais des retours en “adress unreacheable” (mais au bout de 20 fois je suis devenu impatient et du coup on les voit pas dans mon copier-coller dans le premier message). Les lignes “no ipv6 routers present” dans le syslog m’ont aussi orienté vers un problème de ce type.

Mais bon, maintenant avec l’autoconf qui marche, ça veut donc dire que maintenant les NDP marchent, je suppose.

À l’heure actuelle, autoconf à 1 :

ip -6 addr :

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 inet6 fe80::b0eb:6cff:fe12:2150/64 scope link valid_lft forever preferred_lft forever 4: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 inet6 fe80::b0eb:6cff:fe12:2150/64 scope link valid_lft forever preferred_lft forever 5: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 inet6 2001:41d0:8:6b1b::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::76d0:2bff:fe27:d6d0/64 scope link valid_lft forever preferred_lft forever 6: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 inet6 fe80::1/128 scope link valid_lft forever preferred_lft forever 7: tap100i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qlen 500 inet6 fe80::7431:d5ff:fe33:3bd3/64 scope link valid_lft forever preferred_lft forever 8: tap101i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qlen 500 inet6 fe80::f47c:caff:fec1:9c6b/64 scope link valid_lft forever preferred_lft forever

ip -6 route :

2001:41d0:8:6b1b::/64 dev vmbr0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 2001:41d0:8:6bff:ff:ff:ff:ff dev vmbr0 metric 1024 mtu 1500 advmss 1440 hoplimit 0 2001:41d0:8:6b00::/56 dev vmbr0 proto kernel metric 256 expires 2538754sec mtu 1500 advmss 1440 hoplimit 0 fe80::1 dev venet0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 fe80::/64 dev dummy0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 fe80::/64 dev vmbr1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 fe80::/64 dev vmbr0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 fe80::/64 dev venet0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 fe80::/64 dev tap100i0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 fe80::/64 dev tap101i0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 default via 2001:41d0:8:6bff:ff:ff:ff:ff dev vmbr0 metric 1024 mtu 1500 advmss 1440 hoplimit 0

Ce qui n’est pas très différent (la route a un enregistrement en plus : la troisieme ligne) à ce que j’avais dans mon premier message quand l’autoconf de vmbr0 était à 0 (l’autoconf des autres étaient à 1).

ça me semblait logique aussi, mais ce n’est pas ce que semble dire le tuto : how-to.ovh/viewtopic.php?t=40#p88 ; sauf erreur d’interprétation de ma part.

AnonymousCoward · Février 21, 2016, 9:32pm

Je me permets d’ajouter une petite précision utile car je travaille moi aussi avec un équivalent à Proxmox avec de l’IPv6 chez OVH.

Chez OVH, on peut parfaitement avoir des VMs bridgées sur le vmbr0. Mais OVH, pour éviter toute usurpation d’adresse MAC, impose de faire une demande pour une adresse MAC, qu’ils appellent “MAC virtuelle”.
Et si le routeur d’OVH voit passer une adresse MAC qui lui est inconnue, les paquets associés sont bloqués et on en arrive à ce que OVH se penche sur notre cas et sorte le fouet, ça ne rigole pas !

Le problème est que OVH ne fournit pas de “MAC virtuelle” séparément d’une adresse IPv4. Donc, si l’on souhaite avoir une VM en IPv6 seul, on l’a dans le [censuré] .
OVH craint peut-être que l’on sature une mémoire quelconque dans les routeurs CISCO. Pauvres petites bêtes fragiles…

Résultat : Soit l’on met en place une configuration où l’IPv4 est bridgé et l’IPv6 routé (bridge + routeur, compliqué) soit l’on passe tout en routé avec proxy ARP / NDP pour IPv4 et IPv6 respectivement.

Clairement, la solution de passer tout en routé avec proxys ARP et NDP est ce que je conseillerais. En plus, cela nous libère de la gestion des “MAC virtuelles”.

–
AnonymousCoward

C9H8O4 · Février 21, 2016, 9:32pm

Bonjour AnonymousCoward,

Donc,

Si je suis en mode bridge et en autoconf, que j’ai déjà une IPv4 sur les VM, avec une mac virtuelle que j’ai réglée dans Proxmox.

Je n’ai rien besoin d’autre pour l’IPv6 de mes VM que de configurer mes VM comme je viens de configurer l’hôte, c’est ça ? Pas d’activation du forwarding, pas de proxy NDP, ça marchera “tout seul” ?

Désolé si c’est une question bête
Évidemment, je suppose que je dois mettre l’IPv6 et l’IPv4 de la VM sur la même interface pour que la MAC soit partagée.