Configurez le réseau du serveur en ligne de commande

Pour l’instant, vous interagissez avec votre machine virtuelle directement depuis votre écran. Mais dans la réalité de l’entreprise, un serveur est souvent hébergé à distance, dans un centre de données.

Pour avancer avec méthode, vous allez d’abord auditer sa configuration réseau : interface active, adresse IP, passerelle et services en écoute. Vous découvrirez ensuite où se définit la configuration persistante, puis vous vérifierez la résolution de noms DNS, indispensable pour joindre des services distants et préparer l’administration à distance.

Observez la configuration réseau existante

Avant d’envisager toute modification réseau, Alex vous demande de relever l’état actuel du serveur : interface utilisée, adresse IP, passerelle et services en écoute. Une mauvaise hypothèse sur l’un de ces éléments peut suffire à rendre un serveur inaccessible. Votre premier réflexe doit donc être simple : observer avant d’agir.

Identifiez vos cartes réseau  et lisez leur adresse IP

Sur Linux, chaque carte réseau (qu'elle soit physique ou virtuelle) possède un nom unique. Aujourd'hui, ces cartes réseau portent souvent des noms prédictibles comme  ens...   ou  enp...   (par exemple  ens33  ou  enp0s3  ). Pour les lister et lire les adresses IP qui leur sont actuellement attribuées, utilisez la commande  ip addr  , ou sa forme courte  ip a  . 

Lisez la passerelle par défaut

Pour communiquer avec d’autres réseaux, votre serveur a aussi besoin d'une d'une passerelle par défaut.

La commande  ip route  vous affiche la table de routage, ce qui est indispensable pour identifier la passerelle, c'est-à-dire la porte de sortie de votre réseau local vers les autres réseaux.

Vérifiez les services à l'écoute

Auditer le réseau, c'est aussi vérifier quelles portes sont ouvertes sur votre machine. La commande  ss  permet de repérer les ports sur lesquels des services sont en écoute.

Découvrez comment réaliser ce premier audit réseau pas à pas directement sur votre serveur.

Dans cette vidéo, on a :

• identifié l'interface réseau de la machine et lu son adresse IP grâce àip addr,

• repéré la passerelle par défaut permettant de sortir du réseau local via ip route,

• vérifié les ports en écoute et les services associés avec la commandess -tuln.

Maintenant que vous avez une vision claire de vos interfaces, de votre adresse IP, de votre passerelle et des services en écoute, il est temps de comprendre où cette configuration est définie pour qu’elle reste valable après un redémarrage.

Configurez le réseau de manière persistante

Pour qu’un serveur reste administrable dans le temps, il faut aussi comprendre où cette configuration est définie et comment elle est réappliquée après un redémarrage.

Alex vous le rappelle :

Un serveur finit toujours par redémarrer, que ce soit après une mise à jour, une opération de maintenance ou une coupure imprévue. Si sa configuration réseau n’est pas correctement définie, il peut revenir en ligne avec une mauvaise configuration… ou ne plus être joignable du tout.

Sous Debian, la configuration des interfaces réseau peut être définie dans le fichier  /etc/network/interfaces  . Ce fichier texte présente l’avantage d’être lisible et adapté pour comprendre les bases de la configuration réseau. Il permet notamment d’indiquer comment une interface doit être configurée au démarrage de la machine.

En coulisses, cette configuration peut être utilisée par l’outil  ifupdown  , qui se charge d’activer ou de désactiver les interfaces réseau.

Deux approches sont fréquentes : 

1. avec le DHCP (pour Dynamic Host Configuration Protocol), le serveur reçoit automatiquement une adresse depuis le réseau,

2. avec une IP statique, l’adresse, le masque et la passerelle sont définis manuellement. 

Pour un serveur, l’objectif est surtout d’obtenir une adresse stable, que ce soit via une configuration statique ou une réservation DHCP côté infrastructure.

Modifier cette configuration demande toutefois beaucoup de précision. Une erreur sur le nom de l’interface, l’adresse IP, le masque ou la passerelle peut couper l’accès au serveur. C’est pourquoi toute modification réseau doit être suivie d’une vérification immédiate. Posez-vous les questions suivantes. 

• Le serveur a-t-il toujours une adresse IP ? 

• Sa passerelle est-elle toujours présente ? 

• Peut-il encore joindre le réseau ?

Une configuration réseau claire est préférable à une configuration complexe. Avant de modifier, on observe ; après avoir modifié, on vérifie.

Découvrez maintenant où cette configuration est enregistrée et comment une interface peut être déclarée en DHCP ou en IP statique.

Dans cette vidéo, on a :

• localisé le fichier/etc/network/interfaces, qui peut définir la configuration réseau persistante,

• lu et modifié un fichier de configuration (remplacé DHCP par un IP statique), 

• redémarré le service, 

• rappelé que le nom de l’interface doit correspondre à celui observé avecip a,

• vérifié que le serveur conserve une adresse IP, une route par défaut et une connectivité réseau après contrôle ou modification.

Votre serveur dispose maintenant d’une configuration réseau identifiable et vérifiable. Mais pour communiquer efficacement avec des services externes, il ne suffit pas de joindre des adresses IP : il doit aussi être capable de résoudre des noms de domaine. C’est le rôle du DNS, que vous allez maintenant examiner.

Configurez la résolution de noms DNS

Votre audit réseau est rassurant : le serveur possède une adresse IP, une passerelle, et sa configuration réseau est identifiable. Mais est-ce que cette machine sait trouver les services dont elle aura besoin ?

Dans quelques minutes, ce serveur devra peut-être contacter les dépôts Debian pour télécharger des mises à jour, joindre un service interne de l’entreprise ou préparer son futur accès distant. Et dans la réalité, ces services ne sont presque jamais utilisés sous forme d’adresses IP brutes. On parle plutôt à  debian.org  , à un dépôt de paquets, à un serveur interne ou à un nom de domaine.

Alex insiste souvent sur ce point :

Un problème DNS peut faire croire que “le réseau ne marche pas”, alors que l’adresse IP et la passerelle sont parfaitement correctes. Le serveur peut être bien connecté, mais incapable de retrouver l’adresse d’un service à partir de son nom. Résultat : impossible de télécharger des mises à jour ou de joindre une ressource distante par son nom.

Pour diagnostiquer cette situation, vous allez utiliser deux commandes simples :

• ping, qui permet de tester à la fois la résolution d’un nom et la connectivité vers la machine distante,

• getent hosts, qui permet de vérifier comment le système résout en s’appuyant sur la configuration du système un nom de domaine en adresse IP.

Et pour aller plus loin, n’hésitez pas à utiliser la commande dig pour interroger plus précisémment le DNS et analyser la réponse envoyée par un serveur DNS. 

Vous devrez aussi savoir où observer la configuration DNS utilisée par le serveur. Sous Linux, le fichier  /etc/resolv.conf  indique généralement les serveurs DNS interrogés par la machine, notamment grâce aux lignes  nameserver.

Le bon réflexe reste donc le même : vous observez, vous testez, puis vous modifiez seulement si vous savez quel service gère réellement la configuration.

Découvrez maintenant comment vérifier que votre serveur sait résoudre des noms de domaine avant de poursuivre sa mise en service.

Dans cette vidéo, on a :

• vérifié que le serveur peut résoudre un nom de domaine avecping -c 3 debian.org,

• utiliségetent hosts debian.orgpour confirmer la traduction du nom de domaine en adresse IP,

• consulté/etc/resolv.confpour identifier les serveurs DNS interrogés par la machine,repéré les lignesnameserver,

• compris pourquoi une modification manuelle de ce fichier n’est pas recommandée lorsqu’il est géré automatiquement.

Votre serveur sait maintenant s’identifier sur le réseau, sortir de son réseau local et résoudre des noms de domaine. Vous disposez des bases nécessaires pour préparer son futur accès distant.

À vous de jouer

Contexte 

Pour s'intégrer à l'infrastructure de l'entreprise, votre serveur doit être joignable et rester accessible même après un redémarrage. Comme nous l'avons vu, la règle d'or est stricte : on ne modifie jamais une configurationréseau à l'aveugle. Votre mission consiste donc à réaliser un audit complet de la connectivité de votre machine virtuelle.

Consignes

1. Identifiez le nom de l’interface réseau active de votre serveur à l’aide deip addr. Ne retenez pas l’interfacelo, qui correspond à la boucle locale. Cherchez plutôt une interface de typeens…ouenp…

2. Vérifiez les informations réseau associées à cette interface, en repérant notamment l’adresse IP attribuée et la passerelle par défaut, à l’aide deip route.

3. Repérez l'emplacement où est définie la configuration réseau persistante du serveur en consultant le fichier/etc/network/interfaces.Inspectez son contenu, sans modifier aucun fichier.

4. Vérifiez les paramètres de résolution de noms (DNS) actuellement interrogés par votre système en consultant/etc/resolv.conf. Repérez notamment les lignesnameserver, si elles sont présentes.

5. Vérifiez que le serveur est effectivement capable de résoudre un nom de domaine (par exempledebian.org) afin de confirmer le bon fonctionnement du DNS.

En résumé

• L’audit réseau initial consiste à identifier l’interface active, l’adresse IP et la passerelle par défaut à l’aide des commandesip addretip route, afin d’éviter toute modification à l’aveugle.

• La commandesspermet de vérifier les ports en écoute et les services exposés, ce qui contribue à évaluer la surface d’attaque d’un serveur minimal.

• La configuration réseau persistante peut être définie dans le fichier/etc/network/interfaces, où une interface peut être déclarée en DHCP ou avec une adresse IP statique selon les besoins de stabilité.

• Toute modification réseau doit être immédiatement suivie d’une vérification de l’adresse IP, de la route par défaut et de la connectivité afin d’éviter de rendre le serveur inaccessible.

• La résolution DNS repose sur la capacité du serveur à traduire un nom de domaine en adresse IP via des outils commepingetgetent hosts, ainsi que sur la configuration indiquée dans/etc/resolv.conf.

Votre serveur dispose maintenant d’une base réseau vérifiée : vous savez identifier son interface active, son adresse IP, sa passerelle et ses paramètres DNS. La vérification est terminé ! Mais allez-vous vraiment rester toute la journée devant la console de cette machine ? Dans la réalité de notre entreprise, vous l’administrerez depuis votre poste de travail, à distance. Pour prendre le contrôle du serveur sans accès physique direct, nous allons maintenant mettre en place et sécuriser son accès avec SSH.