Labo virtuel personnel – quatrième partie : installation de Debian client (avec GUI XFCE 4)

Nous allons maintenant créer une machine pour un usage « client », dotée d’une interface graphique (GUI). Nous y installerons un navigateur web et un terminal confortable, afin notamment d’administrer notre serveur. En général on utilise Windows pour cela, mais nous allons expérimenter ici l’univers Linux et nous rendre compte qu’il est simple de déployer une interface graphique sur une VM légère mais néanmoins efficace.

Nous allons partir de la machine précédente en la clonant, puis en ajoutant l’environnement de bureau XFCE, réputé léger et fonctionnel.

Clonage de la première VM Debian

Un clic droit sur la VM réalisée à l’étape précédente offre l’option de clonage :

Le clonage, comme les clichés instantanés, sont un des grands intérêts de VirtualBox (et de la virtualisation en général).

On donne un nom à cette nouvelle VM, et on régénère de nouvelles adresses MAC sur les interfaces réseau (important) :

Si vous n’avez pas exactement cet écran, cliquez sur le bouton « mode guidé » en bas de la fenêtre.

L’option clone lié permet de limiter les ressources de stockage nécessaires, mais rendra cette VM dépendante de la première. Si on dispose d’un espace de stockage suffisant, il vaut mieux réaliser cependant un clone intégral :

Nous aurons besoin sur cette VM d’un lecteur optique vide pour installer les extensions VirtualBox ; on l’installe sur le contrôleur SATA existant :

On n’insère aucune image ISO dans ce lecteur.

On démarre cette nouvelle machine et on se logue en root :

le login et le mot de passe sont les mêmes sur la machine initiale.

Installation de l’environnement XFCE4

On modifie au préalable le nom de machine (hostname) de debian à debian-gui par l’éditeur nano, sans oublier de modifier aussi le fichier de résolution locale DNS de la machine (/etc/hosts) :

# nano /etc/hostname

(On valide les modifications avec CTRL-X et O)

# nano /etc/hosts
modification du fichier /etc/hosts

Ensuite on installe l’utilitaire sudo et on ajoute l’utilisateur standard (adapter selon votre propre login) au groupe des sudoers :

# apt install sudo
# adduser pascal sudo

Puis le gros morceau (quasiment 1GiB de téléchargement) : l’installation de xfce4 :

# apt install xfce4
pendant l’installation de XFCE4…

On relance la VM :

# reboot

La console propose désormais un login graphique.

