Kvm: probleme reseau

Support Debian
#1

Bonjour à tous,

je posséde un serveur debian wheezy chez Kimsufi qui fait de la virtualisation sous kvm pour fournir des services gratuit, ce serveur était géré par un technicien.
Mais depuis je n’ai plus de nouvelle de cette personne, j’ai décidé de géré le serveur moi même, mais étant un néophyte sur Linux, j’ai décidé de faire un environnement fermer sur une de mes machines pour ne pas démonter ce que la personne avais déjà établi. Donc j’ai recopié la configuration réseau qui étais sur le serveur sur ma machine en modifiant les adresses ip mais pourtant mes vm n’arrivent pas aller sur Internet.

config réseau du serveur Kimsufi:

The loopback network interface

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 91.121.139.218
netmask 255.255.255.0
network 91.121.139.0
broadcast 91.121.139.255
gateway 91.121.139.254

auto br1
iface br1 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
bridge_stp off
bridge_fd 0
pre-up brctl addbr br1
post-down brctl delbr br1

iface eth0 inet6 static
address 2001:41D0:1:BAda::1
netmask 128
post-up /sbin/ip -f inet6 route add 2001:41D0:1:BAff:ff:ff:ff:ff dev eth0
post-up /sbin/ip -f inet6 route add default via 2001:41D0:1:BAff:ff:ff:ff:ff
pre-down /sbin/ip -f inet6 route del default via 2001:41D0:1:BAff:ff:ff:ff:ff
pre-down /sbin/ip -f inet6 route del 2001:41D0:1:BAff:ff:ff:ff:ff dev eth0

config réseau de mon environnement fermer:

The loopback network interface

auto lo
iface lo inet loopback

The primary network interface

allow-hotplug eth0
auto eth0
iface eth0 inet static
address 192.168.0.2
netmask 255.255.255.0
gateway 192.168.0.1
network 192.168.0.0

auto br1
iface br1 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
bridge_stp off
bridge_fd 0
pre-up brctl addbr br1
post-down brctl delbr br1

Apres diverses passages sur diverses doc, j’ai appris qu’il fallait activer l’ip_forward ce qui a été fait et ai aussi ajouter une règle iptables

règle iptables:
iptables -t nat -A POSTROUTING -s 192.168.1.11/32 -j MASQUERADE --proto tcp --sport 1024:65535 --dport 80

malgré c’est diverses configs, ma vm n’arrive toujours pas a sortir, est ce que quelqu’un pourrai m’aider a ce niveau la.

#2

Ah le bridge sur Linux c’est pénible…
Fais un brctl show pour voir s’il est bien monté ?
Tu peux essayer aussi ça au niveau iptables :

#3

voila, j’ai apporté les modifications apportées mais sans succes.
voici les resultats au niveau de la table de routage et du bridge:

brctl show du serveur kimsufi:
bridge name bridge id STP enabled interfaces
br1 8000.fe54001a4e24 no vnet0
vnet1
vnet2
vnet3
vnet4

brctl show environnement fermer:
bridge name bridge id STP enabled interfaces
br1 8000.000000000000 no

resultat des regles sur le serveur kimsufi:

resultat avant la modification de la regle iptables:
Chain PREROUTING (policy ACCEPT)
target prot opt source destination

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE tcp – 192.168.1.11 anywhere tcp spts:1024:65535 dpt:http

resultat en ayant changer ma regle iptables:
Chain PREROUTING (policy ACCEPT)
target prot opt source destination

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all – 192.168.1.0/24 anywhere

#4

Et la virtualisation sur le KS ou sur ton environnement fermé, c’est géré comment ? Par virsh en ligne de commande ? Par virt-manager ? Via une interface web ?

–
AnonymousCoward

#5

la virtualisation est gérée en ligne de commande avec virsh

#6

Et si tu regarde la liste des réseaux configuré au niveau de virsh / la libvirt, il n’y a pas de différence flagrante avec le KS ?

[mono]virsh net-list --all[/mono]

[mono]virsh net-dumpxml nomDuReseau[/mono] pour voir les détails

–
AnonymousCoward

#7

virsh net-list all de ks:
Name State Autostart

default inactive no

resultat xml:

default
e1649498-d274-abfe-7f21-14c8daed29a1







virsh net-list all environnement fermer:
Name State Autostart Persistent

default inactive no yes

resultat xml:

default
10241a3e-4c9e-4af0-b533-a496f46df316







