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

Sebastien Caps s.caps at dsx-networks.com
Mer 14 Aou 13:07:14 CEST 2019


A devenir dingue cette histoire :)

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/


Plus d'informations sur la liste de diffusion FRsAG