7 décembre 2021

Tuto Virtualisation avec KVM, partie III : Réseau interne

Dans cette troisième partie de la série sur KVM, nous allons parler réseau.

Notre première VM étant branchée directement sur le bridge br0 d’Openvswitch, elle est dans le même réseau que l’hyperviseur.

Admettons que nous voulions aussi avoir la possibilité d’avoir des VMs dans un réseau interne à l’hyperviseur, ne disposant donc pas directement d’une « sortie » via l’eth0/br0 de ce dernier.

C’est ce que nous allons voir dans cet article.

 

I – Nouveau bridge

Tout d’abord, nous allons créer un nouveau bridge au sein d’Openvswitch.

# ovs-vsctl add-br brint

Nouveau bridge sobrement appelé brint.

 

Dans KVM, on va le définir dans un fichier back.xml :

<network>
<name>ovs-back</name>
<forward mode='bridge'/>
<bridge name='brint'/>
<virtualport type='openvswitch'/>
</network>

Puis  :

# virsh net-define back.xml
# virsh net-start ovs-back
# virsh net-autostart ovs-back

 

Sur l’hyperviseur, on va lui offrir la possibilité de communiquer sur ce bridge en passant par l’interface interne créée automatiquement.

Pour se faire :

# ip addr add 10.99.1.250 dev brint
# ip link set brint up
# ip route add 10.99.1.0/24 dev brint

II – Ajout d’une interface à la VM

Pour tester, nous allons brancher à chaud une nouvelle interface réseau à notre première VM. L’avantage de la virtualisation, car aller brancher une carte réseau sur une vrai machine qui tourne, je ne m’y risquerais pas…

Pour voir déjà l’existant :

# virsh domiflist debianmano

On lui ajoute l’interface ainsi :

# virsh attach-interface debianmano network ovs-back --model virtio --target debianmano.1 --mac 52:54:00:11:11:12 --persistent

Au passage, pour détacher, c’est :

# virsh detach-interface debianmano bridge --mac 52:54:00:11:11:12 --config

 

Si on regarde le fichier de configuration :

# virsh edit debianmano

On peut voir la section pour cette interface qui a été ajoutée :

...
<interface type='network'>
<mac address='52:54:00:11:11:12'/>
<source network='ovs-back'/>
<target dev='debianmano.1'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/>
</interface>
...

Puis dans la VM debianmano :

# virsh console debianmano

On va regarder la nouvelle interface ajoutée :

debianmano# ip a

Ici, c’est enp7s0 qui est ajoutée. Donc :

debianmano# ip addr add 10.99.1.1 dev enp7s0
debianmano# ip link set enp7s0 up
debianmano# ip route add 10.99.1.0/24 dev enp7s0

On teste un ping vers l’hyperviseur :

debianmano# ping 10.99.1.250

Et dans l’hyperviseur :

# ping 10.99.1.1

Ceci doit fonctionner sans encombres.

 

III – Réflexions

On va faire une petite pause pour voir comment utiliser au mieux tout cela.

Très souvent, dans le cas ou l’on a besoin d’isoler un réseau de VMs sur un hyperviseur, le plus simple est d’effectuer l’interconnexion des réseaux (externe et interne) au niveau de l’hyperviseur. Typiquement ce qui est utilisé avec les hyperviseurs de type II si on ne cherche pas à complexifier.

Ici, on pourrait le faire en autorisant le forward IP sur l’hyperviseur, plus le lien sur le bridge interne crée auparavant, les régles de NAT…

Coté VM, on les connecterait au brint, en déclarant l’adresse IP de l’hyperviseur sur ce bridge en gateway.

Ok, cela fonctionne….

…mais je n’aime pas.

Quand je virtualise, je veux que l’hyperviseur ne fasse que cela.

Pour le routage vers le réseau interne des VMS, j’utilise une VM spécifique avec un lien sur le br0 (et donc une IP « externe ») et un lien sur le brint. C’est elle qui s’occupera du forward, du nat, etc…

L’hyperviseur garde son IP « principale » uniquement pour l’administration. Et il garde aussi le contact avec les VM mais uniquement pour de la gestion.

 

IV – Debianmano en  Routeur

Ce qu’on va faire pour tester, c’est transformer notre première VM en routeur :

debianmano# echo 1 > /proc/sys/net/ipv4/ip_forward

Puis

debianmano# iptables -t nat -A POSTROUTING -s 10.99.1.0/24 -j SNAT --to 192.168.1.100

Son IP « externe » étant, vous l’aurez compris 192.168.1.100

V – Nouvelle VM

On va donc maintenant faire une machine uniquement branchée sur brint :

# virt-install --name newvm \
--vcpus 1 \
--cpu host \
--ram 1024 \
--location /img/debian-10.2.0-amd64-netinst.iso \
--disk pool=kvm-lvm,size=4,bus=virtio \
--network network:ovs-back,model=virtio,target=newvm.0 \
--graphics none \
--console pty,target_type=serial \
--extra-args='console=ttyS0' \
--os-variant debian10

On fait l’installation avec pour le réseau, une IP du genre 10.99.1.2, Gateway 10.99.1.1 (la première VM).

Une fois l’installation effectuée et la VM démarrée :

#virsh console newvm

On doit pouvoir pinguer debianmano :

newvm# ping 10.99.1.1

Également l’hyper (qui est encore présent sur le même réseau) :

newvm# ping 10.99.1.250

Par contre, la route passe bien par la premiere VM  :

newvm# ip route

renvoie :

default via 10.99.1.1 dev enp1s0 onlink
10.99.1.0/24 dev enp1s0 proto kernel scope link src 10.99.1.2

Depuis debianmano et l’hyperviseur, on doit également pouvoir pinguer newvm sur son IP 10.99.1.2.

 

VI – Conclusion

Le réseau interne est fonctionnel, nous avons la seconde VM qui communique avec l’extérieur par le biais de la VM routeur. L’hyperviseur ne gère en rien le routage.

C’est bien, mais pas top, car j’aime utiliser les VLANs et nous allons voir justement comment les intégrer dans l’article suivant.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *