Introduction
Dans ce laboratoire, vous explorerez les principes fondamentaux de la connectivité de la couche réseau dans un environnement Linux. En utilisant des conteneurs Docker pour simuler deux nœuds distincts, vous apprendrez à attribuer manuellement des adresses IP statiques avec la commande ip. Vous utiliserez ensuite l'utilitaire ping pour tester le chemin de communication direct entre ces nœuds sur un réseau virtuel partagé.
En configurant d'abord les nœuds sur le même sous-réseau, vous observerez une connectivité réussie. Vous reconfigurerez ensuite un nœud sur un sous-réseau différent pour constater un échec de communication prévisible : l'erreur 'Destination Host Unreachable'. Cet exercice pratique offre une démonstration claire et concrète de la manière dont les sous-réseaux IP régissent la communication directe et pourquoi les appareils sur des réseaux logiques différents ne peuvent pas se connecter sans routeur.
Préparer l'environnement de laboratoire à deux nœuds
Dans cette étape, vous allez configurer l'environnement de base pour notre laboratoire. Au lieu d'utiliser des machines virtuelles complètes, nous allons exploiter des conteneurs Docker légers et isolés pour simuler deux nœuds réseau distincts. Pour permettre la communication entre eux, nous allons d'abord créer un réseau Docker personnalisé. Ce réseau virtuel agit comme un commutateur réseau physique, plaçant nos deux nœuds sur le même segment de communication partagé.
Téléchargeons l'image Docker Ubuntu 22.04 pour les nœuds.
docker pull ubuntu:22.04
Tout d'abord, créons le réseau virtuel que nos deux nœuds utiliseront. Nous le nommerons lab_net et lui attribuerons une plage d'adresses IP spécifique, ce qui sera important dans les étapes ultérieures.
Exécutez la commande suivante dans votre terminal :
docker network create --subnet=192.168.56.0/24 lab_net
Cette commande indique à Docker de créer un nouveau réseau de type bridge nommé lab_net et le configure pour utiliser le sous-réseau 192.168.56.0/24. Vous verrez un long identifiant unique pour le réseau en sortie, confirmant sa création.
e8c1c2a3b4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1
Ensuite, nous allons lancer notre premier nœud, un conteneur nommé node1, et le connecter au réseau lab_net.
docker run -d --name node1 --network lab_net --cap-add=NET_ADMIN ubuntu:22.04 sleep infinity
Analysons cette commande :
docker run: La commande standard pour créer et démarrer un nouveau conteneur.-d: Exécute le conteneur en mode "détaché", c'est-à-dire qu'il s'exécute en arrière-plan.--name node1: Attribue un nom simple et mémorable à notre conteneur.--network lab_net: Connecte le conteneur au réseau virtuel que nous avons créé précédemment.--cap-add=NET_ADMIN: Accorde au conteneur la capacitéNET_ADMIN, qui est nécessaire pour modifier les paramètres réseau tels que l'ajout d'adresses IP.ubuntu:22.04: L'image Docker que nous utilisons, qui fournit un environnement Ubuntu standard.sleep infinity: Une commande simple qui s'exécute indéfiniment pour maintenir le conteneur actif.
Lancez maintenant le deuxième nœud, node2, en utilisant une commande similaire :
docker run -d --name node2 --network lab_net --cap-add=NET_ADMIN ubuntu:22.04 sleep infinity
Enfin, vérifions que nos deux nœuds fonctionnent correctement. La commande docker ps liste tous les conteneurs en cours d'exécution.
docker ps
Vous devriez voir une sortie similaire à la suivante, confirmant que node1 et node2 sont tous deux démarrés et en cours d'exécution.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a1b2c3d4e5f6 ubuntu:22.04 "sleep infinity" 5 seconds ago Up 4 seconds node2
g7h8i9j0k1l2 ubuntu:22.04 "sleep infinity" 15 seconds ago Up 14 seconds node1
Avec les deux nœuds fonctionnant sur le même réseau virtuel, notre environnement de laboratoire est maintenant préparé. Dans les étapes suivantes, nous configurerons leurs adresses IP et testerons leur connectivité.
Configurer une IP statique sur le premier nœud avec ip addr
Dans cette étape, vous allez attribuer une adresse IP statique à notre premier conteneur, node1. Une IP statique est une adresse qui est configurée manuellement et qui ne change pas, contrairement à une IP dynamique qui est souvent attribuée automatiquement par un serveur DHCP. Pour notre simulation, l'utilisation d'IP statiques nous donne un contrôle précis sur la configuration réseau.
Nous effectuerons toutes les actions depuis votre terminal principal sur la machine hôte, en utilisant la commande docker exec pour exécuter des commandes à l'intérieur du conteneur node1.
Premièrement, l'image de base ubuntu:22.04 est très minimale. Nous devons installer les outils réseau nécessaires. Commençons par mettre à jour la liste des paquets à l'intérieur du conteneur node1 :
docker exec node1 apt-get update
Vous verrez une sortie lorsque le conteneur récupérera les informations des derniers paquets.
Ensuite, installez le paquet iproute2 (qui fournit la commande ip) et iputils-ping (qui fournit la commande ping que nous utiliserons plus tard).
docker exec node1 apt-get install -y iproute2 iputils-ping
Maintenant que les outils sont installés, inspectons la configuration réseau actuelle de node1. L'interface réseau à l'intérieur d'un conteneur Docker standard est généralement nommée eth0.
docker exec node1 ip addr show eth0
La sortie affichera les détails de l'interface eth0. Vous pourriez voir une adresse IP déjà attribuée par le serveur DHCP interne de Docker (par exemple, 192.168.56.2). Nous allons ajouter notre propre IP statique.
9: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:c0:a8:38:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.56.2/24 brd 192.168.56.255 scope global eth0
valid_lft forever preferred_lft forever
Maintenant, attribuons l'adresse IP statique 192.168.56.10 à node1. Le /24 est la notation CIDR pour le masque de réseau 255.255.255.0, définissant la taille du réseau.
docker exec node1 ip addr add 192.168.56.10/24 dev eth0
Cette commande ne devrait produire aucune sortie en cas de succès. Pour confirmer le changement, exécutez à nouveau la commande ip addr show eth0 :
docker exec node1 ip addr show eth0
Vous devriez maintenant voir votre nouvelle adresse IP statique listée à côté de l'originale, marquée comme secondary. Cela confirme que node1 est maintenant configuré avec l'adresse 192.168.56.10.
9: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:c0:a8:38:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.56.2/24 brd 192.168.56.255 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.56.10/24 scope global secondary eth0
valid_lft forever preferred_lft forever
Configurer une IP statique sur le second nœud dans le même sous-réseau
Dans cette étape, nous allons configurer notre second nœud, node2, avec une adresse IP statique. Pour que deux appareils puissent communiquer directement sans routeur, ils doivent résider sur le même sous-réseau logique. Nous allons attribuer à node2 une adresse IP du même sous-réseau 192.168.56.0/24 que nous avons utilisé pour node1. Cette configuration imite logiquement deux PC connectés avec un câble croisé, où les deux font partie du même réseau local.
Premièrement, tout comme nous l'avons fait pour node1, nous devons installer les outils réseau nécessaires à l'intérieur du conteneur node2. Commencez par mettre à jour la liste des paquets :
docker exec node2 apt-get update
Ensuite, installez les paquets iproute2 et iputils-ping sur node2 :
docker exec node2 apt-get install -y iproute2 iputils-ping
Une fois les outils installés, nous pouvons maintenant attribuer une adresse IP statique à node2. Nous utiliserons 192.168.56.11, qui se trouve dans le même sous-réseau que node1 (192.168.56.10) mais est une adresse unique.
docker exec node2 ip addr add 192.168.56.11/24 dev eth0
Cette commande ajoute l'adresse IP 192.168.56.11 avec un masque de réseau /24 à l'interface réseau eth0 du conteneur node2. Si la commande réussit, elle ne produira aucune sortie.
Pour vérifier que l'adresse IP a été correctement attribuée, inspectons la configuration réseau de node2 :
docker exec node2 ip addr show eth0
La sortie devrait maintenant afficher la nouvelle adresse IP statique ajoutée, marquée comme secondary. Cela confirme que node2 est correctement configuré et prêt pour la prochaine étape où nous testerons la connectivité.
11: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:c0:a8:38:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.56.3/24 brd 192.168.56.255 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.56.11/24 scope global secondary eth0
valid_lft forever preferred_lft forever
Vérifier la connectivité directe entre les nœuds avec ping
Dans cette étape, vous allez tester la connectivité réseau entre node1 et node2. Maintenant que les deux nœuds ont des adresses IP sur le même sous-réseau, ils devraient pouvoir communiquer directement. Nous utiliserons la commande ping, un utilitaire réseau fondamental qui envoie un petit paquet de données (une requête ICMP Echo) à un hôte cible et attend une réponse. Une réponse réussie confirme qu'un chemin réseau existe entre les deux appareils.
Ce test réussi est analogue à la connexion de deux PC avec un câble croisé, où les deux appareils sont sur le même réseau local et peuvent se voir directement.
Tout d'abord, essayons de pinger node2 depuis node1. Nous exécuterons la commande ping à l'intérieur du conteneur node1, en ciblant l'adresse IP de node2, 192.168.56.11.
docker exec node1 ping -c 4 192.168.56.11
Analysons cette commande :
docker exec node1: Exécute la commande suivante à l'intérieur du conteneurnode1.ping: L'utilitaire pour tester la connectivité.-c 4: Un indicateur qui indique àpingd'envoyer exactement 4 paquets puis de s'arrêter. Sans cela,pings'exécuterait indéfiniment.192.168.56.11: L'adresse IP de destination denode2.
Vous devriez voir une sortie réussie, avec des réponses reçues de node2.
PING 192.168.56.11 (192.168.56.11) 56(84) bytes of data.
64 bytes from 192.168.56.11: icmp_seq=1 ttl=64 time=0.123 ms
64 bytes from 192.168.56.11: icmp_seq=2 ttl=64 time=0.087 ms
64 bytes from 192.168.56.11: icmp_seq=3 ttl=64 time=0.091 ms
64 bytes from 192.168.56.11: icmp_seq=4 ttl=64 time=0.085 ms
--- 192.168.56.11 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3074ms
rtt min/avg/max/mdev = 0.085/0.096/0.123/0.015 ms
La ligne "4 packets transmitted, 4 received, 0% packet loss" confirme que la connexion fonctionne. Maintenant, vérifions la connexion dans l'autre sens en pingant node1 depuis node2.
docker exec node2 ping -c 4 192.168.56.10
Là encore, vous devriez voir une série de réponses réussies, confirmant que la communication est bidirectionnelle.
PING 192.168.56.10 (192.168.56.10) 56(84) bytes of data.
64 bytes from 192.168.56.10: icmp_seq=1 ttl=64 time=0.099 ms
64 bytes from 192.168.56.10: icmp_seq=2 ttl=64 time=0.088 ms
64 bytes from 192.168.56.10: icmp_seq=3 ttl=64 time=0.092 ms
64 bytes from 192.168.56.10: icmp_seq=4 ttl=64 time=0.089 ms
--- 192.168.56.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3081ms
rtt min/avg/max/mdev = 0.088/0.092/0.099/0.004 ms
Succès ! Les deux nœuds peuvent communiquer entre eux, comme s'il s'agissait de deux ordinateurs sur le même segment de réseau local.
Reconfigurer le second nœud vers un sous-réseau différent
Dans cette étape, nous allons intentionnellement casser la connectivité directe entre nos deux nœuds. Nous allons y parvenir en reconfigurant node2 pour qu'il soit sur un sous-réseau IP complètement différent de node1. Cela simule un scénario où deux appareils sont physiquement connectés mais logiquement séparés en différents réseaux.
Actuellement, node1 se trouve sur le sous-réseau 192.168.56.0/24. Nous allons maintenant déplacer node2 sur le sous-réseau 192.168.58.0/24. Comme le troisième nombre (octet) est différent (56 contre 58), ceux-ci sont considérés comme des sous-réseaux distincts.
Pour garantir que node2 soit complètement isolé sur le nouveau réseau, nous devons d'abord supprimer toutes les adresses IP existantes de son interface eth0. Cela inclut à la fois l'adresse IP statique que nous avons ajoutée précédemment et l'adresse IP d'origine que Docker a attribuée automatiquement. La commande ip addr flush est l'outil approprié pour cette tâche.
docker exec node2 ip addr flush dev eth0
Cette commande supprime toutes les configurations IP de eth0, assurant une base propre. Elle ne devrait produire aucune sortie en cas de succès.
Maintenant, ajoutons la nouvelle adresse IP, 192.168.58.11, qui appartient au nouveau sous-réseau.
docker exec node2 ip addr add 192.168.58.11/24 dev eth0
Pour confirmer les changements, inspectons à nouveau la configuration réseau de node2.
docker exec node2 ip addr show eth0
Vous verrez que toutes les anciennes adresses IP ont disparu, et seule la nouvelle (192.168.58.11) existe. Cela confirme que node2 n'est plus sur le sous-réseau 192.168.56.0/24.
11: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:c0:a8:38:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.58.11/24 scope global eth0
valid_lft forever preferred_lft forever
Avec node1 sur le sous-réseau 192.168.56.0/24 et node2 sur le sous-réseau 192.168.58.0/24, ils sont maintenant logiquement isolés.
Tester la connectivité et observer l'échec
Dans cette dernière étape, nous allons à nouveau tenter de pinger entre les nœuds. Avec node2 désormais véritablement isolé sur un nouveau sous-réseau, nous nous attendons à ce que la communication échoue, mais de deux manières différentes et importantes qui révèlent le fonctionnement des couches réseau.
Tout d'abord, essayons de pinger la nouvelle adresse IP de node2 (192.168.58.11) depuis node1.
docker exec node1 ping -c 4 192.168.58.11
Observez la sortie. La commande expirera, entraînant une perte de paquets de 100 %.
PING 192.168.58.11 (192.168.58.11) 56(84) bytes of data.
--- 192.168.58.11 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3076ms
Ce délai d'attente se produit car node1 a toujours une route vers le réseau Docker, il envoie donc le paquet ping. Le réseau le transmet à node2. Cependant, comme node2 n'est plus sur ce réseau et n'a pas de route de retour, il ne peut pas envoyer de réponse. Le ping de node1 ne reçoit jamais de réponse.
Ensuite, testons l'autre direction. Essayez de pinger node1 depuis node2.
docker exec node2 ping -c 4 192.168.56.10
Cette fois, vous verrez un message d'erreur différent presque immédiatement.
ping: connect: Network is unreachable
Le message ping: connect: Network is unreachable est significatif. C'est une réponse immédiate du système d'exploitation sur node2. Cela signifie que le système d'exploitation a vérifié sa table de routage, a constaté que la destination 192.168.56.10 se trouve sur un réseau auquel il n'a aucun chemin, et a refusé même de tenter d'envoyer le paquet. C'est une conséquence directe de l'utilisation de ip addr flush, qui a effacé toutes les routes, isolant complètement le conteneur des autres réseaux.
Ce laboratoire a démontré avec succès le rôle essentiel de la segmentation IP et du routage. Lorsque les appareils sont sur le même sous-réseau, ils peuvent communiquer directement. Lorsqu'ils sont sur des sous-réseaux différents, un périphérique de couche 3 comme un routeur avec les routes appropriées est nécessaire pour acheminer le trafic entre eux.
Résumé
Dans ce laboratoire, vous avez appris à simuler un environnement réseau à deux nœuds en utilisant des conteneurs Docker connectés à un réseau bridge personnalisé. Vous avez pratiqué la compétence essentielle de Linux consistant à configurer des adresses IP statiques sur les interfaces réseau à l'aide de la commande ip addr. En attribuant des adresses IP du même sous-réseau aux deux nœuds, vous avez vérifié avec succès la connectivité directe de couche 3 entre eux à l'aide de l'utilitaire ping, démontrant ainsi l'exigence fondamentale de communication sur un segment de réseau local.
Le laboratoire a en outre illustré un concept réseau critique en reconfigurant un nœud avec une adresse IP d'un sous-réseau différent après avoir complètement purgé sa configuration réseau d'origine. Les tentatives ultérieures de communication via ping ont échoué avec deux résultats distincts : un délai d'attente dans une direction et une erreur 'Destination Host Unreachable' dans l'autre. Ce résultat a effectivement montré que les nœuds sur des sous-réseaux logiques différents ne peuvent pas communiquer directement sans routeur, et il a souligné comment les tables de routage et la configuration des interfaces affectent la connectivité réseau.
