[virtualisation vkm] pb de configuration du réseau [résolu]

Support Debian
#1

j’ai suivi le proto de lefinnois.net/wp/index.php/2 … uelle-kvm/ pour ma config reseau debian virtuelle et lors du lancement, j’ai :
"eth1: received packet with own address as source address
eth0: received packet with own address as source address"
et l’ensemble du réseau qui bourre.
j’ai créé un bridge br0 avec eth1 manual et tap0 manual :

[code]/etc/network/interfaces

auto lo eth0 eth1 tap0 br0

iface lo inet loopback

iface eth0 inet dhcp

iface tap10 inet manual
pre-up tunctl -b -u fab -t tap0
pre-up ifconfig tap0 up
post-down tunctl -d tap0

iface br0 inet static
bridge_ports eth1 tap0
bridge_maxwait 0
address 192.168.13.2
netmask 255.255.255.0
network 192.168.13.0
broadcast 192.168.13.255
gateway 192.168.13.1

iface eth1 inet manual[/code]

[code]ifconfig
br0 Link encap:Ethernet HWaddr 00:1c:f0:11:f9:b5
inet adr:192.168.13.2 Bcast:192.168.13.255 Masque:255.255.255.0
adr inet6: fe80::21c:f0ff:fe11:f9b5/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:140 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:9502 (9.2 KiB) TX bytes:1296 (1.2 KiB)

eth0 Link encap:Ethernet HWaddr 00:1d:7d:96:12:0a
inet adr:192.168.12.2 Bcast:192.168.12.255 Masque:255.255.255.0
adr inet6: fe80::21d:7dff:fe96:120a/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7255734 errors:0 dropped:0 overruns:0 frame:0
TX packets:7718242 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:1134320040 (1.0 GiB) TX bytes:1218088732 (1.1 GiB)
Interruption:252 Adresse de base:0x6000

eth1 Link encap:Ethernet HWaddr 00:1c:f0:11:f9:b5
adr inet6: fe80::21c:f0ff:fe11:f9b5/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:150 errors:0 dropped:0 overruns:0 frame:0
TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:12768 (12.4 KiB) TX bytes:2242 (2.1 KiB)
Interruption:18

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:16436 Metric:1
RX packets:30783 errors:0 dropped:0 overruns:0 frame:0
TX packets:30783 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:2558081 (2.4 MiB) TX bytes:2558081 (2.4 MiB)

tap0 Link encap:Ethernet HWaddr 00:ff:63:9d:04:f4
adr inet6: fe80::2ff:63ff:fe9d:4f4/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:63 errors:0 dropped:0 overruns:0 frame:0
TX packets:14862411 errors:0 dropped:447 overruns:0 carrier:0
collisions:0 lg file transmission:500
RX bytes:10360 (10.1 KiB) TX bytes:2322135110 (2.1 GiB)[/code]

voici la commande: kvm -hda /services/debian.img -m 256 -k fr -net nic -net tap,ifname=tap0 -vnc :0 &

Où est le souci?

#2

ben déjà, dans ton fichier interfaces, c’est normal que tu aies quote
iface tap10 inet manual
(…)[/quote] :question:

#3

C’est à dire que j’ai appliqué bêtement le tuto de Leffinois. Quand à savoir si c’est normal, mes compétences en bridge virtuel sont pour l’instant limitées…

#4

[quote=“mattotop”]ben déjà, dans ton fichier interfaces, c’est normal que tu aies quote
iface tap10 inet manual
(…)[/quote] :question:[/quote]
Il semblerait que ça vienne de VirtualBox.

#5

nan, ma question est purement formelle, et ce n’est pas une question de virtualbox, puisque kvm est basé sur qemu, mais:
le tuto utilise tap10, ça n’a pas d’importance et j’aurais personnellement utilisé tap0, mais aprés, le tuto utilise bien ifname=tap10 partout, or maufab, toi, tu utilises tap0.
Pas besoin de savoir ce qu’on fait pour s’en apercevoir.

#6

J’ai résolu mon pb de bourrage réseau en configurant dans le guest eth0 en statique et sur une autre ip que celle de br0 de l’hôte. Par contre, concernant tap0, j’ai commis une erreur: c’est bien tap0 qu’il faut mettre partout.
Cependant, si je peux pinguer depuis la station virtuelle sur la passerelle dans les réseaux 192.168.12.0 et 192.168.13.0, et bien sûr sur les interfaces eth0 et bro de l’hôte, par contre je ne sors pas sur les autres machines du réseau, ni sur la livebox, et encore moins sur le net.

route Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.13.0 * 255.255.255.0 U 0 0 0 eth0 192.168.12.0 192.168.13.1 255.255.255.0 UG 0 0 0 eth0 default 192.168.13.1 0.0.0.0 UG 0 0 0 eth0

Mais je peux pinguer depuis les autres machines du réseau sur la station virtuelle et m’y connecter en ssh.
Pour vnc, je peux me connecter, mais sur 192.168.12.2 (br0 de l’hôte??). Est-ce normal?
Peut-être dois-je faire un NAT depuis l’hôte pour sortir sur le réseau et internet?

#7

Evidemment il faut des adresses différentes pour chaque machine puisqu’une adresse sert à identifier une machine.
Qu’entends-tu exactement par “bourrage réseau” ?

[quote]Cependant, si je peux pinguer depuis la station virtuelle sur la passerelle dans les réseaux 192.168.12.0 et 192.168.13.0, et bien sûr sur les interfaces eth0 et bro de l’hôte, par contre je ne sors pas sur les autres machines du réseau, ni sur la livebox, et encore moins sur le net.route Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.13.0 * 255.255.255.0 U 0 0 0 eth0 192.168.12.0 192.168.13.1 255.255.255.0 UG 0 0 0 eth0 default 192.168.13.1 0.0.0.0 UG 0 0 0 eth0[/quote]
A quoi sert la route vers 192.168.12.0/24 ? Cette destination n’est-elle pas déjà couverte par la route par défaut ?
Edit : à quoi correspond la passerelle 192.168.13.1 ?

