par EDIT 2018 : Retrouvez cette série de tuto dans une grosse mise à jour ici : Xen et OpenVswitch sont dans une Debian 9 – V.2018
Troisième partie du tutoriel sur la virtualisation « Xen et OpenVswitch sont dans une Debian« .
Dans la première partie, nous avons mis en place Xen, puis dans la seconde, Openvswitch dans lequel nous avons créé deux switchs virtuels :
- br0 sur lequel sont branchés les machines qui doivent sortir (en l’occurence, le dom0 et la vm routeur)
- brint qui est le switch de communication entre les vms. Celui ci disposant de plusieurs vlans.
Nous allons maintenant créer trois machines :
- le routeur
- l’IDS
- une machine avec un serveur web (nommée proxy car on s’en servira par la suite)
Niveau réseau, nous allons faire en sorte qu’elles communiquent comme il faut. La sécurisation de tout cela viendra plus tard.
Cette partie du tutoriel est assez conséquente car j’explique aussi quelques notions de réseaux importantes.
Préparez le café et les clopes (hou pas bien !), le cerveau va chauffer !
I – Création des Vms
A – Routeur
Cette machine sera branchée sur le bridge bro et sur le bridge interne. L’Ip coté externe sera l’Ip Failover (attribuée par Online) et coté interne : 10.2.1.2
dom0# xen-create-image --hostname routeur --role tuto --size 5G --memory 512M --swap 1G --vcpus=1 --ip=99.99.99.99
L’ip est volontairement mauvaise : on va modifier la configuration réseau.
On peut suivre la création avec :
dom0# tail -f /var/log/xen-tools/routeur.log
Une fois la vm créé, on va éditer le fichier /etc/xen/routeur.cfg.
Notez la MAC attribué a l’interface par défaut (MAX_XEN) et remplacez la partie vif par ce qui suit :
vif = [ 'vifname=routeur.0,ip=IP_FAILOVER ,mac=MAC_FAILOVER,bridge=br0',
'vifname=routeur.1,ip=10.2.1.2 ,mac=MAC_XEN,bridge=brint.2',
'vifname=routeur.2,ip=10.99.1.2 ,mac=MAC_XEN+1,bridge=brint.99']
Ici, nous déclarons trois interfaces réseaux (qui dans la vm correspondront à eth0, eth1 et eth2). Pour l’adresse MAC de la pâte routeur.1 prenez la MAC qu’a créé Xen et ajoutez lui 1 (par ex.)
La première interface est branchée sur br0 pour un accès direct au net. On la déclare avec l’IP FAILOVER fourni par Online et surtout, l’adresse MAC fournie également par Online. Lors de la commande d’une IP Failover, une fois rattachée à votre serveur dans l’interface Online, générez une adresse MAC de type XEN.
En cas de foirage ici, c’est le port réseau de votre box qui risque d’être coupé. Soyez sur de ce que vous mettez !
La seconde interface est branchée sur le bridge interne, et le port est affecté au vlan2.
La dernière interface est aussi branchée sur le bridge interne et le poste, affecté au vlan99
Maintenant, nous allons monter le disque du routeur pour modifier la configuration du réseau dans le fichier /etc/network/interfaces de la vm :
dom0# mkdir /mnt/vm dom0# mount /dev/vg0/routeur-disk /mnt/vm dom0# nano /mnt/vm/etc/network/interfaces
La, remplacez le contenu par ce qui suit :
auto lo iface lo inet loopback auto eth0 iface eth0 inet static address IPFAILOVER netmask 255.255.255.0 gateway GATEWAY ONLINE (la même que votre dédibox) auto eth1 iface eth1 inet static address 10.2.1.2 netmask 255.255.255.0 autot eth2 iface eth2 inet static address 10.99.1.2 netmask 255.255.255.0
Puis on démonte :
dom0# umount /mnt/vm
Et voila pour la première vm; on la démarrera plus tard.
B – IDS
Cette machine va inspecter le flux réseau transitant entre ses deux interfaces. Pour l’instant, on la prépare simplement, l’ids sera installé plus tard.
Pour cette partie, j’aurais pu faire autrement, je l’expliquerais dans le futur tutoriel sur les IDS (mirroring, machine en pont).
Dans notre cas, j’ai choisi d’installer une machine en sortie du routeur. Dans ce cas la, le seul fonctionnement possible est qu’elle aussi, agisse comme un routeur. Elle reçoit les paquets du réseau 10.2.1.0/24 et les forward vers le réseau 10.10.1.0/24. Et vice-versa, du réseau 10.10.1.0/24 vers le réseau 10.2.1.0/24.
dom0# xen-create-image --hostname ids --role tuto --size 10G --memory 1G --swap 1G --vcpus=1 --ip=99.99.99.99
On va modifier sa configuration réseau.
Dans le fichier /etc/xen/ids.cfg :
vif = [ 'vifname=ids.0,ip=10.2.1.3 ,mac=00:16:3E:69:9D:4A,bridge=brint.2',
'vifname=ids.1,ip=10.10.1.3 ,mac=00:16:3E:69:9D:4B,bridge=brint.10',
'vifname=ids.2,ip=10.99.1.3 ,mac=00:16:3E:69:9D:4C,bridge=brint.99']
Puis :
dom0# mkdir /mnt/vm dom0# mount /dev/vg0/ids-disk /mnt/vm dom0# nano /mnt/vm/etc/network/interfaces
La, remplacez le contenu par ce qui suit :
auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 10.2.1.3 netmask 255.255.255.0 gateway 10.2.1.2 auto eth1 iface eth1 inet static address 10.10.1.3 netmask 255.255.255.0 autot eth2 iface eth2 inet static addresse 10.99.1.3 netmask 255.255.255.0
On démonte :
dom0# umount /mnt/vm
C – Proxy
Pour les besoins du tutoriel, nous allons créer un simple serveur Web qui nous permettra de tester au final qu’un http://IP_FAILOVER pointera bien sur celle ci (une fois les régles de NAT déterminées dans le routeur.
dom0# xen-create-image --hostname proxy --role tuto --size 10G --memory 512M --swap 1G --vcpus=1 --ip=99.99.99.99
On va modifier sa configuration réseau.
Dans le fichier /etc/xen/web.cfg :
vif = [ 'vifname=proxy.0,ip=10.10.1.10 ,mac=00:16:3E:69:6F:4A,bridge=brint.10',
'vifname=proxy.1,ip=10.99.1.10 ,mac=00:16:3E:69:6F:4B,bridge=brint.99']
Puis :
dom0# mkdir /mnt/vm dom0# mount /dev/vg0/web-disk /mnt/vm dom0# nano /mnt/vm/etc/network/interfaces
La, remplacez le contenu par ce qui suit :
auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 10.10.1.10 netmask 255.255.255.0 gateway 10.10.1.3 (ici la gateway est bien l'ids, c'est par lui qu'on joint les autres réseaux) auto eth1 iface eth1 inet static address 10.99.1.10 netmask 255.255.255.0
On démonte :
dom0# umount /mnt/vm
Voila, nos trois vms sont prêtes.
II – Mise en place
On va maintenant démarrer les vms et configurer ce qu’il faut dessus pour que cela fonctionne.
Avant tout on va connecter notre Dom0 sur le vlan 99 :
dom0# ifconfig vlan99 10.99.1.1 netmask 255.255.255.0 broadcast 10.99.1.255
Cette interface va nous servir pour administrer nos domus…
Le petit hic la, c’est que rajouter la config de cette interface dans le fichier /etc/network/interface comme on aurait l’habitude de faire semble ne rien produire, elle n’est pas monté au démarrage (surement du à openvswitch, j’ai creusé, mais pas encore trouvé pourquoi)
Tant pis, solution de contournement (certe un peu crade mais cela fonctionne) : on va rajouter cela à dans un fichier /etc/init.d/debugo :
#!/bin/bash ifconfig vlan99 10.99.1.1 netmask 255.255.255.0 broadcast 10.99.1.255
Rendez le exécutable et insérez le au démarrage
dom0# chmod +x /etc/init.d/debugo
Au passage, rajoutez aussi ces deux règles dans le fichier /etc/init.d/firewall :
- Autoriser le ssh depuis le dom0 vers les domu :
iptables -t filter -A OUTPUT -d 10.99.1.0/24 -p tcp --dport 22 -j ACCEPT
- Autoriser les domu à interroger le ntp :
iptables -t filter -A INPUT -p udp --dport 123 -j ACCEPT
Puis on exécute :
dom0# /etc/init.d/firewall
A – Routeur
Il est temps de lancer la vm routeur :
dom0# cd /etc/xen dom0# xen create routeur.cfg
Et pour accéder à la console :
dom0# xen console routeur
Ou alors en un coup :
dom0# xen create routeur.cfg -c
Pour quitter la console CTRL+$ ou CTRL+^, depend de votre client SSH.
Mais si vous avez tout bien suivi, vous devriez pouvoir vous y connecter en ssh depuis l’hyperviseur :
dom0# ssh 10.99.1.2
Et la, deux solutions : vous êtes en train de tester chez vous ou sur un réseau ou l’hyperviseur et cette machine ont une IP dans le même sous réseau (par exemple, quand je maquettais chez moi, l’hyperviseur avait l’IP 192.168.0.200 et mon domu routeur, l’IP 192.168.0.201. Dans ce cas, pas de soucis, les routes seront bonnes (IP et Gateway dans le même réseau). Vous pouvez pinger l’extérieur et l’extérieur peut vous pinger;
Par contre, si vous êtes sur une dédibox avec ces fameuses IPFailover, elles sont généralement dans un tout autre réseau et la, paf, pas de routes correctes :
routeur# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.2.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 10.99.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 195.154.49.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
On va donc devoir lui dire comment joindre la gateway (qui je rappelle est la même qu’utilise le Dom0)
Dans mon cas, la gateway de ma box est 62.210.83.1
routeur# route add 62.210.83.1/32 dev eth0 routeur# route add default gw 62.210.83.1 dev eth0
Et la, on doit pouvoir pinger cette VM de l’extérieur sur son Ip publique (ici, mon Ip failover), se connecter dessus en ssh, etc..
Depuis celle ci, les pings vers l’extérieur fonctionnent également.
Par contre, si on tente de pinger une machine sur le réseau 195.154.49.0/24, cela échoue..
Il faut supprimer la route :
routeur# route del -net 195.154.49.0 netmask 255.255.255.0
Encore un truc curieux, si l’on rajoute les routes dans le fichier /etc/network/interfaces, ça ne fonctionne pas (la, je ne comprend pas, si quelqu’un voit….)
Ma solution de contournement :
Fichier /etc/init.d/debugo (en mettant la bonne gateway) :
#!/bin/bash route add 62.210.83.1/32 dev eth0 route add default gw 62.210.83.1 dev eth0 route del -net 195.154.49.0 netmask 255.255.255.0
Ensuite :
routeur# chmod +x /etc/init.d/debugo routeur# insserv debugo
Pour le moment, tout est bon.
B – IDS
On démarre la seconde machine, l’IDS.
dom0# xen create /etc/xen/ids.cfg
On doit pouvoir se connecter dessus depuis le dom0
dom0# ssh 10.99.1.3
Une certaine lenteur doit vous sauter aux yeux, signe d’un soucis de résolution dns (mais ce n’est rien, on va rapidement y remédier).
Depuis la machine ids, on doit pouvoir pinger le routeur 10.2.1.2 et depuis le routeur, on doit pinger l’ids (10.2.1.3)
Par contre, un ping vers le net depuis l’ids ne fonctionne pas.
Coté routeur, installons tcpdump pour voir ce qu’il se passe :
routeur# apt-get install tcpdump
On écoute sur l’interface ou arrive le ping depuis l’ids
routeur# tcpdump -i eth1 icmp -n 00:10:26.395336 IP 10.2.1.3 > 8.8.8.8: ICMP echo request, id 338, seq 159, length 64 00:10:27.395359 IP 10.2.1.3 > 8.8.8.8: ICMP echo request, id 338, seq 160, length 64 00:10:28.395391 IP 10.2.1.3 > 8.8.8.8: ICMP echo request, id 338, seq 161, length 64
Par contre rien sur l’interface eth0 :
routeur# tcpdump -i eth0 icmp -n
Normal : pour activer le transfert (forward) de paquets entre interface, il faut utiliser cette commande :
routeur# echo 1 > /proc/sys/net/ipv4/ip_forward
Pour la rendre persistante (ici, au reboot ip_forward repasserait à 0), dans le fichier /etc/sysctl.conf, trouvez la ligne
net.ipv4.ip_forward=1
et décommentez la.
Ensuite :
sysctl -p /etc/sysctl.confEt la, nous voyons les pings passés sur eth0
# tcpdump -i eth0 icmp -n 00:13:06.483479 IP 10.2.1.3 > 8.8.8.8: ICMP echo request, id 338, seq 319, length 64 00:13:07.483422 IP 10.2.1.3 > 8.8.8.8: ICMP echo request, id 338, seq 320, length 64
Cependant, sur l’ids, aucun retour de notre ping … Pourquoi ?
Pour expliquer, je me sers d’un autre serveur pour la démonstration, sur l’adresse 99.99.99.99, adresse fictive mais qui est une adresse « internet », situé de l’autre côté du routeur pour votres ids.
Depuis l’ids, je ping 99.99.99.99 et sur cette machine :
99.99.99.99# tcpdump icmp 17:33:36.054076 IP 10.2.1.3 > 99.99.99.99: ICMP echo request, id 399, seq 262, length 64 17:33:37.053951 IP 10.2.1.3 > 99.99.99.99: ICMP echo request, id 399, seq 263, length 64 17:33:38.054086 IP 10.2.1.3 >99.99.99.99: ICMP echo request, id 399, seq 264, length 64
Le ping arrive bien mais son adresse source est 10.2.1.3 qui bien sur n’est pas routable… bref la machine 99.99.99.99 ne sait pas a qui renvoyer le paquet.
Tout cela est bien mesquin n’est ce pas ?
Pas de soucis, il suffit au niveau du routeur de lui demander de modifier l’adresse source des paquets qui sortent par son interface eth0 et venant du réseau 10.2.1.0/24 :
routeur# iptables -t nat -A POSTROUTING -o eth0 -s 10.2.1.0/24 -j SNAT --to IPFAILOVER
Cette règle demande à modifier l’adresse source de chaque paquet sortant par eth0. Chaque paquet aura donc l’IP Failover en source, du coup le serveur distant saura ou renvoyer la réponse, et le routeur de faire suivre au demandeur (Policy Accept par défaut d’iptable dans la table NAT, chaine FORWARD, on s’occupera du FW plus tard)
On teste un ping vers 8.8.8.8 depuis l’ids, cela fonctionne.
C – Proxy
Maintenant, démarrons la dernière vm.
Celle ci doit déjà pouvoir pinger l’ids sur l’adresse 10.10.1.3 et depuis l’ids, on doit la pinger sur 10.10.1.10.
Par contre, impossible de pinger l’extérieur depuis cette VM.
Bien sur, il faut activer le forward sur l’ids :
ids# echo 1 > /proc/sys/net/ipv4/ip_forward
Ajoutons la modification au reboot : fichier /etc/sysctl.conf, trouvez la ligne
net.ipv4.ip_forward=1
et décommentez la.
Ensuite :
sysctl -p /etc/sysctl.confMais cela ne suffit pas.
Lancons un ping vers 8.8.8.8 depuis la machine proxy 10.10.1.10 et sur le routeur :
routeur# tcpdump -n icmp 13:14:31.887146 IP IPFAILOVER > 8.8.8.8: ICMP echo request, id 451, seq 1, length 64 13:14:31.923442 IP 8.8.8.8 > IPFAILOVER : ICMP echo reply, id 451, seq 1, length 64 13:14:31.923471 IP 8.8.8.8 > 10.10.1.10: ICMP echo reply, id 451, seq 1, length 64
Pour le retour le routeur recoit un paquet à destination de 10.10.1.10, seulement, si l’on fait :
# route -n Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 GATEWAYONLINE 0.0.0.0 UG 0 0 0 eth0 10.2.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 RESEAUONLINE.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Nous constatons que le routeur ne sait pas quoi faire des paquets à destination du réseau 10.10.1.0/24.
Un peu comme avant, ou la machine 99.99.99.99 ne savait pas quoi faire des paquets en provenance de 10.2.1.2
La première solution serait d’ajouter une règle de DNAT sur l’ids comme il en existe déjà une sur le routeur mais cette solution n’est pas la bonne.
Pourquoi ?
Nous voulons que ce soit le routeur qui définisse qui fait quoi par la suite (par ex, rediriger le port 80 vers telle vm, autoriser tel vm a sortir sur tel port, etc..)
Bref, les règles dans iptables se feront avec les ips du réseau 10.10.1.0/24 (en passant par la gateway de ce réseau, 10.2.1.3). Si nous utilisions l’ids pour faire du masquerade, nous pourrions nous passer de la route nouvelle du routeur, mais dans ce cas, il faudrait faire l’aiguillage des paquets dans l’ids, ce qui n’est pas son rôle.
On va plutôt ajouter une route côté routeur, pour lui dire comment joindre le réseau 10.10.1.0/24
On va donc stipuler que les paquets à destination du réseau 10.10.1.0 doivent transiter par la machine IDS 10.2.1.3 sur l’interface eth1
routeur# route add -net 10.10.1.0/24 gw 10.2.1.3 dev eth1
Ajoutez cette ligne à votre fichier /etc/init.d/debugo pour que cette route soit chargée avec les deux autres.
Il doit ressembler à cela :
#!/bin/bash route add 62.210.83.1/32 dev eth0 route add default gw 62.210.83.1 dev eth0 route add -net 10.10.1.0/24 gw 10.2.1.3 dev eth1
Autorisons le POSTROUTING pour le réseau 10.10.1.0/24
routeur#iptables -t nat -A POSTROUTING -o eth0 -s 10.10.1.0/24 -j SNAT --to IPFAILOVER
Et la, magie, les pings depuis cette VM vers l’extérieur doivent passer.
Pour terminer la démo, installons simplement Nginx.
# apt-get install nginx
Puis sur la vm routeur :
routeur# iptables -t nat -A PREROUTING -i eth0 -d IP_FAILOVER -p tcp --dport 80 -j DNAT --to-destination 10.10.1.10
Et depuis un navigateur, testez un http://IPFAILOVER, vous devriez trouver la page nginx par défaut.
Voila qui clôture ce copieux chapitre.
Dans la suite, nous allons rajouter un peu de firewall sur ces nouvelles machines dans la Partie IV : Firewall.
On peut suivre la création avec :
dom0# tail -f /var/log/xen-tools/routeur.log
=>/var/log/xen-tools# tail -f routeur–role.log
Une fois la vm créé, on va éditer le fichier /etc/xen/routeur.cfg. => existe plus. pas trouvé
Qu’est ce que tu n’as pas trouvé ?