Labo virtuel personnel – dernière partie : finalisation

Dans cette dernière partie, nous allons finaliser notre labo virtuel :

  • Intégration des VM dans le réseau interne virtuel LAN
  • Configuration de base de pfSense

Dans un premier temps il faut bien sûr veiller à ce que les trois machines soient démarrées.

Sur la console de la VM pfSense on voit que l’interface WAN connectée en NAT a obtenu par DHCP une adresse IPv4 fournie par VirtualBox, et que l’adresse IP sur la « patte » LAN est 192.168.1.1/24 :

La console pfSense

La VM Debian GUI est connectée en NAT, son interface réseau a donc elle aussi obtenu par DHCP une adresse IPv4 depuis VirtualBox. On peut démarrer un terminal, et vérifier l’IP obtenue :

$ ip -c a
Pratique : avec la touche Ctrl et la molette de la souris, on ajuste la taille du texte dans le terminal.

Cette commande nous donne (en couleur grâce à l’option -c) les adresses IP de chaque interface réseau du système.

Connexion de DebianGUI au réseau LAN

Cette opération peut se faire « sous tension », comme on le ferait avec une machine réelle, en reconnectant le câble réseau. Depuis la configuration de la VM, on connecte l’interface réseau au réseau interne LAN :

Reconnexion de l’interface sur le LAN

Il faut maintenant renouveler le bail DHCP de la VM GUI, en deux temps. D’abord on redémarre le service réseau :

$ sudo systemctl restart networking

Puis on demande un nouveau bail :

$ sudo dhclient

NB : on aurait pu aussi simplement redémarrer la VM.

Désormais notre DebianGUI est sur le réseau LAN et a obtenu une IPv4 depuis pfSense.

Configuration de pfSense par WebAdmin

On peut maintenant utiliser le navigateur WEB pour procéder à la configuration initiale de pfSense, à l’adresse https://192.168.1.1 :

Comme nous utilisons une IP privée locale comme adresse source HTTP, on a bien sûr l’avertissement habituel sur les risques d’un certificat auto-signé. Nous acceptons ce « risque », et nous voilà sur la page de connexion à pfSense :

Par défaut, l’identifiant est admin et le mot de passe pfsense.

L’assistant d’installation initiale (Wizard)

Au premier lancement, le « wizard » de configuration apparaît (il est également possible de l’appeler plus tard depuis le menu system) :

Nous allons donc procéder à la configuration initiale élémentaire de pfSense, qui sera notamment très permissive au niveau du pare-feu (par défaut).

Le bouton « next » nous amène à la suite :

Netgate, l’éditeur, propose de considérer la souscription au support avancé pour pfSense. On laisse ensuite le hostname et le domaine proposés, et on fixe les serveurs DNS que nous souhaitons utiliser :

Attention, selon votre environnement, il est possible que ces DNS vous soient imposés ; il convient de saisir ici les valeurs adéquates. Par défaut, nous pouvons prendre les DNS de CloudFlare (1.1.1.1 et 1.0.0.1). Il faut décocher l’option « override » pour que nos choix DNS ne soient pas remplacés par ceux fournis par le WAN (par DHCP).

On définit ensuite le serveur NTP principal que va utiliser pfSense, ainsi que la timezone de notre système. On prend ici des réglages adaptés à la France.

serveur NTP : 0.fr.pool.ntp.org

L’étape suivante concerne le paramétrage de l’interface WAN ; celle-ci utilise DHCP pour sa configuration.

Sur cette page on veillera aussi à désactiver le blocage des flux RFC1918 (plages d’adresses IP privées) arrivant sur le WAN ; en effet ce genre de situation peut se produire, et d’ailleurs dans le cas présent l’interface WAN est sur un réseau privé.

On peut également débloquer les réseaux Bogon notamment si on est amené à utiliser des plages IP réservées à des usages de test (comme celles de la RFC5737), ou plus généralement si on veut lever toute restriction initiale sur le pare-feu.

L’étape suivante consiste à renseigner (confirmer) l’adresse IP de pfSense sur le réseau LAN. Laissons ce réglage intact :

Enfin, il convient de personnaliser le mot de passe associé à l’utilisateur admin. En réalité, les bonnes pratiques de sécurité obligent même à désactiver ce compte et à en créer un autre ; nous ferons cela un peu plus loin. Pour le moment, limitons-nous à modifier ce mot de passe.