[quote]Mais je peux pinguer depuis les autres machines du réseau sur la station virtuelle et m’y connecter en ssh.
Pour vnc, je peux me connecter, mais sur 192.168.12.2 (br0 de l’hôte??). Est-ce normal?[/quote]
Si j’ai bien suivi, 192.168.12.2 est l’adresse de eth0 de l’hôte, donc là tu te connectes à l’hôte, pas l’invité. Et oui, c’est étonnant que tu puisses pinguer dans un sens et pas dans l’autre.
Comment sont réglées les routes sur les autres machines et la box ? Le forwarding (fonction routeur) est-il activé sur l’hôte ? A-t-il des règles iptables ?

Ce sera peut-être nécessaire pour l’accès à internet.

Questions subsidiaires :

  • À quoi correspond l’option “gateway 192.168.13.1” dans la configuration de br0 ? J’éviterais de déclarer une passerelle par défaut sur br0, elle entrerait en conflit avec la route par défaut de eth0.
  • À quoi est rattachée eth1 de l’hôte, qui est pontée avec tap0 ?
#8

Par bourrage, j’entends un envoi de paquets conséquent sur le réseau qui ralentissait les machines (imprimante réseau surtout).

[A quoi sert la route vers 192.168.12.0/24 ? Cette destination n’est-elle pas déjà couverte par la route par défaut ?]
C’est un essai, comme je n’arrive pas à sortir…

[à quoi correspond la passerelle 192.168.13.1 ?]
c’est la 2nde carte réseau de la passerelle (ipcop) configurée en DMZ (pour l’instant j’ai permis le passage depuis 192.168.13.0 sur tous les ports du réseau vert:192.168.12.0 en tcp et udp).

[Comment sont réglées les routes sur les autres machines et la box ? Le forwarding (fonction routeur) est-il activé sur l’hôte ? A-t-il des règles iptables ?]

Pour l’hôte:

Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.13.0 * 255.255.255.0 U 0 0 0 br0 192.168.12.0 * 255.255.255.0 U 0 0 0 eth0 default 192.168.13.1 0.0.0.0 UG 0 0 0 br0 default 192.168.12.1 0.0.0.0 UG 0 0 0 eth0

Pour ipcop:

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 0 0 0 eth1 192.168.13.0 * 255.255.255.0 U 0 0 0 eth2 192.168.12.0 * 255.255.255.0 U 0 0 0 eth0 default 192.168.1.1 0.0.0.0 UG 0 0 0 eth1

Pour une machine quelconque:

Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.12.0 * 255.255.255.0 U 0 0 0 eth0 default ipcop 0.0.0.0 UG 0 0 0 eth0

Non, je n’ai rien configuré sur l’hôte concernant iptables et le forwarding. Pour la livebox (192.168.1.1), je n’ai rien touché pour le routage, et ai tout ouvert vers ipcop.

#9

Dis-donc, il n’est pas tout simple ton réseau ! Tu aurais pu commencer par le décrire.
Tu n’as pas répondu à ma question : à quoi est rattachée eth1 de l’hôte ? Je suppose qu’elle est connectée à eth2 de l’IPcop ? Dans ce cas tu n’as pas besoin de configurer l’hôte en routeur si l’IPcop joue ce rôle, ni de créer des routes spécifiques.

Et l’ICMP, pour le ping ? Tu as aussi autorisé le trafic dans l’autre sens ? Pour l’accès internet, il faudra aussi autoriser les connexions de 192.168.13.0 vers la box.

#10

normalement, ipcop est configurer par defaut pour autoriser le traffic de vert vers orange et d’orange vers red.
A l’installation d’IPCOP, sans ajout de addons, sans modification du système, les flux sont gérés de la manière suivante :
Connexions en provenance de => à destination de
RED => IPCOP : fermé*
RED => GREEN : fermé*
RED => ORANGE : fermé*
RED => BLUE : fermé*

ORANGE => IPCOP : fermé**
ORANGE => GREEN : fermé***
ORANGE => BLUE : fermé***
ORANGE => RED : ouvert**

GREEN => IPCOP : ouvert**
GREEN => ORANGE : ouvert**
GREEN => BLUE : ouvert**
GREEN => RED : ouvert**

Effectivement, eth1 de l’hôte est rattachée à eth2 d’ipcop (enfin tous les câbles passent par le même switch).

#11

j’ai compris pourquoi j’avais un bourrage sur les interfaces réseau: il fallait que je rajoute l’option script=no à la commande de kvm, sinon br0 comprenais eth1, tap0 [i]ET eth0[/i]. Toujours pas de ping vers le réseau vert, par contre.

#12

Je mérite un bon coup de pied au c… pour ne pas avoir pensé à tester le réseau avec un wget ou links : ça fonctionne. Et effectivement ipcop ne laissait pas passer ICMP. Et je peux aussi me connecter par SSH; donc tout celà est résolu. Merci pour votre aide.

#13

Pour ajouter une précision: j’ai lu quelque part que qemu ne supportait pas le protocole iCMP.

#14

Je ne connais pas particulièrement qemu, mais si ça émule une interface ethernet je ne vois pas en quoi ICMP ou n’importe quel autre protocole aurait droit à un traitement spécial. D’autant plus qu’ICMP, ce n’est pas seulement le ping, c’est une part indissociable d’IP ; IP sans ICMP, ça risque de marcher beaucoup moins bien.