la seule difference est la persistence, je ne sais pas si c’est significatif

#8

On peut avoir un aperçu de la configuration des interfaces réseau pour une VM avec la commande [mono]virsh domiflist nomDuDomaine[/mono]. Par contre, ce qui est un peu dommage, il vaut mieux que la VM ne soit pas en marche : Si la VM est en marche on ne peut pas voir si une interface réseau est rattachée à un “réseau” de la libvirt.

De même, le dump XML ([mono]virsh dumpxml nomDomaine[/mono]) pour une même VM en marche et à l’arrêt donnera des informations différentes concernant la configuration des interfaces réseau.

Comparer les configurations de deux VMs censées être identiques, à l’arrêt, sur le KS et dans ton environnement de test, pourra fournir des indices intéressants.

–
AnonymousCoward

#9

[quote=“gallarian”]…
la seule difference est la persistence, je ne sais pas si c’est significatif[/quote]
Selon la documentation, un réseau non-persistant sera supprimé au prochain redémarrage du daemon de la libvirt.

Cela peut être ennuyeux mais je ne pense pas que tes problèmes viennent de là.

–
AnonymousCoward

#10

virsh dumpxml statut (running) sur ks:

tech-infor 84be15ae-7251-7299-1960-3e38ce626d9b 524288 524288 1 hvm destroy restart restart /usr/bin/kvm

virsh dumpxml statut (shutdown) sur ks:

tech-infor
84be15ae-7251-7299-1960-3e38ce626d9b
524288
524288
1

hvm








<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>

/usr/bin/kvm



























virsh domiflist statut(shutdown) sur ks:
Interface Type Source Model MAC

  •      bridge     br1        -           52:54:00:e0:74:05

virsh dumpxml statut (running) sur env. fermer:

vm1
f45bbc2c-dfd0-446f-83cc-39dcd7dd256a
524288
524288
1

/machine


hvm












<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>

/usr/bin/qemu-system-i386

























































virsh dumpxml statut (shutdown) sur env. fermer:

vm1
f45bbc2c-dfd0-446f-83cc-39dcd7dd256a
524288
524288
1

hvm












<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>

/usr/bin/qemu-system-i386









































virsh domiflist statut(shutdown) sur env fermer:
Interface Type Source Model MAC

  •      bridge     br1        rtl8139     52:54:00:b0:79:4e

Voila, n’etant pas sur de quel noeud prend dans le xml, j’ai mis toute la config de la vm

#11

Pardon pour le délai.

Manifestement, les VM sur ton KS ou dans ton environnement de dev ne sont pas rattachées au “réseau” paramétré dans la libvirt mais directement à un bridge puisque tu peux voir que le “Interface Type” indique “bridge” (et pas “network”).

Cela veut probablement dire que les VMs sur le KS sont soit :

  • Configurées avec une adresse IP statique / “en dur”. Avec l’adresse de la passerelle également en dur ETC.
  • Configurées pour utiliser du DHCP. Et qu’il y aurait un serveur DHCP à l’écoute sur l’interface du bridge, br1 . Les packages dnsmasq ou isc-dhcp-server, pour ne parler que des plus communs.

Il faut que tu regardes ce qu’il en est. Ensuite, tu pourras recopier cette configuration du KS vers ton environnement de test et voir quels seront les problèmes restants.

–
AnonymousCoward

#12

Bonjour,

oui les vm recoivent une ip statique au moment de l’installation sur le KS.
mais avant cela, j’ajoute cette regle iptables: iptables -t nat -A POSTROUTING -s 192.168.1.11/32 -j MASQUERADE --proto tcp --sport 1024:65535 --dport 80 et modifiant seulement l’ip.

Je fais la même sur mon environnement et la, la vm bloque au moment ou elle doit chercher le miroir sur le réseau

#13

Dans un environnement fermé, ça me semble plutôt normal.

Blague à part :

  • As-tu vérifié la connectivité IP de base d’une machine virtuelle (avec la machine hôte, les machines du réseau local, la passerelle de la machine hôte) avec [mono]ping[/mono] ou autre ?
  • Comment est configurée la résolution DNS ? La règle MASQUERADE que tu cites n’affecte que les connexions HTTP (TCP/80) sortantes, pas les requêtes DNS (UDP/53 et TCP/53). Si le masquerading est nécessaire pour les connexions sortantes au delà de la machine hôte, alors il faut ajouter des règles pour les requêtes DNS ou bien le serveur DNS interrogé doit être sur la machine hôte.
#14

désolé comme dit precedemment, je debutes sur linux.

voila le resultat d’un ping sur la vm a partir de l’hote:

PING 192.168.1.11 (192.168.1.11) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Destination Host Unreachable
From 192.168.1.1 icmp_seq=2 Destination Host Unreachable
From 192.168.1.1 icmp_seq=3 Destination Host Unreachable
From 192.168.1.1 icmp_seq=4 Destination Host Unreachable
From 192.168.1.1 icmp_seq=5 Destination Host Unreachable

par contre pas oublier que l’installe de la vm ne se finalise pas.

comment dois je faire pour configurer le dns sur linux, quel est le fichier qui gere se service?

#15

Hello,

Je récapitule :

  • Ton hyperviseur (env. fermé) a une adresse IP sur ton LAN qui est 192.168.0.2/24 (soit 192.168.0.2 avec un masque de sous-réseau de 255.255.255.0).
  • Ce même hyperviseur a un bridge (ou switch virtuel) sur lequel sont raccordés les machines virtuelles qui sont configurées avec des IPs en 192.168.1.X/24 . L’interface correspondant au bridge a elle-même l’IP 192.168.1.1 .
  • Pour que les VMs puissent être connectées à Internet, l’hyperviseur route les paquets entre eth0, l’interface LAN et br1, le bridge.

Après, pour avoir des communications “utiles” avec Internet, il faut que la connectivité fonctionne dans les deux sens.
Là, tes VMs arrivent à envoyer des paquets vers la box pour qu’elle les route / relaie vers Internet. Et la box les relaie (en pratique, elle ne le fait pas à cause du rp_filter). Mais les paquets en retour, où est-ce que la box les fait suivre ? La box ne connait pas le réseau 192.168.1.0/24, elle n’a pas de route vers ces IPs. Les paquets en retour sont donc perdus.

Bravo à Pascal pour avoir identifié le problème.

Pour corriger cela :

  • Soit tu fournis à la box une route vers le réseau 192.168.1.0/24 via 192.168.0.2 . Souvent c’est appelé une “route statique”, à tort.
  • Soit tu demandes à l’hyperviseur de dissimuler les adresses en 192.168.1.0/24 derrière l’IP 192.168.0.2 . C’est ce que l’on appelle le Source Network Address Translation, SNAT ou NAT tout court.

Pour activer le SNAT, sous Linux, il faut ajouter une (seule) règle au pare-feu de Linux, dans la table nat, chaîne POSTROUTING.

On affiche les règles de cette chaîne avec la commande iptables --line-numbers -nvx -t nat -L POSTROUTING . Exemple :root@machine:~# iptables --line-numbers -nvx -t nat -L POSTROUTING Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 4316 317622 SNAT all -- * eth0 0.0.0.0/0 0.0.0.0/0 to:62.210.102.xx

Pour effacer une règle dans cette chaîne, tu peux utiliser la commande iptables -t nat -D POSTROUTING 1 pour effacer la règle numéro 1.

Pour ajouter une règle effectuant du SNAT, tu peux utiliser la commande suivante : iptables -t nat -A POSTROUTING --out-interface eth0 -j SNAT --to-source 192.168.0.2 .
Le MASQUERADE sous Linux est quasi identique au SNAT mais est plus à destination des connexions sans adresse IP fixe. Je ne le détaillerais donc pas plus.

Une fois que tu auras mis en place du SNAT sur ton hyperviseur correctement (ou une route), tu devrais pouvoir ping la box qui te sert à aller sur Internet, d’adresse IP 192.168.0.1 dans ton cas.
Et si cela fonctionne, cela devrait aussi fonctionner avec un serveur sur Internet.

Pour le DNS, tu peux :

  • Soit utiliser celui qui est souvent intégré à la box, comme les éventuels autres PCs sur ton LAN.
  • Soit mettre en place un serveur DNS de type “forwarder” sur ton hyperviseur avec les packages [mono]dnsmasq[/mono] ou [mono]bind9[/mono]. Pas indispensable. Leur intérêt est d’avoir un cache et de faire tourner les serveurs DNS en amont s’ils ne sont pas toujours fiables.
  • Soit, si tu as pas mal de temps devant toi, installer un serveur DNS de type “recursive resolver” avec les packages [mono]bind9[/mono], [mono]unbound[/mono] ou [mono]pdnsd[/mono] . Ce qui te permet de te passer de serveur DNS en amont.

–
AnonymousCoward