Il ne reste plus qu’à recharger le système avec cette nouvelle configuration.

Et voilà ! le système est (presque) configuré, on clique sur « finish ».

La dernière étape de l’assistant de configuration.

L’affichage de ce « placard » informatif est notamment le signe que le système accède à Internet. On est invité à accepter les conditions, puis encore une invitation à participer à l’amélioration du système, et on arrive sur le dashboard par défaut :

le dashboard (ou tableau de bord) de pfSense

Personnalisation du tableau de bord

Le tableau de bord peut afficher des informations plus pertinentes que les informations relatives à Netgate (dont vous pouvez prendre connaissance malgré tout !).

Utiliser les croix en haut à droite de chaque élément du dashboard, puis l’option + pour en ajouter, comme celui qui permet de visualiser l’état des passerelles (gateways) ou l’activité sur les interfaces (traffic graph) :

Des widgets sont disponibles pour personnaliser le dashboard.

Voici un dashboard plus informatif. Il est possible de déplacer les éléments, il ne faut pas oublier alors d’enregistrer cette disposition avec l’icône « disquette » en haut à droite.

Configuration complémentaire

Il convient de réaliser quelques opérations supplémentaires pour finaliser la configuration initiale.

Activer le chiffrement matériel avec AES-NI

La plupart des CPU actuels disposent d’un jeu d’instructions AES-NI pour le chiffrement symétrique, lequel est notamment utilisé lors de connexions VPN. Par principe, on l’active d’emblée sur une nouvelle instance pfSense. On vérifie d’abord que l’option est disponible, depuis le dashboard > system information > CPU Type > AES-NI > Yes (inactive)

Si c’est “Yes” (comme sur la capture ci-dessus), on l’active :

Menu system > advanced > Miscellaneous > Cryptographic & thermal sensor :

On active AES-NI, et on clique sur « save » en bas de page.

Désormais, la mention « active » est présente sur le dashboard dans la section CPU > AES-NI.

Désactivation de l’admin par défaut

On va créer un utilisateur administrateur et désactiver le compte admin par défaut. Menu system > user manager > users > add :

Créer l’utilisateur (username et mot de passe au moins) et l’ajouter au groupe admins :

Puis sauvegarder.

Se déconnecter de l’admin actuel (icone en haut à droite de la page), puis se reconnecter avec ce nouvel utilisateur.

Désactiver maintenant l’utilisateur admin standard :

Sauvegarder.

Désactivation d’IPv6 sur le WAN

Notre interface WAN ne dispose que d’une IPv4 ; pour plus de clarté, on va désactiver la gestion de l’IPv6 sur cette interface.

Menu interfaces > WAN

Sauvegarder et appliquer les changements.

Désactivation du DNS resolver

De nombreux services sont activés sur pfSense pour assurer la gestion du réseau (DHCP, NTP, DNS, FIREWALL, …). Pour alléger le fonctionnement du DNS, qui est la source de bien des soucis (« it’s always DNS ! »), on va désactiver le serveur DNS intégré (résolveur). Les requêtes DNS seront gérées directement par les serveurs externes prédéfinis plus haut.

Menu Services > DNS resolver

Sauvegarder et appliquer les changements.

Tout ceci n’est peut-être pas exhaustif ou parfait, mais c’est basé sur l’expérience, et le fait qu’on soit sur un labo. Par exemple, sur un pfSense en production, on pourra notamment protéger le menu de la console par un mot de passe (menu system > advanced > admin access) :

Afin de propager les réglages DNS notamment, il convient de redémarrer la VM Debian_GUI

Connexion de Debian serveur dans le LAN

Il faut également redémarrer la Debian Core, après l’avoir elle aussi reconnectée sur le réseau interne LAN.

Contrôle final

Maintenant, les machines accèdent à internet via pfSense.

DebianGUI navigue sur le WEB
et la Debian core accède elle aussi à Internet (ping d’un nom de domaine : résolu et joignable)

On récupère l’IP de la VM Debian Core avec la commande ip -c a ; ici 192.168.1.104. On peut constater qu’elle est joignable depuis la machine GUI :

L’adresse IP de DebianGUI est 192.168.1.103 ; les ping vers 192.168.1.104 fonctionnent.

