Labo virtuel personnel – troisième partie : installation de Debian Core (mode serveur)

Nous allons créer une VM dotée du système d’exploitation GNU/Linux, selon la distribution assez universelle Debian, dans un mode minimal (ou « core »). Cette configuration est idéale pour déployer un serveur basé sur GNU/Linux.

Image ISO d’installation

Il faut tout d’abord récupérer l’image ISO d’installation de Debian, dernière version, pour architecture x64. On prend la version minimale « net install » : les compléments seront téléchargés lors de l’installation (une connexion à Internet est nécessaire).

Le nom du fichier ISO est de cette forme : debian-x.x.x-amd64-netinst.iso

On trouve cette image à l’emplacement suivant (en bas de page) :

https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/

Vérification de l’image téléchargée (option recommandée)

Sur le site indiqué, on peut aussi récupérer les hash SHA256 des images, afin de contrôler l’intégrité du fichier téléchargé. Le fichier des hash est SHA256SUMS

La page web de téléchargement des ISO Debian GNU/Linux

Vérification sous Windows avec l’utilitaire hashcheck (ajoute un onglet « Hachages » sur les propriétés du fichier) :

C’est toujours une bonne précaution de vérifier la signature d’un téléchargement.

Création et configuration de la VM

Depuis VirtualBox, taper CTRL+N (ou menu Machine / Nouvelle), puis choisir le « mode expert » ; attention à bien cocher l’option « skip Unattended Installation ». En effet, on souhaite maîtriser complètement le processus d’installation :

On affecte 1024 MO de RAM et un cœur de CPU :

Configuration de la partie « compute » ; on utilise ici un BIOS standard (legacy) et non EFI, mais c’est juste par habitude. Debian supporte très bien le mode EFI.

Et on crée un nouveau disque VDI de 20 Gio :

configuration de la partie « storage »

On clique « finish » : la machine est créée.

Configuration de la VM

Cliquer sur Configuration, on obtient la page des paramètres de la VM :

Dans la rubrique « Système », choisir une souris PS/2, ceci permettra plus loin de pouvoir désactiver les contrôleurs USB :

On désactive le matériel audio, inutile dans notre cas :

Un principe basique de sécurité informatique : ce qui n’est pas utile doit être désactivé.

Notre VM doit ultimement être connectée sur le LAN, mais pfSense n’a pas encore été configuré, on va donc utiliser pour le moment une connexion de type « NAT » afin qu’elle ait accès à Internet :

La section « advanced » permet notamment de choisir le type d’interface matérielle (laisser par défaut) et de récupérer (ou modifier) l’adresse MAC de cette interface.

On retire l’USB inutile :

La machine est prête. On la lance :

Installation de Debian en mode « core »

Pour la phase d’installation on peut utiliser le mode graphique qui est plus confortable ; voici quelques-unes des étapes importantes :

Il ne faut confondre installation en mode graphique et installation d’une interface graphique sur le système final (cette option est choisir plus loin).

L’écran est un peu différent si on a activé le mode EFI :

Valider plusieurs fois de suite les options linguistiques (France)

La détection automatique des paramètres réseau doit se passer sans encombre si la machine est bien connectée à Internet.

Définir le hostname (nom de la machine) : debian

définition du hostname (nom de la machine)

Domaine : on laisse vide

Mot de passe pour le super-utilisateur root (par exemple simplement « root » car il s’agit de tests uniquement. En production, il faudra quelque chose de plus élaboré : 12 caractères (min, maj, chiffres, caractères spéciaux)

Il est également possible de ne pas saisir de mot de passe pour l’utilisateur root, auquel cas ce compte sera désactivé, et le compte utilisateur défini ensuite aura des droits « d’élévation » (sudoer) pour accéder aux privilèges de root. Ceci peut être utile en mode production, mais pour notre cas, nous activons le compte root :

définir le mot de passe root active le compte root.

On déclare aussi un utilisateur standard (remplacer bien sûr pascal par vos propres prénom et nom) :

Le système propose alors un login (identifiant) ; là aussi utiliser quelque chose qui vous est propre (prénom), mais attention, les caractères utilisables sont limités :

Et mot de passe (idem, rester simple pour les tests) :

Pour le partitionnement et le formatage du disque, on conserve les propositions par défaut :

Attention ici l’option proposée par défaut sera « Non », car cette action efface le disque concerné ; il faut donc choisir « Oui » :

Oui, oui, on veut bien effacer le disque (qui d’ailleurs est totalement vide).

L’installation du système de base commence…

Pas d’autre CD ou DVD supports d’installation, le reste se fera en ligne, via un site de dépôt :

Choix d’un miroir (site de téléchargement des paquets Debian) :

Pas de proxy (sauf cas très particulier lié à votre environnement) :

laisser la zone vide, et continuer.

L’installateur configure le gestionnaire de paquets, puis propose de participer aux statistiques d’utilisation des paquets :

au libre choix de chacun de participer à ces statistiques, consultables sur https://popcon.debian.org

Puis l’installateur propose d’installer des paquets complémentaires, on désélectionne tout (en effet, on veut l’environnement le plus léger possible) :

on ne conserve aucune option, même si certaines semblent pouvoir être utiles plus tard.

Puis enfin, l’installation de GRUB (cette étape n’existe pas si on a choisi l’option EFI) :

Sans installation de GRUB, le système ne démarrera pas !
choisir le disque principal (et unique) pour l’installation de GRUB

L’installation est terminée :

En cliquant sur « continuer », la VM redémarre.

La machine est en mode console, et invite à entrer un login. On se logue en root :

puis on vérifie qu’une IP a bien été attribuée (DHCP) :

# ip -c a

On peut aussi vérifier la connectivité à Internet et la résolution de nom DNS :

# ping 1.1.1.1
# ping debian.org

On lance ensuite les mises à jour :

# apt update
# apt upgrade

Puis on éteint la VM :

# poweroff

Il reste à supprimer le lecteur optique du système ainsi que son contrôleur, devenus inutiles :

Sauvegarde de l’état de la VM

Puis enfin, prendre un instantané (snapshot) de la machine dans cet état initial, pour pouvoir y revenir ensuite, ou réaliser des clones :

donner un nom au cliché, par exemple « post installation ».

Et voilà notre VM terminée ! J’espère que tout s’est passé sans problème pour vous.

Ce genre de machine Debian « core » est la base idéale pour déployer des services : serveurs de base de données, serveur HTTP, Docker, …

Nous utiliserons cette référence pour nos prochaines expériences.

La prochaine étape : cloner cette Debian basique, et lui apporter un environnement du bureau ultra-léger (XFCE4), afin de disposer dans notre labo d’une machine de type « client ». Son rôle sera de nous offrir un environnement graphique (GUI) pour pouvoir administrer « confortablement » à distance les machines de type « serveur », tout en mobilisant le moins de ressources possibles (empreinte légère).

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