Resp. UE : P-F. Bonnefoi, http://p-fb.net/, « Réseaux Avancés I–TP n°4 » version du 5 décembre 2016, rédigé avec ConTEXt – Don’t Panic ! 1/4

Master1èreannée

RéseauxAvancés I

TP n°4

Configuration réseau, « sniffing » & virtualisation

Plateforme virtuelle

∘ le réseau du FAI : la machine réelle ;∘ le routeur du FAI : les services réseaux fournis

par VirtualBox : NAT, DHCP, Routage, DNS.∘ un routeur Linux : la VM ;∘ le réseau interne : un « bridge » virtuel dans la

VM ;∘ deux postes, « UsagerA » et « UsagerB » : deux

LXC dans la VM ;

On obtient le schéma suivant :

[ bridge_internal ]-------------

VM +-------------- / \ --+ \-----------------+Routeur | |

[INTERNAL_HOSTA: 10.10.10.3] [INTERNAL_HOSTB: 172.16.1.11]

Création des fichiers de configuration de la simulation sur la VM ishtar :

Pour la configuration des connexions :# on active le mode routeursudo sysctl -w net.ipv4.ip_forward=1

# on ajoute deux pontssudo brctl addbr bridge_internalsudo brctl setfd bridge_internal 0sudo ip link set bridge_internal up

dans le fichier config_network_hardware

Ce fichier est à créer dans la VM.Lors de son exécution, il va déclencher la fonctionde routage et créer un bridge virtuel .Vous exécuterez ce fichier dans la VM au traversd’une connexion SSH :

xterm$ source config_network_hardware

Création des deux containers LXC :Pour la configuration du Host A :lxc.utsname = INTERNAL_HOSTAlxc.network.type = vethlxc.network.veth.pair = veth_INTERNAL_Alxc.network.flags = uplxc.network.link = bridge_internallxc.network.name = eth0lxc.network.hwaddr = 00:0a:ba:be:ca:fe

dans le fichier Internal_HostA.cfg

Pour la configuration du Host B :lxc.utsname = INTERNAL_HOSTBlxc.network.type = vethlxc.network.veth.pair = veth_INTERNAL_Blxc.network.flags = uplxc.network.link = bridge_internallxc.network.name = eth0lxc.network.hwaddr = 00:0a:de:ad:be:ef

dans le fichier Internal_HostB.cfg

Pour le lancement du Host A :sudo lxc-execute -n LXCHOSTA -f Internal_HostA.cfg bash dans le fichier lancer_hoteA

Pour le lancement du Host B :sudo lxc-execute -n LXCHOSTB -f Internal_HostB.cfg bash dans le fichier lancer_hoteB

Lancement des deux containers dans un connexion différente de votre poste vers la VM ishtar :xterm

$ source lancer_hoteAxterm

$ source lancer_hoteB

Resp. UE : P-F. Bonnefoi, http://p-fb.net/, « Réseaux Avancés I–TP n°4 » version du 5 décembre 2016, rédigé avec ConTEXt – Don’t Panic ! 2/4

Travail à réaliser1 – Dans chacun des containers, exécutez les commandes suivantes :

□ ip link□ ip address□ ip routeQue pouvez vous apprendre sur la configuration de ces deux containers ?

2 – Vous allez maintenant configurer l’interface de chaque container de la manière suivante :□ INTERNAL_HOSTA :

xterm# ip address add 172.16.1.129/24 dev eth0

□ INTERNAL_HOSTB :xterm

# ip address add 172.16.1.1/25 dev eth0

a. Si vous utilisez la commande « ip address » et « ip route » sur chaque container qu’est-ce quia changé ?

b. Test de connectivité : depuis INTERNAL_HOSTA faites un ping vers INTERNAL_HOSTB :xterm

# ping 172.16.1.1

Que se passe-t-il ?Essayez de faire un ping depuis INTERNAL_HOSTB vers INTERNAL_HOSTA : qu’observez vous ?Quelle explication pouvez vous donner à ce comportement ?

Utilisez maintenant la possibilité de « sniffer » le trafic sur le « bridge_internal », en lançant la com-mande sur la VM :

xterm$ sudo tcpdump -nvve -i bridge_internal

Qu’observez vous lorsque vous faites chacun des « ping » ?Comment corriger le problème ?

Quitter un container LXC

Pour quitter un container LXC, il suffit de quitter le shell qu’il exécute par la commande « exit » oula combinaison CTRL-D.

Routage inter-segments3 – Une société dispose de 172.16.1.0/24 :

Internet172.16.1.128/25

Mail server172.16.1.209

Host B172.16.1.7

Router andpacket filter

Host A172.16.1.11

Web server172.16.1.208

172.16.1.0/25

Internal network

DMZ

eth0

eth2

eth1

Nous allons modéliser ce réseau à l’aide de « containers » Linux, ou « LXC » à l’intérieur d’une machinevirtuelle dans laquelle vous êtes administrateur.

Resp. UE : P-F. Bonnefoi, http://p-fb.net/, « Réseaux Avancés I–TP n°4 » version du 5 décembre 2016, rédigé avec ConTEXt – Don’t Panic ! 3/4

Simulation avec deux containers :[ bridge_dmz ] [ bridge_internal ]

____ ----

+----- / \ -----------+ Hôte Réel +-------------- / \ -------+

| Routeur |

[DMZ_WEB: 172.16.1.208] [INTERNAL_HOSTA: 172.16.1.11]

Création des fichiers de configuration de la simulation sur la VM ishtar :