Tout est en place ! Notre labo est fin prêt pour ses premières expériences. Je vous recommande de faire un cliché instantané (snapshot) de chacune des VM à ce stade.

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 un clone intégral :

Un clic sur « Finish » (les traductions ne sont pas terminées semble-t-il ;-), et VirtualBox crée une nouvelle VM par clonage.

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, depuis la configuration de la VM :

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.

Vous me direz : « Ne devrions-nous pas ajouter un peu de ressources à cette VM ? Un CPU et un gigaoctet de RAM pour machine avec interface graphique, c’est un peu léger, non ? »

Eh bien… non, ça ira, vous verrez.

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

Le premier caractère de la ligne ci-dessus représente le prompt (l’invite de commande), ici en mode root (#) ; il ne faut bien entendu pas le saisir. Avec l’éditeur nano, 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 souvent des désagréments.

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 dkms
$ sudo mkdir -p /mnt/cdrom
$ sudo mount /dev/cdrom /mnt/cdrom
$ cd /mnt/cdrom
$ sudo sh ./VBoxLinuxAdditions.run
$ sudo reboot

On peut remarquer que désormais l’interface graphique s’ajuste à la taille de la fenêtre. Il peut être (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 :

Sauvegarde de l’état de la VM

Ne pas oublier d’éteindre et de prendre un cliché instantané de cette machine cliente, pour pouvoir la restaurer dans cet état propre, 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 – 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-12.5.0-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 :

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

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. On utilise ici un BIOS standard (legacy) et non EFI, mais c’est juste par habitude, car Debian supporte le mode EFI :

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

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 :

Notre VM devra au final ê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 accède à Internet :

On retire l’USB inutile :

La machine est prête. On clique OK, puis on la lance :

Installation de Debian core

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

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). On peut utiliser simplement debian :

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é : au moins 12 caractères (minuscules, majuscules, chiffres et 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 :

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 :

  • Assisté – utiliser un disque entier
  • Tout dans une seule partition

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

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) :

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) :

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

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 :

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 reconnue et spécialisée dans 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/

Edit 16/05/2024 : Netgate semble proposer désormais de télécharger un installateur universel pfSense. J’ai essayé, ça n’a pas fonctionné (pendant l’installation, validation impossible). En attendant du nouveau, il est toujours possible de récupérer les installateurs classiques (offline) sur ces deux miroirs :

L’image récupérée est pfSense-CE-2.7.2-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 :

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

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) ; on utilise ici le mode Expert pour la configuration :

On lui octroie ensuite dans les onglets « hardware » et « Hard Disk » 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.
  • On ne choisit pas l’option EFI (même si celle-ci est supportée par pfSense)
Choix de la RAM allouée et du nombre de cœurs CPU

Un petit clic sur « Finish » et notre 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 :

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

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 en amont ne voit que notre 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 virtuel 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 modifier) l’adresse MAC de l’interface virtuelle ; ceci peut être très utile au moment de configurer le système qui sera installé sur la VM :

Installation de pfSense

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

Et après la phase de démarrage sur l’image ISO d’installation, l’écran d’accueil s’affiche :

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) :

… pour éteindre la VM.

La VM s’éteint.

On supprime le lecteur optique devenu inutile :

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

Affectation des interfaces

Normalement, 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 :

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). Comme évoqué plus haut, c’est avec les adresses MAC que nous pouvons identifier chaque interface dans VirtualBox.

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 configure 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è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 » :

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

Notre VM pfSense est maintenant opérationnelle. Sa configuration initiale 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

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, basé sur VirtualBox. Cet hyperviseur de niveau 2 est une solution reconnue, 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 (distributions GNU/Linux et Mac OS X)

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 23H2
VirtualBox7.0.12
pfSense2.7.2
Debian Linux12 (BookWorm)
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 GNU/Linux notamment.

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

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

VirtualBox Extension Pack (optionnel)

Télécharger également le pack d’extensions, qu’il faut lancer après avoir terminé l’installation de VirtualBox ; il apporte des fonctionnalités diverses qui peuvent servir dans certains cas, mais que nous n’utiliserons pas dans la suite de nos travaux.

Personnalisation de VirtualBox

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

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 des réseaux privés hôte, meilleure stabilité graphique, …). 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, et mes derniers essais avec MS Hyper-V ont été plutôt décevants…

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 « isolation du noyau » dans la barre de recherche de Windows, et désactiver l’option :

