[FRsAG] [SOLVED] Problème d'isolation réseau et système sous Linux - OVS - Qemu

Florent Nolot fnolot at gmail.com
Mer 14 Aou 14:31:33 CEST 2019


Le 14/08/2019 à 13:07, Sebastien Caps via FRsAG a écrit :
> A devenir dingue cette histoire :)

je deviens effectivement dingue depuis plusieurs jours. J'ai même fait 
des montages plus complexe en couplant namespace, veth, bridge et OVS 
mais toujours le même résultat.

Je viens de trouver le problème. Cela provient des options de lancement 
de mes VM qemu

Je faisais :
qemu-system-x86_64 -machine accel=kvm:tcg -cpu host -m 256 -hda 
alpine-lab1.img -net nic,macaddr=52:54:00:12:12:02 -net 
tap,script=no,ifname=lab1vm1 -vnc :1 -name lab1vm1 -localtime --daemonize


Maintenant, j'ai modifié pour respecter les nouvelles options :
qemu-system-x86_64 -machine accel=kvm:tcg -cpu host -m 256 -hda 
alpine-lab1.img -device e1000,netdev=mynet3,mac=52:54:00:12:12:02 
-netdev tap,script=no,ifname=lab1vm1,id=mynet3 -vnc :1 -name lab1vm2 
-localtime --daemonize


La modification de
-net nic,macaddr=52:54:00:12:12:02 -net tap,script=no,ifname=lab1vm1
en
-device e1000,netdev=mynet3,mac=52:54:00:12:12:02 -netdev 
tap,script=no,ifname=lab1vm1,id=mynet3
résout le problème.

Pourquoi, j'en ai aucune idée. Si quelqu'un sait, cela m'intéresse. Pour 
info, QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.15)