Pour la configuration des connexions :# on active le mode routeursudo sysctl -w net.ipv4.ip_forward=1

# on ajoute deux pontssudo brctl addbr bridge_internalsudo brctl setfd bridge_internal 0sudo ip link set bridge_internal up

sudo brctl addbr bridge_dmzsudo brctl setfd bridge_dmz 0sudo ip link set bridge_dmz up

dans le fichier config_network_hardware

Pour la configuration des interfaces réseaux :# on fixe les adresses des interfacessudo ip addr add 172.16.1.129/25 devbridge_dmzsudo ip addr add 172.16.1.1/25 devbridge_internal

dans le fichier config_network_routing

Pour la configuration du serveur Web :lxc.utsname = DMZ_WEBlxc.network.type = vethlxc.network.veth.pair = veth_DMZ_WEBlxc.network.flags = uplxc.network.link = bridge_dmzlxc.network.name = eth0lxc.network.hwaddr = 00:0a:de:ad:be:eflxc.network.ipv4 = 172.16.1.208/25

dans le fichier DMZ_Web_server.cfg

Pour la configuration du Host A :lxc.utsname = INTERNAL_HOSTAlxc.network.type = vethlxc.network.veth.pair = veth_INTERNAL_Alxc.network.flags = uplxc.network.link = bridge_internallxc.network.name = eth0lxc.network.hwaddr = 00:0a:ba:be:ca:felxc.network.ipv4 = 172.16.1.11/25

dans le fichier Internal_HostA.cfg

Pour le lancement du Host A :sudo lxc-execute -n LXCHOST -f Internal_HostA.cfg bash dans le fichier lancer_hote

Pour le lancement du serveur Web :sudo lxc-execute -f DMZ_Web_server.cfg -n LXCWEB bash dans le fichier lancer_web

Lancement des deux containers dans un connexion SSH différente de votre poste vers la VM ishtar :xterm

$ source lancer_hotexterm

$ source lancer_web

Configuration de la passerelle des deux containers :Sur le container « DMZ_WEB » :

xterm# ip route add default via 172.16.1.129

et sur le container « INTERNAL_HOSTA » :xterm

# ip route add default via 172.16.1.1

Travail à réaliser1. Test du routage avec le « ping » de la machine « HOST_A » vers la machine « DMZ_WEB » ;

2. Test de la connexion depuis la machine « HOST_A » vers le serveur web de la machine « DMZ_WEB » :xterm

# socat stdio tcp-listen:8000 sur DMZ_WEB

et sur HOST_A :xterm

# socat stdio tcp:172.16.1.208:8000

Vous devez pouvoir échanger du texte entre les deux containers au travers de la connexion TCP.

3. Observation de la connexion de « socat » avec tcpdump :

Resp. UE : P-F. Bonnefoi, http://p-fb.net/, « Réseaux Avancés I–TP n°4 » version du 5 décembre 2016, rédigé avec ConTEXt – Don’t Panic ! 4/4

xterm$ tcpdump -i bridge_dmz tcp and port 8000

Attention

Pour quitter un container, vous pouvez « quitter » le shell par la commande « exit » ou le raccourci« ctrl-c ». Dans le cas où un programme continue à fonctionner dans le container, comme le serveurWeb du container « DMZ_WEB », il est possible que votre container refuse de quitter.Dans ce cas là, vous pouvez vérifier si un container continue son exécution à l’aide de la commande :$ lxc-ls

LXCWEB

Et ensuite vous pouvez le supprimer à l’aide de la commande :$ sudo lxc-kill -n LXCWEB

La virtualisationSous Linux, il est possible de créer des machines virtuelles suivant différentes méthodes :⋆ l’émulation hardware : où il est possible de faire tourner des OS différents par émulation, c-à-d. en

émulant l’intégralité du hardware mis à disposition de l’OS.C’est une solution très lente. Exemple : qemu, bochs

⋆ la « full virtualization » ou la virtualisation complète : on utilise un « Hyperviseur », et un point d’accèscommun aux ressources matérielles que l’on met à disposition des différents OS ;On obtient de bonnes performances, mais il faut disposer d’un mode hyperviseur dans le processeur.Exemple : VMWare, VirtualBox, IBM z/VM, KVM.

⋆ la « paravirtualisation » : on utilise également un mode hyperviseur, mais on utilise uniquement des OSqui ont été modifiés pour tenir compte de cette virtualisation.On obtient les meilleurs performances, mais on ne peut l’exploiter que pour certains OS modifiables.Exemple : Xen.

⋆ la « virtualisation d’OS » : qui est également appelé « containerization » ou « zoning » qui permet dedéfinir différents « espaces utilisateurs » en utilisant un seul noyau.Les performances sont excellentes, et le container ne s’applique que sur les éléments que l’on veutmettre dans un container.Exemple : OpenVZ, Linux-Vserver, LXC.

LXC et connexion réseauIl existe différents types d’interface pour la configuration d’un container Linux :∘ phys : donne au container le contrôle direct d’une interface physique de l’hôte ;∘ veth : crée un couple d’interface :

⋄ une à l’intérieur du container (surle schéma, « lxcn0 ») ;

⋄ une dans l’hôte (sur le schéma,« veth0 ») qui doit être reliée à unbridge (sur le schéma, « br0 »).

L’interface externe permet « d’écouter »ce qui transite sur l’interface internedu container.

C’est

ce type d’interface que nous utiliserons pour connecter notre container à un « hub », « bridge », lui-même virtuel.