Et ensuite ?

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

Skeleton lance une superbatterie qui se charge en 30 secondes

Skeleton Technologies a lancé sa «superbatterie» à charge rapide qui s’appuie sur sa technologie de supercondensateur.

La batterie de 2,25 V peut se recharger en 60 secondes pour permettre jusqu’à 30 minutes de conduite avec un taux de charge maximal de 100 C. Le taux de charge continue est de 20C, avec une durée de vie de 50 000 cycles de charge/décharge, dix fois celle des batteries Lithium-Ion, offrant une durée de vie beaucoup plus longue. La cellule de batterie a une densité de puissance de 10kW/kg et une densité d’énergie de 65Wh/kg.

Skeleton en Allemagne est l’un des principaux développeurs et fabricants de supercondensateurs dans le cadre d’accords avec Siemens et d’autres fournisseurs.

La conception n’utilise pas de cobalt, de nickel, de graphite ou de cuivre, mais plutôt son graphène incurvé. Il utilise également moins de 5% de lithium et ne souffre donc pas d’emballement thermique, il n’est donc pas nécessaire de prendre des mesures de propagation thermique.

La densité d’énergie et la plage de température étendue de -30 à +50 C signifient que la batterie est testée dans des véhicules électriques hybrides et à pile à combustible, des bus, des camions et des infrastructures de recharge.

Skeleton travaille avec Shell et sept autres partenaires pour utiliser la technologie dans les véhicules miniers électriques. Ceux-ci incluent Microvast, Stäubli, Carnegie Robotics, Heliox, Spirae, Alliance Automation et Worley pour fournir une infrastructure de recharge rapide.

Les solutions d’électrification de Shell Mining pour les véhicules tout-terrain consistent en un approvisionnement en énergie et des micro-réseaux pour fournir un approvisionnement constant et fiable en énergie renouvelable, avec des batteries à charge rapide et un stockage d’énergie dans le véhicule.

www.skeletontech.com

Source : eeneweurope

La 5G est 90% plus économe en énergie selon Nokia

Une étude réalisée par Nokia et Telefónica a révélé que les réseaux 5G sont jusqu’à 90% plus écoénergétiques que les réseaux traditionnels.

La recherche, qui a été menée sur une période de trois mois, s’est concentrée sur la consommation électrique des systèmes de réseau d’accès radio (RAN ou Radio Access Network) 5G de Nokia dans le réseau de Telefónica.

L’étude a utilisé les stations de base AirScale de Nokia et les systèmes d’antenne adaptative massive MIMO et combiné les lectures de consommation d’énergie réelle de la station de base sur site dans différents scénarios de charge de trafic, allant de 0% à 100%, ainsi qu’une surveillance à distance de la consommation d’énergie réelle via les systèmes de gestion du réseau. 

Le déploiement des réseaux 5G devrait faire augmenter considérablement le trafic, ce qui rend essentiel que l’énergie consommée n’augmente pas au même rythme.

Des tests approfondis ont examiné onze scénarios différents de charge de trafic prédéfinis qui mesuraient l’énergie consommée par Mbps en fonction de la répartition de la charge de trafic. Les résultats ont mis en évidence que la technologie 5G RAN est nettement plus efficace que les technologies existantes en ce qui concerne la consommation d’énergie par unité de trafic de données grâce à des fonctionnalités matérielles et logicielles qui aident à économiser l’énergie.

La 5G a été conçue pour transporter plus de bits de données par watt d’énergie, mais les réseaux nécessiteront des mesures supplémentaires pour améliorer l’efficacité énergétique et minimiser les émissions de CO2 qui seront générées par une augmentation exponentielle du trafic de données, déclare Nokia. Il existe plusieurs fonctionnalités d’économie d’énergie au niveau de la station de base radio et du réseau, telles que les fonctionnalités d’économie d’énergie 5G, les déploiements de petites cellules et une nouvelle architecture et protocoles 5G, qui peuvent être combinées pour améliorer considérablement l’efficacité énergétique des réseaux sans fil.

Nokia et Telefónica développent également une infrastructure de réseau d’énergie intelligente et des fonctionnalités d’économie d’énergie basées sur l’apprentissage automatique et l’intelligence artificielle.