#16

Bonjour,

Voila, j’ai ajouté la règle que vous m’aviez fourni: iptables -t nat -A POSTROUTING --out-interface eth0 -j SNAT --to-source 192.168.0.2

une fois fait, j’ai retenté l’install d’une vm et sans succès.

au niveau du message d’erreur du ping, c’est la même que mon précédent post

#17

Bonjour,

Je suppose qu’il faudrait vérifier que le routage soit autorisé. Pour cela, utiliser les commandes :

  • [mono]cat /proc/sys/net/ipv4/ip_forward[/mono] (devrait retourner 1 pour que cela fonctionne, vaut 0 par défaut sous Debian)
  • [mono]cat /proc/sys/net/ipv4/conf/eth0/forwarding[/mono] (idem)
  • [mono]cat /proc/sys/net/ipv4/conf/br1/forwarding[/mono] (idem)
    (ou en tant que root une commande telle que [mono]sysctl net.ipv4.ip_forward[/mono])
    (Chromium, chez moi affiche mal les tirets bas quand je passe du texte en police monospace, faire attention)

Si l’une des ces valeurs était à 0, tu peux la passer à 1 avec une ligne de commande comme ci-dessous :

  • [mono]sysctl -w net.ipv4.ip_forward=1[/mono]
  • [mono]echo 1 >/proc/sys/net/ipv4.ip_forward[/mono]

Et si tu souhaites que ces changements soit pérennes, il vaut mieux aller modifier le fichier [mono]/etc/sysctl.conf[/mono] pour que ceux-ci soient appliqués à nouveau lors d’un redémarrage.

Concernant la règle pour le NAT, il faut vérifier que ce soit la seule, qu’il n’y en ait pas une autre qui interfère, en affichant le contenu de la chaîne POSTROUTING.
Mais il est possible que les manipulations indiquées ci-dessus suffisent.

Un bon test pour voir si cela fonctionne, c’est un ping sur l’IP de ta box. Par exemple : [mono]ping -n -c 4 192.168.0.1[/mono] .

–
AnonymousCoward

#18

Voici les differents retour de la commande cat

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

cat /proc/sys/net/ipv4/conf/eth0/forwarding
1

cat /proc/sys/net/ipv4/conf/br1/forwarding
1

sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

résultat du ping de l’hôte vers la box:
ping -n -c 4 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=24.1 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=1.84 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=1.58 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=1.69 ms

— 192.168.0.1 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.581/7.326/24.184/9.733 ms

affichage de la table de routage POSTROUTING:

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all – anywhere anywhere to:192.168.0.2

#19

Pour toi, l’hôte, c’est celui qui héberge les machines virtuelles, n’est-ce pas ? Juste pour être certain.

Il faudrait essayer le même test dans une VM. Voir, faire un [mono]ping -n -c 4 173.194.67.94[/mono] (une des adresses de google.fr).

Si cela ne fonctionne pas, peut-être est-ce que cela viendrait d’un blocage dans le pare-feu. Pour cela, il serait pratique de voir sa configuration complète avec les commandes :

  • [mono]iptables --line-numbers -nvx -t filter -L[/mono]
  • [mono]iptables --line-numbers -nvx -t nat -L[/mono]
  • [mono]iptables --line-numbers -nvx -t mangle -L[/mono]

Et sinon, je ne vois pas.

Précisons que POSTROUTING est une chaîne dans la table nat du pare-feu. Rien à voir avec la/les table(s) de routage.

Si tu veux afficher la table de routage (principale), et ce serait un renseignement utile, il te faut taper [mono]ip -4 route show[/mono] . Les commandes ifconfig et route, c’est le mal !!

–
AnonymousCoward

#20

oui l’hote est la machine qui heberge les machines virtuelles.

Le ping a partir de la machine n’est pas disponible, car l’installation de la vm ne se finalise pas car elle demande un accès réseau pour récupérer le miroir et pas moyen de sauter l’étape.

retour des commandes proposées:

iptables --line-numbers -nvx -t filter -L
Chain INPUT (policy ACCEPT 8 packets, 592 bytes)
num pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 7 packets, 1112 bytes)
num pkts bytes target prot opt in out source destination

iptables --line-numbers -nvx -t nat -L
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination

iptables --line-numbers -nvx -t mangle -L
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination

ip -4 route show
default via 192.168.0.1 dev eth0
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.2
192.168.1.0/24 dev br1 proto kernel scope link src 192.168.1.1