IMPORTANT : il faut se connecter avec l’utilisateur sudoer et non par directement en root. En effet utiliser un environnement graphique en root génère de nombreux désagréments (essayez, vous verrez 😉 :

Le login en version GUI assuré par le display manager (ici c’est lightdm)

On va désormais installer les utilitaires et pilotes VirtualBox pour rendre l’environnement plus ergonomique (ils vont permettre notamment de mettre en place le copier/coller et le glisser/déposer entre la VM et la machine hôte, et de dimensionner dynamiquement la définition graphique de la VM).

On insère d’abord le CD d’installation des « additions VirtualBox » :

L’icône du lecteur optique avec le CD doit apparaître sur le bureau XFCE. En cas d’échec, vérifier que vous avez bien un lecteur optique installé sur la VM.

Ensuite, on ouvre le terminal depuis le dock XFCE :

On continue dans ce terminal, en installant les prérequis (ligne 1), en montant le CD dans le système de fichiers (lignes 2 à 4), puis en lançant le script d’installation (ligne 5) ; enfin, on redémarre la VM (ligne 6) :

$ sudo apt install bzip2
$ sudo mkdir -p /mnt/cdrom
$ sudo mount /dev/cdrom /mnt/cdrom
$ cd /mnt/cdrom
$ sudo ./VBoxLinuxAdditions.run
$ sudo reboot

On peut remarquer que désormais l’interface graphique s’ajuste à la taille de la fenêtre. Il peut (très) utile aussi d’activer le presse-papier partagé bidirectionnel depuis le menu « périphériques » de la console VirtualBox. Et pourquoi pas également le glisser-déposer.

Enfin, nous allons installer le navigateur Firefox et une application de terminal plus ergonomique (terminator par exemple) :

$ sudo apt install -y firefox-esr terminator

Vérifications

Pour vérifier tout ça, depuis le dock on relance un terminal (qui doit être terminator désormais) et on ping un domaine public, comme debian.org.

On ouvre également depuis le dock le navigateur Web (Firefox) et on se rend sur la page web de debian.org :

NB : si la notion de « connexion ssh au serveur » n’est pas très claire pour vous, ce n’est pas grave, nous aborderons ceci dans les prochains tutoriels.

Sauvegarde de l’état de la VM

Ne pas oublier d’éteindre et de prendre un « snapshot » de cette machine cliente, pour pouvoir la restaurer dans cet état « post installation ».

Conclusion (mais ce n’est pas fini…)

Nous disposons au terme de ces quatre étapes des machines de notre laboratoire virtuel sur le thème « Linux » (nous verrons par ailleurs un homelab sur le thème « Windows »).

J’espère que jusque là tout est ok pour vous ! Il nous reste une dernière étape visant à interconnecter nos VM dans le LAN virtuel et à réaliser le paramétrage de base de pfSense.

Labo virtuel personnel – deuxième partie : installation de pfSense

Cette machine virtuelle pfSense va être le pivot et le cœur du réseau de notre environnement. On s’arrête ici à son installation ; dans des tutos ultérieurs nous pourrons découvrir toutes les fonctionnalités de cette distribution pour la gestion et la protection des réseaux.

Image ISO d’installation

Première chose, il faut récupérer l’image ISO d’installation de pfSense CE (Community Edition), dernière version, pour architecture x64 (AMD64).

NB : Il ne faut pas choisir l’image pour clé USB dont le fonctionnement est différent ; on pourra en revanche utiliser ce format pour un déploiement sur une machine physique notamment.

L’URL de téléchargement est : https://www.pfsense.org/download/

Téléchargement de l’image ISO sur le site de l’éditeur Netgate

L’image récupérée est de la forme : pfSense-CE-2.x.x-RELEASE-amd64.iso.gz Il est recommandé de vérifier la signature SHA256 de l’image, à l’aide d’un outil comme hashcheck par exemple :

l’outil Hashcheck ajoute un onglet sur les propriétés d’un fichier pour le calcul des empreintes.

Cette image est compressée au format gzip (.gz), il faut un outil tel que 7zip pour en extraire le fichier image ISO final :

L’utilitaire 7zip est un excellent outil, libre, pour manipuler les archives sous de nombreux formats.

Création et configuration de la VM

Depuis VirtualBox, taper CTRL+N (ou menu Machine / Nouvelle), nommer la VM pfSense et choisir le type FreeBSD x64 (pfSense est en effet une distribution de FreeBSD) :

La première étape de création d’une VM, avec la nouvelle interface de la version 7 de VirtualBox.

On lui octroie ensuite (ce qui doit correspondre aux propositions par défaut) :

  • 1024 Mio de RAM,
  • 1 cœur CPU
  • Un disque dur (type VDI) dynamiquement alloué de 16 Gio.
Choix de la RAM allouée et du nombre de cœurs CPU
Création d’un nouveau disque virtuel au format VDI. A noter que l’espace demandé n’est pas provisionné sur le disque physique, il le sera au fur et à mesure (ce qui réduit les performances, mais ici ce n’est pas crucial).

La machine est maintenant créée, nous allons finalier la configuration, puis lancer l’installation.

Configuration de la VM

Cliquer sur le bouton « Configuration » pour faire apparaître les paramètres de la VM. On désactive les ressources audios parfaitement inutiles :

On désactive l’interface audio.

Les ports série et USB doivent être désactivés, car ils ne sont pas non plus utiles pour notre cas :

Désactivation des interfaces USB ; les interfaces port série ne sont pas activées par défaut.

Configuration de l’interface réseau WAN

Dans la rubrique « réseau », nous allons configurer deux interfaces. Une première correspond à la partie WAN de pfSense, l’accès à Internet, que l’on obtient par pontage (bridge) d’une interface existante sur la machine hôte, soit par le mode « NAT » proposé par VirtualBox, qui permet d’ajouter une isolation supplémentaire par rapport au réseau réel.

Si l’on souhaite par la suite rendre le pfSense « visible » sur Internet, il est préférable de choisir le mode bridge. Dans ce mode, il faudra sélectionner l’interface physique associée (et on préfèrera une interface filaire plutôt que Wi-Fi).

Le mode NAT permet quant à lui d’accéder à Internet sur des machines hôtes qui sont sur un réseau assez sécurisé : en effet, le pare-feu amont ne « voit » que la machine hôte, qui « partage sa connexion » avec la VM.

Ici, nous allons utiliser le mode NAT, qui permet en plus de ne pas avoir à choisir l’interface physique parente. Il est toujours possible bien sûr de modifier ensuite pour utiliser le mode pont (bridge) :

L’interface 1 de la VM est connectée en mode NAT. Avec VirtualBox, on ne dispose que de quatre interfaces réseau maximum.

Configuration de l’interface LAN

La seconde interface réseau correspond au côté LAN de pfSense ; on l’associe à un réseau local interne (qu’on appellera donc LAN) sur lequel nous pourrons connecter nos autres équipements virtuels. Notons qu’il est possible ici de visualiser et même de renouveler l’adresse MAC de l’interface virtuelle :

La seconde interface réseau, connectée sur un réseau interne virtuel, appelé « LAN ».

Installation de pfSense

La machine est prête, on clique sur OK, et on la démarre :

L’écran d’accueil de l’installateur pfSense

Pour notre installation plutôt standard, il suffit d’accepter les options proposées par défaut.

NB :  Il n’est pas utile de configurer un clavier français lors de l’installation, car au démarrage suivant, le clavier est de nouveau en mode QWERTY (à moins que ce bug ne soit corrigé dans le futur)

Attention à bien sélectionner le disque de destination avec la barre d’espacement :

On sélectionne l’emplacement de stockage. pfSense utilise ZFS qui permet notamment d’utiliser plusieurs disques et de gérer nativement la redondance (RAID).

Et on confirme sans hésiter :

L’installation va supprimer tout le contenu du disque. On est prévenu !

Attention pour la phase finale : afin d’éteindre la machine, plutôt que la redémarrer, on va utiliser le Shell pour lancer la commande « init 0 » (attention, la disposition du clavier est QWERTY) :

On demande l’ouverture du Shell Unix…
… pour éteindre la VM.

La VM s’éteint.

On supprime le lecteur optique devenu inutile :

Suppression du lecteur optique de la VM, qui n’est plus utile.

On relance la VM pfSense, la console affiche toute la séquence de démarrage, jusqu’à cet écran :

Le menu principal de pfSense (sur l’accès console primaire).

Affectation des interfaces (si besoin)

De façon générale, pfSense aura automatiquement affecté chaque interface à son rôle : WAN (sur l’interface NAT) & LAN (sur l’interface en réseau interne)

En cas de problème, ou de doute, il est possible de relancer cette affectation, avec l’option 1 de la console :

La gestion des interfaces en mode console. On peut également ici configurer des VLAN (nous n’en aurons pas besoin dans notre environnement).

Les interfaces disponibles sont identifiées par leur adresse physique MAC, et leur nom dans le système FreeBSD (em0 et em1 dans notre cas).

On ne souhaite pas mettre en place des VLAN ici, on répond : N ; puis on affecte les interfaces à leur rôle, WAN ou LAN :

attention, le clavier est toujours en QWERTY ! et le verrouillage numérique n’est probablement pas activé par défaut.

A propos de la console pfSense

La console permet d’effectuer des opérations de base pour pfSense, notamment :

  • Redémarrer (5)
  • Arrêter (6)
  • Affecter les interfaces (1)
  • Configurer les interfaces (2)
  • Lancer une mise à jour du système (13)
  • Réinitialiser les réglages par défaut (4)
  • Réinitialiser le mot de passe d’administration (3)

Dans la pratique, il est recommandé de protéger l’accès à ce menu console par un mot de passe (ceci se règle depuis l’interface WEB GUI que nous verrons plus loin.)

Fonctionnement de la VM en tâche de fond

Afin que pfSense tourne en tâche de fond dans notre environnement, il peut être démarré sans affichage depuis VirtualBox :

démarrage d’une VM en tâche de fond.

Dès lors, la console n’est visible que depuis la prévisualisation de VirtualBox, mais il est possible de réactiver la console en cliquant sur « afficher » :

Mais il est possible d’obtenir une console pour une telle machine.

Et de la refermer depuis le menu « fichier » de la fenêtre console :

On retire la console attachée.

Voilà, notre VM pfSense fonctionne. Sa configuration complète n’est pas réalisée, car il faut pour cela disposer d’un navigateur WEB pour accéder, par le réseau LAN, à la console WEBAdmin. Nous verrons ceci un peu plus loin, dans une section consacrée aux réglages, astuces et bonnes pratiques de sécurité avec pfSense.

La prochaine étape : construire et préparer notre machine Debian core, destinée à un usage « serveur ».

Labo virtuel personnel – première partie : présentation et installation de VirtualBox

Introduction

La version 7 de VirtualBox est sortie depuis quelques semaines maintenant. A cette occasion, je vous propose un guide pratique pour la mise en place d’un laboratoire systèmes & réseaux personnel, léger, virtuel et open source. Cette version majeure de VB apporte en effet des évolutions attendues qui confortent cet hyperviseur de niveau 2 comme une solution fiable et maintenue pour la virtualisation de systèmes.

Ce guide se veut aussi complet, précis et universel que possible, sans trop charger de détails inutiles. Il est revérifié régulièrement au gré des mises à jour des différentes solutions utilisées.

Prérequis

Pour réaliser avec succès tous ces travaux, il faut disposer d’un ordinateur équipé au minimum d’un processeur x64 (Intel ou AMD) avec 4 cœurs physiques, 8 Gio de RAM (16 étant plus confortable), un stockage de type SSD avec au minimum 100 Gio libres et une interface réseau connectée à Internet, de préférence filaire. Sur cet ordinateur hôte, qui n’est pas dédié à ce rôle d’hyperviseur, le système d’exploitation sera probablement MS Windows 10 ou 11. On essaiera d’avoir une installation la plus « propre » possible. Pour plus d’infos à ce sujet, rendez-vous à la fin de ce premier article. VirtualBox est également disponible pour les autres OS courants.

Présentation du labo virtuel

Notre objectif est donc de mettre en œuvre un environnement de travail (labo) virtuel de base pour expérimenter diverses configurations systèmes & réseaux.

Il a été conçu pour demander de moins de ressources possibles, afin d’être déployé sur un PC standard à partir de solutions open source. Pour cela on va s’appuyer sur :

  • L’hyperviseur de niveau 2 VirtualBox
  • La solution pfSense® pour le cœur de réseau (interface WAN / LAN)
  • Debian GNU/Linux pour les systèmes (un serveur en mode console et un client en mode GUI (Interface Graphique pour l’Utilisateur).

Voici le schéma logique du labo virtuel que nous aurons mis en place à la fin de ce guide :


Versions

ElémentVersion
OS hôteMicrosoft Windows 11 Professionnel
Version 22H2 (Build OS 22621.963)
VirtualBox7.0.2
pfSense2.6.0
Debian Linux11.5 (Bullseye)
XFCE4.16
Versions des différents éléments logiciels utilisés

VirtualBox : l’hyperviseur

Téléchargement et installation

VirtualBox est un logiciel hyperviseur de niveau 2, libre et gratuit, il existe pour les environnements MS Windows, Mac OS X et Linux notamment.

Rendez-vous sur : https://www.virtualbox.org/

La page d’accueil du site officiel.

Après le téléchargement propre à votre environnement, procéder à l’installation avec les options par défaut proposées.

VirtualBox Extension Pack

Télécharger également le pack d’extensions, qu’il faut lancer après avoir terminé l’installation de VirtualBox :

La page des téléchargements, avec le pack d’extensions.

Personnalisation de VirtualBox

Il peut être intéressant de personnaliser certains paramètres de VirtualBox en fonction de vos habitudes ou environnement. Voici quelques exemples.

Touche « hôte »

La touche hôte permet de redonner la main à la machine hôte lorsque le clavier et/ou la souris sont « capturés » par la machine virtuelle. Par défaut c’est la touche Ctrl droite du clavier, mais si votre clavier n’a pas cette touche ou encore si vous êtes habitués au couple Ctrl + Alt de VMWare, on peut modifier ; appuyer sur Ctrl+G ou depuis le menu « fichier », cliquer sur « paramètres », puis sur l’onglet « entrée » :

La fenêtre de réglage des préférences de VirtualBox.

Emplacement par défaut

Autre élément intéressant, l’emplacement par défaut pour enregistrer les fichiers (machines et disques virtuels) ; cette option vous permet de stocker ces fichiers qui peuvent être volumineux sur un emplacement secondaire de votre machine hôte. Il est recommandé toutefois que cet emplacement soit rapide (de type SSD notamment).

Toujours dans les paramètres :

Sélection de l’emplacement par défaut des machines et disques virtuels.

Pourquoi préférer Oracle VirtualBox à VMWare Workstation ?

Voilà une question qui revient souvent quand il s’agit de choisir un environnement de virtualisation sur PC personnel. VirtualBox n’est pas forcément une préférence, c’est ici un choix orienté vers les solutions open source. Il y a des raisons pour préférer parfois VMWare Workstation à VirtualBox (meilleure gestion de la virtualisation imbriquée et meilleure stabilité graphique notamment). VirtualBox intègre en revanche des fonctionnalités de snapshot et de clonage, qui ne sont disponibles que dans les versions payantes de VMWare Workstation.

Trucs, astuces, limites et problèmes connus

Activer les fonctionnalités de virtualisation du processeur

Les processeurs actuels de la famille x86/x64, Intel ou AMD, intègre un jeu d’instructions complémentaire pour optimiser le fonctionnement de la virtualisation sur le système d’exploitation. Ces fonctionnalités s’appellent VT-x ou AMD-v et doivent être activées dans le micrologiciel du PC (BIOS / EFI). En général, elles le sont par défaut, mais il convient de vérifier au besoin (les hyperviseurs signalent en général assez clairement quand ces fonctions ne sont pas activées).

Activer la virtualisation imbriquée sous VirtualBox

Par défaut la virtualisation imbriquée (« nested virtualization ») n’est pas active sous VB. Si l’on souhaite réaliser une VM capable elle-même de réaliser de la virtualisation, l’option existe mais elle n’est pas accessible :

L’option « Activer VT-x/AMD-V imbriqué » est grisée, non accessible.

Pour l’activer, il faut utiliser la ligne de commande Windows :

> cd 'C:\Program Files\Oracle\VirtualBox'
> ./vboxmanage.exe list vms
…
"nom_de_la_VM" {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
…
> ./vboxmanage.exe modifyvm "nom_de_la_VM" --nested-hw-virt on

NB : la ligne de commande Windows n’est pas sensible à la casse, mais VirtualBox l’est : respecter la casse pour le nom de la VM.

Et ainsi :

L’option « Activer VT-x/AMD-V imbriqué » est est désormais activée pour la VM.

Notons que la virtualisation imbriquée est un « montage » délicat. Depuis quelque temps, installer ProxMoxVE sous VB fonctionne, mais les VM créées sous PVE ne fonctionnent pas (c’est peut-être un bug temporaire). De même, l’installation de VMWare ESXi ne fonctionne pas.

Les VM créées sous VirtualBox se plantent au démarrage

Après une installation réussie, certaines VM après le démarrage se plantent avec des messages d’erreur système assez « dramatiques » : kernel panic et autres. Il y a plusieurs choses à faires :

1 – désactiver les fonctionnalités de virtualisation de Windows

Tapez la touche Windows + R, puis appwiz.cpl et Entrée (ceci lance le panneau de configuration, section « programmes et fonctionnalités »)

Cliquer sur « activer ou désactiver des fonctionnalités Windows » :

Dans la liste, décocher ces fonctionnalités si elles sont actives :

  • hyperV
  • plateforme de l’hyperviseur Windows
  • plateforme de machine virtuelle
  • sous-système linux

2 – désactiver l’isolation du noyau (core isolation)

Cette fonctionnalité de sécurité Windows assez récente empêche la plupart du temps VirtualBox de fonctionner correctement.

Rechercher « core isolation » dans la barre de recherche de Windows, et désactiver l’option :

La fonctionnalité d’isolation du noyau.

Et ensuite ?

Rendez-vous maintenant au prochain article pour l’installation de la première VM de notre labo : pfSense.

Routage IP avec Linux et iproute2

Présentation

Je vous propose d’expérimenter le routage IP sous Linux (Debian), grâce aux outils de la suite iproute2, afin de mieux comprendre ce mécanisme essentiel du niveau 3 de l’OSI.

  • Nous allons dans un premier temps installer un environnement de travail virtuel avec deux réseaux locaux « fermés » (LAN1 et LAN2) et trois machines légères : une dans chaque LAN et une avec « une patte » dans chaque réseau local.
  • Puis nous mettrons en œuvre un routage statique entre ces deux réseaux.

Il est recommandé de connaître le Protocole Internet (IP) et le principe du routage associé. Pour plus de clarté, nous n’utiliserons dans ces travaux que le protocole IPv4 ; le principe reste le même pour IPv6.

A propos d’iproute2

On désigne par iproute2 est une collection d’utilitaires pour la gestion des protocoles TCP, UDP, IP et la gestion du réseau sous Linux, supportant l’IPv4 et l’IPv6. La collection iproute2 est destinée à remplacer toute une suite d’outils réseau standard Unix (appelée net-tools) qui étaient anciennement utilisés pour les tâches de configuration d’interfaces réseau, tables de routage, et gestion de table ARP. La suite net-tools est dépréciée, il est recommandé de ne plus l’utiliser.

Voici quelques exemples d’outils net-tools remplacés par iproute2 :

UsageAncien outil net-toolsCommande iproute2
Adressage (niv. 2)ifconfigip link
Adressage (niv. 3)ifconfigip addr
Routagerouteip route
Résolution d’adressesarpip neigh
VLANvconfigip link
Tunnelsiptunnelip tunnel
Multicastipmaddrip maddr
Statistiquesnetstatss
Source : Wikipedia

Préparation

Nous allons utiliser notre logiciel hyperviseur préféré pour créer trois machines GNU/Linux minimales  :

Nom de la VMhostname Unix
Debian AdebianA
Debian BdebianB
Debian XdebianX
Nous aurons besoin de trois machines virtuelles Debian minimales.

Pour créer ces machines, voir le tutoriel de référence dédié à cela. Les caractéristiques communes initiales de nos trois machines sont :

  • 1 CPU
  • 1 GB RAM
  • 1 HDD 10 GB
  • 1 interface réseau en mode NAT

Préparation des VM

Le PC hôte de nos VM doit être connecté à Internet afin que chaque VM soit elle-même connectée à Internet via la connexion NAT (recommandé) ; il est possible aussi d’utiliser le mode bridge (pont) sur l’interface physique connectée à Internet.

Toutes les commandes à suivre sont réalisées en mode console, connecté avec l’utilisateur root.

On vérifie la connexion à Internet, en testant la connexion à une adresse IP externe connue (ici le DNS Cloudflare) :

# ping 1.1.1.1
Un ping 1.1.1.1 fonctionnel ; on le stoppe avec [CTRL]-[C]

et à un DNS fonctionnel :

# ping debian.org
ping avec résolution de nom (debian.org renvoie ici à l’IP publique 130.89.148.77)

On commence par les opérations classiques de mise à jour. On met à jour la base de données du gestionnaire de paquets Debian :

# apt update
# apt update ; le résultat indique ici qu’il y a des paquets qui peuvent être mis à jour.

Puis on procède aux mises à jour s’il y en a :

# apt upgrade
# apt upgrade met à jour ici deux paquets.

Éventuellement un peu de ménage (dans notre cas c’est juste pour rappeler les commandes ; et encore, on pourrait aller plus loin à ce sujet) :

# apt clean
# apt autoremove

Enfin, on installe sur chaque machine les utilitaires tcpdump et traceroute :

# apt install -y tcpdump traceroute

Ces opérations sont à faire pour chaque VM ; on peut aussi le faire pour une, puis la cloner deux fois (attention à bien générer de nouvelles adresses MAC pour les interfaces réseau).

Connexion des cartes réseau aux segments LAN

Une fois les trois machines préparées, il faut les éteindre :

# poweroff

Il faut maintenant modifier le « hardware virtuel » des VM afin de créer l’infrastructure suivante (on utilise les réseaux internes de l’hyperviseur) :

Attention, dans cette configuration, les machines ne seront plus connectées à Internet.

Voici la configuration sous VirtualBOX de l’interface réseau de debianA connectée au réseau interne LAN1 :

Puis la configuration pour debianB qui est sur LAN2 :

La machine debianX quant à elle dispose de deux cartes réseau, une sur chaque LAN :

La carte 1 sur le LAN1, on repère l’adresse MAC.
La carte 2 sur le LAN2.

Enfin, nous modifions le nom de chaque machine (hostname), si besoin (notamment si vous avez procédé par clonage ; car lors de l’installation Debian, le nom de machine est demandé)  :

A# echo "debianA" > /etc/hostname

NB : par convention, quand c’est utile, je fais précéder le prompt (# ou $) du nom de la machine concernée (A, B, ou X)

B# echo "debianB" > /etc/hostname
X# echo "debianX" > /etc/hostname

Est-ce suffisant pour modifier correctement le nom des machines ? Nope. Il y a un autre fichier qui contient le hostname, afin de le résoudre avec l’ip 127.0.1.1. C’est le fichier primaire de résolution DNS : /etc/hosts. Si on ne fait pas cette modification, on aura par exemple des erreurs avec la commande sudo qui affichera systématiquement :

sudo: impossible de résoudre l'hôte debianX: Nom ou service inconnu

Utilisons l’outil sed, en présumant que nous avons nommé la machine debian lors de l’installation. Pour chaque machine A, B et X :

A# sed -i 's/debian/debianA/g' /etc/hosts
B# sed -i 's/debian/debianB/g' /etc/hosts
X# sed -i 's/debian/debianX/g' /etc/hosts

Les machines doivent être redémarrées pour que le hostname soit pris en compte :

# reboot

Configuration des adresses IP

Nous utiliserons donc la suite de commandes iproute2, devenue le standard sur les systèmes GNU/Linux.

La commande ip link show (que l’on peut abréger avec ip link et même ip l), permet d’afficher les interfaces disponibles. Ajoutons l’option -c pour avoir un peu de couleur :

X# ip -c l
Nous voyons les deux interfaces Ethernet de debianX. Bien repérer leurs noms ; ici : eth0 et eth1

Grâce aux adresses MAC, on peut valider quelle interface est en lien avec quel réseau. Ici, eth0 (adresse MAC 08:00:27:83:7C:BB) est clairement la carte qui est connectée au LAN1, selon le repérage effectué juste avant.

La carte eth1 est DOWN, car elle a été ajoutée après l’installation, donc non préconfigurée, et elle n’est pas encore configurée dans le système.

Nous pouvons attribuer l’adresse IPv4 192.168.10.1/24 à la machine A sur son interface eth0 (si c’est son nom ; avec vmware workstation par exemple, elle aurait pu s’appeler ens32) :

A# ip addr add 192.168.10.1/24 dev eth0
A# ip -c a

Cependant, cette configuration ne sera pas persistante au prochain redémarrage du système.

Pour ce faire, il faut modifier le fichier de configuration des interfaces réseau :

A# nano /etc/network/interfaces 

L’écran d’édition doit proposer quelque chose de ce genre ; il faut modifier les paramètres (en gras) de l’interface réseau primaire (en conservant le nom de l’interface sur votre système, il est possible que ce soit plutôt enp0s3 ou ens32 que eth0) :

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.10.1/24

NB : nano est dans ce cas l’éditeur de texte, mais ça peut être un autre, comme vi ou vim.

NB : la configuration de l’interface primaire est précédée de celle de la boucle « loopback » (lo) et de quelques commentaires . Attention aux erreurs de frappe qui « décommentent » par mégarde certaines lignes dans les fichiers de configuration… et plantent l’initialisation correcte du système (une cause fréquente est l’état de cette satanée touche VERR.NUM…)

Après un reboot de la machine, la configuration IPv4 est validée :

Il nous faut paramétrer maintenant les autres machines. D’abord la debianB :

B# nano /etc/network/interfaces 
...
allow-hotplug eth0
iface eth0 inet static
address 192.168.11.1/24

Puis la debianX, avec ses deux cartes eth0 et eth1 :

X# nano /etc/network/interfaces 
...
allow-hotplug eth0
iface eth0 inet static
address 192.168.10.254/24

allow-hotplug eth1
iface eth1 inet static
address 192.168.11.254/24

et voilà pour la debianX (après un reboot bien sûr) :

Test de fonctionnement

Une fois tout cela en place, il doit être possible de « pinger » la machine X depuis la machine A :

A# ping 192.168.10.254

Et de « pinger » la machine X depuis la machine B :

B# ping 192.168.11.254

Et enfin de « pinger » les machines A et B depuis la machine X :

X# ping 192.168.10.1
X# ping 192.168.11.1

Cependant, il n’est (normalement) pas possible de pinger la machine B depuis la machine A :

A# ping 192.168.11.1

En effet, la machine debianA ne « connaît » pas ce réseau 192.168.11.0/24, et encore moins le moyen de s’y rendre.

Petit focus sur le voisinage réseau (ARP)

Regardons quelques commandes iproute2 qui permettent de gérer le cache ARP de la machine. En effet, chaque machine disposant d’une pile (stack) IP gère une table d’association [adresse MAC] <> [adresse IP]. Chaque entrée de cette table a par ailleurs une durée de vie limitée. Essayez ces quelques commandes :

A# ping 192.168.10.254
A# ip neigh
A# ip n
A# ip n flush all
A# ip n
A# ping -c 1 192.168.10.254 && watch ip n

Avec la dernière commande, vous pourrez normalement voir l’évolution d’une entrée ARP entre les états DELAY, REACHABLE (atteignable) et STALE (périmé).

On peut aussi créer une association permanente (attention c’est touchy) :

A# ip n add 192.168.10.254 lladdr 08:00:27:83:7C:BB dev eth0
A# ip n flush all
A# ip n
A# ip n del 192.168.10.254 lladdr 08:00:27:83:7C:BB dev eth0
A# ip n

L’usage d’entrées ARP permanentes peut avoir deux raisons :

  • éviter dans un réseau très dense des requêtes ARP,
  • empêcher l’ARP « spoofing », où des machines se font passer pour d’autres lors des requêtes ARP.

Mise en place du routage sur la machine debianX

Par défaut, le routage n’est pas activé sur une machine Linux standard, et notamment ici sur la machine debianX. Il faut donc activer le routage IPv4 sur notre machine X :

X# sysctl -w net.ipv4.ip_forward=1

Profitons-en au passage pour désactiver intégralement la gestion de l’IPv6 sur notre machine (quand on n’a pas envie de gérer quelque chose, il vaut mieux le désactiver que de laisser les réglages par défaut) :

X# sysctl -w net.ipv6.conf.all.disable_ipv6=1

Les commandes sysctl permettent de configurer certaines fonctions du noyau Linux. Les deux commandes que nous venons de lancer fonctionnent, mais ne sont pas persistantes. Pour ce faire, il faut modifier le fichier adéquat :

X# nano /etc/sysctl.conf

et ajouter les deux lignes suivantes :

net.ipv4.ip_forward=1
net.ipv6.conf.all.disable_ipv6=1

Il est probable que la première existe déjà dans le fichier, mais qu’elle soit commentée (et donc désactivée). Puis on relance la machine X, et on vérifie que le routage IPv4 est activé, et qu’il n’a plus d’adresse IPv6 :

X# reboot
...
X# sysctl net.ipv4.ip_forward
X# ip -c a

Tables de routage

Quelle commande permet d’afficher la table de routage actuelle de chaque machine ?

# ip route

Ce qui doit nous donner, pour chacune des machines A, B, X :

192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.1
192.168.11.0/24 dev eth0 proto kernel scope link src 192.168.11.1
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.254
192.168.11.0/24 dev eth1 proto kernel scope link src 192.168.11.254

Lancer l’utilitaire tcpdump sur la machine X afin de visualiser les paquets ICMP qui transitent sur son interface reliée à LAN1 (donc sur l’interface eth0) :

X# tcpdump -i eth0 icmp

Quelle est la commande pour activer un routage IP de la machine A vers la machine B ?

A# ip route add 192.168.11.0/24 via 192.168.10.254 dev eth0

Traduction : pour joindre le réseau 192.168.11.0/24, il faut passer par la passerelle (gateway) 192.168.10.254, via l’interface eth0 (rappel évident : une passerelle doit toujours faire partie d’un réseau auquel je suis directement connecté).

Que donne un ping de A vers B désormais ?

A# ping 192.168.11.1

ça ne fonctionne pas. Si on analyse les résultats affichés sur le tcpdump qui tourne sur X, on devine la cause du problème. Il ne faut pas oublier qu’un ping c’est une demande (request) de A vers B, suivi d’une réponse (reply) de B vers A, pour valider la bonne connexion de niveau 3 (IP). Il manque donc ici le message retour de B vers A, donc la route de B vers A.

Quelles est la commande pour activer un routage IP de la machine B vers la machine A ?

B# ip route add 192.168.10.0/24 via 192.168.11.254 dev eth0

Et c’est la joie dans la place ! la route est en place de bout en bout :

Capture d’écran de la machine routeur debianX, avec tcpdump

La commande traceroute permet de savoir le chemin emprunté pour joindre la machine distante :

A# traceroute 192.168.11.1

On voit clairement que le paquet est d’abord passé par la machine X, avant de joindre la machine B :

Persistance des routes statiques

Après avoir contemplé la magie du routage IP (ce mécanisme est le fondement de la majorité des échanges sur Internet), nous ne saurions être pleinement satisfait si les routes statiques que nous avons réalisées n’étaient pas persistantes.

Qu’à cela ne tienne.

Nous allons nous rendre dans le répertoire du système prévu justement pour des scripts qui sont exécutés à chaque fois qu’une interface du réseau est « up » :

A# cd /etc/network/if-up.d

Et ajoutons un script pour chaque machine (ici la debianA) :

A# nano route_x

A priori, on l’imagine simplement contenant deux lignes :

  • Le « shebang » qui indique que c’est un script texte et le shell à utiliser
  • La commande d’ajout de la route
#!/usr/bin/env bash
ip route add 192.168.11.0/24 via 192.168.10.254 dev eth0

Il ne faut pas oublier de le rendre exécutable :

A# chmod +x route_x

Après redémarrage de la machine, vous pourrez vous rendre compte que ça ne fonctionne pas très bien… Si, si. La route statique existe, sans doute, mais vous aurez aperçu un petit [FAILED] dans la séquence de démarrage, et le service networking est en réalité HS, voyez par vous-même :

# systemctl status networking

En fait, ce script, que l’on voit de-ci de-là comme solution pour une route statique, n’est pas satisfaisant.

D’abord, dans un script, il faut prendre la bonne habitude d’écrire les commandes avec un chemin absolu, et non relatif, comme ici (« ip … »), donc déjà :

#!/usr/bin/env bash
/sbin/ip route add 192.168.11.0/24 via 192.168.10.254 dev eth0

D’autre part, les scripts présents dans if-up.d sont lancés pour chaque interface qui passe UP, ainsi qu’une fois supplémentaire quand toutes sont UP. A chaque fois, la variable $IFACE contiendra le nom de l’interface en question (et aura la valeur « –all » pour le dernier cas).

Notre script sera donc plus correct ainsi :

#!/usr/bin/env bash
if [ "$IFACE" = "eth0" ] ; then
  /sbin/ip route add 192.168.11.0/24 via 192.168.10.254 dev eth0
fi

Relancer les machines, et vérifier que cette fois, tout est fonctionnel, sans erreur, paisible et serein.

Est-ce la seule méthode ?

Il existe (au moins) une autre méthode pour créer cette route statique persistante : au lieu de créer un script dans le répertoire if-up.d, on peut insérer la commande de création de la route directement dans le fichier de configuration des interfaces, grâce à la directive post-up :

Par exemple ici pour la machine A (fichier /etc/network/interfaces):

...
allow-hotplug eth0
iface eth0 inet static
address 192.168.10.1/24
post-up /sbin/ip route add 192.168.11.0/24 via 192.168.10.254 dev eth0

Conclusion

Nous avons donc pu au travers d’une maquette simple expérimenter les fondamentaux du routage avec Linux, utiliser quelques outils iproute2 et aborder quelques point importants. J’espère que ce tutoriel vous aura plu.

Pour en savoir plus sur iproute2 : https://inetdoc.net/guides/lartc/lartc.iproute2.html ainsi que https://manpages.debian.org/bullseye/iproute2/index.html

Pour en savoir plus sur la gestion des interfaces réseau : https://manpages.debian.org/bullseye/ifupdown/interfaces.5.en.html

Dernière mise à jour : 29/01/2023