«Notre plus grande contribution pour surmonter les défis mondiaux en matière de durabilité réside dans les solutions et la technologie que nous développons et fournissons. Nous accordons une grande importance à cela. La technologie de Nokia est conçue pour être économe en énergie pendant l’utilisation, mais elle nécessite également moins d’énergie lors de la fabrication. Cette étude importante montre comment les opérateurs mobiles peuvent compenser les gains énergétiques lors de leurs déploiements en les aidant à être plus respectueux de l’environnement tout en leur permettant de réaliser des économies de coûts significatives », a déclaré Tommi Uitto, président des réseaux mobiles chez Nokia.

source : electronique-eci.com

Les routeurs domestiques embarqués dans la guerre des botnets IoT

Un nouveau rapport de Trend Micro met en garde les consommateurs contre une nouvelle vague d’attaques visant à compromettre leurs routeurs domestiques, pour les utiliser dans des « botnets IoT », c’est-à-dire des appareils connectés à Internet qui sont tous infectés et contrôlés par un type commun de malware.

Selon le rapport, il y a eu un pic récent d’attaques ciblant et exploitant les routeurs, en particulier autour du quatrième trimestre 2019. La recherche, indique la société, indique que l’utilisation abusive de ces appareils se poursuivra car les attaquants peuvent facilement monétiser ces infections dans des attaques secondaires sauf si les utilisateurs prennent des mesures pour empêcher leurs appareils d’activer cette activité criminelle.

« Avec une grande majorité de la population qui dépend actuellement des réseaux domestiques pour son travail et ses études, ce qui arrive à votre routeur n’a jamais été aussi important », déclare Jon Clay, directeur des communications mondiales contre les menaces pour Trend Micro. « Les cybercriminels savent qu’une grande majorité des routeurs domestiques ne sont pas sécurisés avec les informations d’identification par défaut et ont multiplié les attaques à grande échelle. »

 » Pour l’utilisateur domestique, c’est détourner sa bande passante et ralentir son réseau « , déclare Clay.  » Pour les entreprises ciblées par des attaques secondaires, ces botnets peuvent totalement détruire un site Web, comme nous l’avons vu lors d’attaques de grande envergure. « 

Les recherches de la société ont révélé une augmentation à partir d’octobre 2019 des tentatives de connexion par force brute contre les routeurs, dans lesquelles les attaquants utilisent un logiciel automatisé pour essayer des combinaisons de mots de passe courantes. Le nombre de tentatives a presque décuplé, passant d’environ 23 millions en septembre à près de 249 millions de tentatives en décembre 2019. Pas plus tard qu’en mars 2020, selon l’entreprise, elle a enregistré près de 194 millions de connexions par force brute.

Un autre indicateur de l’augmentation de l’ampleur de cette menace, selon la société, est que les appareils tentent d’ouvrir des sessions telnet avec d’autres appareils IoT. Parce que telnet n’est pas chiffré, il est préféré par les attaquants – ou leurs botnets – comme moyen de sonder les informations d’identification des utilisateurs. À son apogée, à la mi-mars 2020, près de 16000 appareils ont tenté d’ouvrir des sessions telnet avec d’autres appareils IoT en une seule semaine.

La tendance est préoccupante, dit l’entreprise, et indique que les cybercriminels sont en concurrence les uns avec les autres pour compromettre autant de routeurs que possible afin qu’ils puissent être enrôlés dans des botnets. Ceux-ci sont ensuite vendus sur des sites clandestins, soit pour lancer des attaques par déni de service distribué (DDoS), soit comme moyen d’anonymiser d’autres attaques telles que la fraude au clic, le vol de données et la prise de contrôle de compte. La concurrence est si féroce, dit la société, que les criminels sont connus pour désinstaller tous les logiciels malveillants qu’ils trouvent sur les routeurs ciblés, démarrant les leurs afin qu’ils puissent revendiquer un contrôle total sur l’appareil. Pour l’utilisateur – domestique ou professionnel – un routeur compromis est susceptible de souffrir de problèmes de performances, et si des attaques sont ensuite lancées à partir de cet appareil, son adresse IP peut également être mise sur liste noire, ce qui peut les impliquer dans des activités criminelles et les couper potentiellement des parties clés d’Internet, et même les réseaux d’entreprise.

