Contrairement au mode routé venet, le mode virtual ethernet veth d’OpenVZ permet de mapper directement une interface virtuelle Ethernet depuis l’hôte réel dans un serveur virtuel. La virtualisation réseau ne s’effectue donc plus au niveau 3 (routage IP) mais au niveau 2 (Ethernet). Chaque interface virtuelle possède alors son adresse MAC., ce qui autorise le trafic multicast (par finalité DHCP, SMB) et la gestion iptables dans vos CT. Les interfaces réseaux sont d’ailleurs adressables dans le serveur virtuel, pour peu que le mappage soit effectué entre l’hôte réel et l’hôte virtuel.
Je vais expliquer dans ce billet les points importants afin de configurer le mode veth en IPv4 mais surtout IPv6. Ceci ne vous empêche pas une configuration mixte venet & veth.
OpenVZ est installé sous un hôte réel Debian Lenny 64 bits. Au niveau de sa configuration réseau, une interface bridge vmbr0 est créée à laquelle j’ajoute les IP publiques du serveur : une IPv6 et une IPv4 en alias. Par la suite, les interfaces réseaux virtuelles veth<CTID>.<ID> seront créées par OpenVZ, qui les ajoutera au bridge, tout en les mappant dans le CT considéré en interface eth<ID>.
root@HN:/# more /etc/network/interfaces |
01 |
root@HN:/# network interface settings |
03 |
iface lo inet loopback |
05 |
iface eth0 inet manual |
08 |
iface vmbr0 inet6 static |
09 |
address 2001:1234:5678::2 |
11 |
gateway 2001:1234:5678::1 |
16 |
iface vmbr0:0 inet static |
18 |
netmask 255.255.255.224 |
Les paramètres noyaux suivants sont à fixer pour pouvoir bénéficier du support IPv4 et IPv6 depuis l’environnement virtualisé :
root@HN:/# more /etc/sysctl.conf |
02 |
net.ipv4.ip_forward = 1 |
03 |
net.ipv4.conf.default.proxy_arp = 0 |
04 |
net.ipv4.conf.all.rp_filter = 1 |
05 |
net.ipv4.conf.default.send_redirects = 1 |
06 |
net.ipv4.conf.all.send_redirects = 0 |
07 |
net.ipv6.conf.default.forwarding = 1 |
08 |
net.ipv6.conf.all.forwarding = 1 |
09 |
net.ipv6.conf.default.forwarding = 1 |
10 |
net.ipv6.conf.default.proxy_ndp = 1 |
11 |
net.ipv6.conf.all.proxy_ndp = 1 |
13 |
net.ipv6.conf.default.autoconf = 0 |
14 |
net.ipv6.conf.all.autoconf = 0 |
L’activation du forwarding IPv4 n’est nécessaire que si vos VPS sont susceptibles d’utiliser des adresses IP privées (le NAT devant être réalisé par un firewall). Le forwarding IPv6 est quant à lui obligatoire. Les deux dernièrs paramètres permettent de désactiver l’auto-configuration IPv6 des interfaces réseaux, ce qui sera répercuté dans les serveurs virtuels. Ceci n’est pas obligatoire, mais sécurise le tout en rendant obligatoire une configuration statique.
La création d’un CT en mode veth est simple, il suffit d’omettre la configuration réseau au moment de sa création :
root@HN:/# vzctl create 101 --ostemplate debian-6.0-standard_6.0-2_amd64 |
Par contre, il faut créer les interfaces réseaux par la suite :
root@HN:/# vzctl set 101 --netif_add eth0 --save |
root@HN:/# vzctl set 101 --netif_add eth1 --save |
Ici, j’ai créé la première interface pour son IPv6 et la seconde pour son IPv4. Le serveur virtuel peut maintenant être démarré :
01 |
Starting container ... |
03 |
Setting CPU units: 1000 |
05 |
Set hostname: vps101.interact.lu |
06 |
File resolv.conf was modified |
07 |
Setting quota ugidlimit: 0 |
08 |
Configure veth devices: veth101.0 veth101.1 |
09 |
Adding interface veth101.0 to bridge vmbr0 on CT0 for CT101 |
10 |
Adding interface veth101.1 to bridge vmbr0 on CT0 for CT101 |
11 |
Container start in progress... |
OpenVZ a donc créé les interfaces veth101.0 (mappée sur eth0) et veth101.1 (mappée sur eth1), tout en les ajoutant à notre bridge vmbr0.
root@HN:/# vzctl enter 101 |
Avant de configuer les interfaces réseaux côté CT, il faut désactiver le forwarding :
root@HN:/# vzctl enter 101 |
root@CT:/# more /etc/sysctl.conf |
1 |
net.ipv4.ip_forward = 0 |
2 |
net.ipv6.conf.all.forwarding = 0 |
3 |
net.ipv6.conf.all.mc_forwarding = 0 |
Au niveau de la configuration réseau dans le CT, rien de spécial à spécifier mais il faut forcer les routes par défaut. En IPv6, la route par défaut n’est pas appliquée par l’option gateway (peut être une subtilité Debian, rien de dramatique).J’ai donc recours aux options up :
root@CT:/# more /etc/network/interfaces |
02 |
iface lo inet loopback |
05 |
iface eth0 inet6 static |
06 |
address 2001:1234:5678::3 |
08 |
up /sbin/ip -6 route add default via 2001:1234:5678::1 |
10 |
iface eth1 inet static |
12 |
netmask 255.255.255.224 |
13 |
up /sbin/ip route add default via 81.23.45.225 |
Reste à appliquer la nouvelle configuration :
root@CT:/# /etc/init.d/networking restart |
Running /etc/init.d/networking restart is deprecated because it may not enable again some interfaces ... (warning). |
Reconfiguring network interfaces...done. |
Puis à vérifier l’accès réseau :
eth0 Link encap:Ethernet HWaddr 1a:a5:96:8c:72:91 |
inet6 addr: fe80::18a5:96ff:fe8c:7291/64 Scope:Link |
inet6 addr: 2001:1234:5678::3/48 Scope:Global |
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 |
RX packets:68106 errors:0 dropped:0 overruns:0 frame:0 |
TX packets:33712 errors:0 dropped:0 overruns:0 carrier:0 |
collisions:0 txqueuelen:0 |
RX bytes:98987770 (94.4 MiB) TX bytes:2480372 (2.3 MiB) |
eth1 Link encap:Ethernet HWaddr 00:18:51:e2:0e:f8 |
inet addr:81.23.45.227 Bcast:81.23.45.255 Mask:255.255.255.224 |
inet6 addr: fe80::218:51ff:fee2:ef8/64 Scope:Link |
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 |
RX packets:2194 errors:0 dropped:0 overruns:0 frame:0 |
TX packets:74 errors:0 dropped:0 overruns:0 carrier:0 |
collisions:0 txqueuelen:0 |
RX bytes:101387 (99.0 KiB) TX bytes:2743 (2.6 KiB) |
lo Link encap:Local Loopback |
inet addr:127.0.0.1 Mask:255.0.0.0 |
inet6 addr: ::1/128 Scope:Host |
UP LOOPBACK RUNNING MTU:16436 Metric:1 |
RX packets:0 errors:0 dropped:0 overruns:0 frame:0 |
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 |
collisions:0 txqueuelen:0 |
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) |
root@CT:/# ping6 -c4 2001:1234:5678::1 |
PING 2001:1234:5678::1(2001:1234:5678::1) 56 data bytes |
64 bytes from 2001:1234:5678::1: icmp_seq=1 ttl=64 time=0.460 ms |
64 bytes from 2001:1234:5678::1: icmp_seq=2 ttl=64 time=0.445 ms |
64 bytes from 2001:1234:5678::1: icmp_seq=3 ttl=64 time=0.422 ms |
64 bytes from 2001:1234:5678::1: icmp_seq=4 ttl=64 time=0.420 ms |
--- 2001:1610:4::1 ping statistics --- |
4 packets transmitted, 4 received, 0% packet loss, time 2998ms |
rtt min/avg/max/mdev = 0.420/0.436/0.460/0.030 ms |
Reste ensuite à sécuriser le tout en faisant votre parefeu iptables, mais ceci sera l’objet d’un article à venir.
