Permettre un accès à Internet à vos VE sous OpenVZ

No brain, no access

Sous OpenVZ, le partage de l'accès à Internet est simple.
Si vos VE n'accèdent pas à Internet, votre HN - Hardware Node - qui héberge vos VE est mal configuré.

Cet article vous présente les différentes étapes de contrôles et de réglages permettant à vos VE d'accéder à Internet via votre serveur OpenVZ.

Support de l'IP forwarding

Le HN soit supporté l'IP forwarding. Vérifiez celà en exécutant la commande :

# cat /proc/sys/net/ipv4/ip_forward 1

1 indique que l'IP forwarding est actif, 0 qu'il ne l'est pas.

Pour changer cette valeur, modifiez le fichier /etc/sysctl.conf en ajoutant les lignes :

net.ipv4.conf.default.forwarding=1 net.ipv4.conf.all.forwarding=1

Puis exécutez la commande :

# sysctl -p

et vérifiez la valeur de /proc/sys/net/ipv4/ip_forward

iptables DROP les paquets de vos VE

Si vous avez sécurisé votre HN avec le firewall iptables, assurez-vous que les paquets en FORWARD ne sont pas en mode DROP. Listez les règles :

# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination

Chain FORWARD (policy ACCEPT) target prot opt source destination
DROP all -- anywhere 255.255.255.255

Chain OUTPUT (policy ACCEPT) target prot opt source destination

Dans cet exemple, tous les paquets reçus pour transfert sont effacés.
Les règles iptables peuvent être complexes. Pour la mise au point de l'accès Internet, je vous suggère de les désactiver temporairement.

VE qui ont une IP publique accède à Internet mais pas les autres

Si vous constatez que vos VE qui ont une IP publique accèdent à Internet alors que celle qui n'ont qu'une adresse locale n'y accède pas, il est fort probable que la machine physique qui les héberge n'assure pas le routage SNAT des paquets.

Pour vérifier cette hypothèse, exécutez les commandes simultanément sur votre HN et votre VE qui ne possède qu'une adresse locale comme 192.168.0.120.

Sur votre HN, exécutez la commande :

# tcpdump host 192.168.0.120 06:57:34.295488 IP 192.168.0.120 > cdns.ovh.net: ICMP echo request, id 22273, seq 1, length 64 06:57:35.294654 IP 192.168.0.120 > cdns.ovh.net: ICMP echo request, id 22273, seq 2, length 64 06:57:36.294576 IP 192.168.0.120 > cdns.ovh.net: ICMP echo request, id 22273, seq 3, length 64 06:57:37.294630 IP 192.168.0.120 > cdns.ovh.net: ICMP echo request, id 22273, seq 4, length 64 06:57:38.294606 IP 192.168.0.120 > cdns.ovh.net: ICMP echo request, id 22273, seq 5, length 64 06:57:39.294652 IP 192.168.0.120 > cdns.ovh.net: ICMP echo request, id 22273, seq 6, length 64 06:57:40.294578 IP 192.168.0.120 > cdns.ovh.net: ICMP echo request, id 22273, seq 7, length 64 06:57:41.294587 IP 192.168.0.120 > cdns.ovh.net: ICMP echo request, id 22273, seq 8, length 64 06:57:42.294577 IP 192.168.0.120 > cdns.ovh.net: ICMP echo request, id 22273, seq 9, length 64

Sur votre VE :

120:/# ping 173.194.36.104 PING 173.194.36.104 (173.194.36.104) 56(84) bytes of data.

--- 173.194.36.104 ping statistics --- 180 packets transmitted, 0 received, 100% packet loss, time 16999ms

Dans l'exemple, nous voyons sur le HN les requêtes ping - ICMP - partir vers le DNS d'OVH mais nous ne voyons pas les retours. Donc, le HN les filtre.

La solution pour pour donner accès à Internet aux conteneurs qui n'ont qu'une IP interne est de configurer le HN pour qu'il supporte l'IP masquerading ou SNAT (Source Network Address Translation).
La commande pour activer le SNAT sur le HN est la suivante :

# iptables -t nat -A POSTROUTING -s src_net -o eth0 -j SNAT --to ip_address

où src_net est la plage d'IP des conteneurs à gérer en SNAT et ip_address l'adresse IP externe de votre Hardware Node.

Pour connaitre l'interface qui assure la communication vers Internet sur le HN, exécutez la commande :

# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.120 * 255.255.255.255 UH 0 0 0 venet0 192.168.0.250 * 255.255.255.255 UH 0 0 0 venet0 192.168.0.202 * 255.255.255.255 UH 0 0 0 venet0 192.168.0.111 * 255.255.255.255 UH 0 0 0 venet0 192.168.0.6 * 255.255.255.255 UH 0 0 0 venet0 192.168.0.101 * 255.255.255.255 UH 0 0 0 venet0 91.121.164.0 * 255.255.255.0 U 0 0 0 vmbr0 default rbx-51-m0.fr.eu 0.0.0.0 UG 0 0 0 vmbr0

Dans cet exemple, la gateway vers Internet est gérée par l'interface vmbr0.

Déterminez l'IP publique de cette interface :

root@ns399999:~# ifconfig vmbr0 vmbr0 Link encap:Ethernet HWaddr 00:1c:c0:e3::
inet addr:91.121.1.1 Bcast:91.121.1.255 Mask:255.255.255.0 inet6 addr: fe80::21c:c0ff:fee3:6e81/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3209933 errors:0 dropped:0 overruns:0 frame:0 TX packets:1643605 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3529407709 (3.2 GiB) TX bytes:358546110 (341.9 MiB)

L'IP est 91.121.1.1

La commande finale dans cet exemple est donc :

# iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o vmbr0 -j SNAT --to 91.121.1.1

Relancez un ping depuis votre VE :

120:/# ping 173.194.36.104 PING 173.194.36.104 (173.194.36.104) 56(84) bytes of data. 64 bytes from 173.194.36.104: icmp_seq=3 ttl=57 time=4.44 ms 64 bytes from 173.194.36.104: icmp_seq=11 ttl=57 time=4.44 ms 64 bytes from 173.194.36.104: icmp_seq=13 ttl=57 time=4.46 ms 64 bytes from 173.194.36.104: icmp_seq=14 ttl=57 time=4.45 ms 64 bytes from 173.194.36.104: icmp_seq=15 ttl=57 time=4.46 ms

Votre VE accède à Internet.

Host non résolu

Si le ping d'une adresse IP publique fonctionne mais la résolution du nom de domaine échoue, vous devez modifier le nameserver du VE dans le fichier /etc/resolv.conf.

# vzctl exec 120 ping google.fr ping: unknown host google.fr

Choisissez un serveur DNS publique, par exemple celui de Google 8.8.8.8, celui d'OVH 213.186.33.99, ceux d'OpenDNS...
Changez le serveur de noms de votre VE, redémarrez et testez :

# vzctl set 120 --nameserver 8.8.8.8 --save # vzctl restart 120 # vzctl exec 120 ping google.fr PING google.fr (173.194.36.104) 56(84) bytes of data. 64 bytes from lhr14s01-in-f104.1e100.net (173.194.36.104): icmp_seq=1 ttl=57 time=4.49 ms