Comme expliqué dans le rapport, qui met en évidence trois familles de logiciels malveillants de botnet (Mirai, Kaiten et Qbot) il existe un marché noir florissant des logiciels malveillants de botnet et des botnets à la location. Bien que tout appareil IoT puisse être compromis et exploité dans un botnet, les routeurs présentent un intérêt particulier car ils sont facilement accessibles et directement connectés à Internet.

Pour lutter contre cela, dit l’entreprise, les utilisateurs à domicile doivent tenir compte des recommandations suivantes :

  • Assurez-vous qu’un mot de passe fort est utilisé et qu’il est modifié de temps en temps.
  • Assurez-vous que le routeur exécute le dernier micrologiciel (firmware)
  • Vérifiez les journaux (logs) pour détecter un comportement qui n’a pas de sens pour le réseau.
  • Autorisez uniquement les connexions au routeur à partir du réseau local.

Pour en savoir plus, consultez le rapport : « Worm War : The Botnet Battle for IoT Territory » de Trend Micro

Source : https://www.smart2zero.com/news/home-routers-caught-iot-botnet-war

Tesla recrute en Allemagne alors que Daimler licencie en masse

La restructuration mondiale des modèles de mobilité, le déclin du moteur à combustion et surtout la crise corona provoquent actuellement une tempête parfaite dans l’industrie automobile. Le résultat se voit déjà sur le marché de l’emploi: alors qu’une forteresse automobile traditionnelle Daimler supprime beaucoup d’emplois, Tesla recrute à long terme en Allemagne, advienne que pourra.

Tesla prévoit d’embaucher jusqu’à 10 500 travailleurs pour sa Gigafactory près de Berlin, actuellement en construction. Selon cartains médias, les plans de l’usine comprennent une installation complète de production de véhicules, avec fonderie, atelier de carrosserie, atelier de peinture, production de groupe motopropulseur et assemblage final. Une opération en trois équipes est prévue; entre 3 000 et 5 000 personnes doivent travailler dans chaque équipe.
Dans sa demande d’approbation environnementale, Tesla donne des détails sur le nombre d’employés par équipe, selon les médias. On parle également de jusqu’à 12 000 emplois directs.

L’usine prévue sera reliée à l’autoroute A10 via la jonction Freienbrink. Une sortie temporaire sur l’A10 est prévue, que Tesla a l’intention de construire et de financer elle-même jusqu’à ce qu’une nouvelle sortie d’autoroute régulière soit prête. Cependant, la planification de la connexion routière en est encore à ses balbutiements, dit-on.

La planification environnementale n’est pas non plus terminée. Cependant, Tesla a déjà déblayé une partie de la zone à ses propres risques et prépare la construction de l’usine.

En même temps, 600 km plus au sud-ouest, au siège de Daimler à Stuttgart, on réfléchi à autre chose: il s’agit de se débarrasser de travailleurs. Il y a déjà quelques semaines, des rapports indiquaient que 10 000 à 15 000 emplois seraient perdus en raison de la crise du Coronavirus et dans son sillage de l’effondrement des ventes mondiales. Le responsable des ressources humaines de Daimler, Wilfried Porth, a désormais fourni plus de détails: les chiffres diffusés jusqu’à présent ne seront pas suffisants, a déclaré Porth à l’agence de presse allemande dpa. « Le nouveau nombre de licenciements sera nettement plus grand », a déclaré le responsable du personnel. Actuellement, le constructeur automobile emploie quelque 152.000 personnes  dans le monde et plus de 300.000 dans le groupe.

Les suppressions d’emplois ne sont peut-être pas uniquement dues à la crise du Coronavirus. Les coûts doivent également être optimisés, a précisé la société. Et puis il y a aussi la mobilité électrique, où Daimler n’est pas considéré comme un joueur de premièr plan. De plus, des voix s’élèvent pour demander le nettoyage de la gamme de produits déroutante.

Il est à noter que Daimler a décidé de vendre son usine de Hambach en Lorraine où sont fabriquées les voitures de la gamme Smart et Daimler serait en discussions avec Ineos, le géant britannique de la chimie, qui cherche un endroit pour fabriquer son 4×4 développé en collaboration avec Steyer Puch.

Source : ECI électronique – 20 juillet 2020 par A Delapalisse

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