>
> Possible de nous faire voir "ovs-vsctl show" ?
>
> Seb
>
> Le 14-08-2019 12:22, Florent Nolot a écrit :
>> au démarrage de la maquette, sur VM1, VM2 et VM3
>>
>> ip neigh | arp -a -> vide
>>
>> donc normal, je viens de démarrer les VM
>>
>> Je stoppe de suite VM2 (poweroff) le ping depuis VM1 -> VM3 ne marche 
>> pas
>>
>> En faisant un poweroff de la VM2, cela détruit les tap sur l'host
>> (lab1dhcp lab1dhcpadm) donc pour simuler l'existance de la VM, je
>> refais un
>>
>> ip tuntap add lab1dhcp mode tap; ip link set up dev lab1dhcp
>> ip tuntap add lab1dhcpadm mode tap; ip link set up dev lab1dhcpadm
>> Le ping ne marche pas.
>>
>> Je lance VM2 et le ping se met à marcher.
>>
>> VM1 : ip neigh | arp -a -> MAC de VM3
>> VM2 : ip neigh | arp -a -> vide
>> VM3 : ip neigh | arp -a -> MAC VM1
>>
>> Si je shut eth0 et eth1 de VM2, le ping continue à marcher.
>>
>> Je flush la table arp de VM1 et VM2. Le arp -an et le ip neigh | arp
>> -an sont vide sur VM1 et VM3 MAIS le ping marche !
>>
>> C'est donc bien sur le host qu'il se passe quelque chose !
>>
>> Sur le host, iptables -F et iptables -F -t nat, ebtables (qui n'a pas
>> d'impact sur les OVS il me semble) vide, politique par defaut accept
>>
>>
>> Le 14/08/2019 à 11:47, Sebastien Caps via FRsAG a écrit :
>>> Bonjour,
>>>
>>> Justement au niveau 2 tu as quoi dans ta table ARP quand la VM est 
>>> éteinte ?
>>> ip neigh / arp -a
>>>
>>> Seb
>>>
>>> Le 14-08-2019 11:42, Florent Nolot a écrit :
>>>> Bonjour
>>>>
>>>> justement, je n'ai pas de routage en place, pas de proxy arp et les
>>>> trames de broadcast atteigne VM3 depuis VM1
>>>>
>>>> Sur mon host :
>>>>
>>>> toto at ubuntu:~$ ip route show
>>>>  default via 10.22.9.254 dev ens160 onlink
>>>>  10.22.9.0/24 dev ens160 proto kernel scope link src 10.22.9.75
>>>>
>>>> net.ipv4.ip_forward = 0
>>>>  net.ipv4.conf.all.proxy_arp = 0
>>>>
>>>> Sur les VM, je n'ai pas de route par défaut. Chaque VM est lancé
>>>> ainsi
>>>>
>>>> qemu-system-x86_64 -machine accel=kvm:tcg -cpu host -m 256 -hda
>>>> alpine-lab1.img -net nic,macaddr=52:54:00:12:12:02 -net
>>>> tap,script=no,ifname=lab1vm1 -vnc :2 -name lab1vm1 -localtime
>>>> --daemonize
>>>>
>>>> Ce que je n'explique pas, si je down eth0 eth1 de la VM2, les ping
>>>> continue à marcher ! VM2 ne fait donc pas le routage. Visiblement,
>>>> c'est le kernel du host qui relai les paquets. Mais pourquoi les tag
>>>> vlan ne jouent pas leur rôle ?
>>>>
>>>> Cordialement
>>>>
>>>> Le 14/08/2019 à 04:44, VALOIS, Pascal a écrit :
>>>>
>>>>> bonjour,
>>>>>
>>>>> Dans ton cas, je pense que tes vm1 2 et 3 ont chacune une route par
>>>>> défaut positionnée, et que l'équipement qui assure leur routage
>>>>> fait le lien entre les deux vlans.
>>>>>
>>>>> en gros, au niveau 2 tu est bien isolé, mais comme tu es dans un
>>>>> contexte de ping et de routage ip, et non plus d'une transation pure
>>>>> ethernet (niveau 2), ben tu as un chemin qui existe entre des vms.
>>>>>
>>>>> A ce niveau la, il faut ajouter des ACLS sur ton équipement de
>>>>> routage, pour filtrer le niveau 3 (comme le ferai un firewall)
>>>>>
>>>>> Cordialement.
>>>>>
>>>>> Le 13/08/2019 à 23:23, Florent Nolot a écrit :
>>>>>
>>>>>> Bonjour
>>>>>>
>>>>>> J'ai un problème d'isolation entre des VM connectés à un
>>>>>> OpenVSwitch et utilisant des VLAN. Les vlan ne jouent pas leur
>>>>>> rôle de cloisement. Je copie ci-dessous le post stackoverflow que
>>>>>> j'ai effectué, resté sans réponse à ce jour.
>>>>>>
>>>>>> I have 3 VM (qemu with tap interface), 2 on vlan 10 and 1 on vlan
>>>>>> 66 on the same lab1 OpenVSwitch. The first VM is connected via a
>>>>>> tap interface on port lab1vm1. The second has 2 network interfaces
>>>>>> connected on port lab1dhcp and lab1dhcpmaster and the third VM on
>>>>>> port dhcpmaster.
>>>>>>
>>>>>> ------------- ----------------------- --------------
>>>>>> | VM 1 | | VM2 | | VM3 |
>>>>>> |10.10.10.3 | |10.8.6.1 10.10.10.13| | 10.10.10.2 |
>>>>>> ------------- ----------------------- --------------
>>>>>> | | | |
>>>>>> | | | |
>>>>>> ------------------------------------------------------------------
>>>>>> |lab1vm1 lab1dhcp lab1dhcpadm dhcpmaster OVS lab1|
>>>>>> |tag 10 tag 10 tag 66 tag 66 |
>>>>>> ------------------------------------------------------------------
>>>>>>
>>>>>> The OpenVSwitch is configured as follow :
>>>>>>
>>>>>> Bridge "lab1"
>>>>>> Port "lab1vm1"
>>>>>> tag: 10
>>>>>> Interface "lab1vm1"
>>>>>> Port "lab1"
>>>>>> tag: 10
>>>>>> Interface "lab1"
>>>>>> type: internal
>>>>>> Port "lab1dhcp"
>>>>>> tag: 10
>>>>>> Interface "lab1dhcp"
>>>>>> Port "lab1dhcpadm"
>>>>>> tag: 66
>>>>>> Interface "lab1dhcpadm"
>>>>>> Port dhcpmaster
>>>>>> tag: 66
>>>>>> Interface dhcpmaster
>>>>>> ovs_version: "2.9.2"
>>>>>>
>>>>>> The problem: VM1 can ping VM3!
>>>>>>
>>>>>> * If I power off VM2 or shutdown lab1dhcp or lab1dhcpadm
>>>>>> interface, the ping doesn't work.
>>>>>> * If I shutdown the two network interfaces of VM2, ping works !
>>>>>>
>>>>>> Why VM2 relay ICMP packet from VM1 to VM3 ? The broadcast send by
>>>>>> VM1 reach also VM3 ! for example, if I ask an address from dhcp
>>>>>> client on VM1, VM3 receive the dhcp discover.
>>>>>>
>>>>>> Merci pour votre aide.
>>>>>>
>>>>>> Florent
>>>>>>
>>>>>> _______________________________________________
>>>>>> Liste de diffusion du FRsAG
>>>>>> http://www.frsag.org/ [1]
>>>>
>>>>
>>>> Links:
>>>> ------
>>>> [1] http://www.frsag.org/
>>>>
>>>> _______________________________________________
>>>> Liste de diffusion du FRsAG
>>>> http://www.frsag.org/
>>> _______________________________________________
>>> Liste de diffusion du FRsAG
>>> http://www.frsag.org/
> _______________________________________________
> Liste de diffusion du FRsAG
> http://www.frsag.org/


Plus d'informations sur la liste de diffusion FRsAG