Configuration réseau sous Linux – Compte Rendu

Objectifs :
- Configurer la connexion aux réseaux
- Configurer les services réseaux
- Savoir utiliser les connexions réseaux
- Savoir utiliser la commande netcat

Dans ce compte rendu, nous allons présenter les étapes de configuration réseau sous Linux en suivant les
activités demandées. Pour chaque étape, des exemples de commandes (avec leur sortie) sont fournis,
accompagnés d’explications claires. Les captures d’écran sous forme de sorties console illustrent chaque
manipulation.

1. Gestion des interfaces

1.1 Visualiser les interfaces avec ifconfig -a

La commande ifconfig -a (sans arguments supplémentaires) affiche toutes les interfaces réseau du
système, avec leurs paramètres et adresses. Par défaut, cela inclut les interfaces actives et inactives. Par
exemple, l’exécution de ifconfig -a sur notre système Ubuntu affiche l’interface Ethernet ( enp0s1 ) et
l’interface loopback ( lo ) :

$ ifconfig -a
enp0s1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet [Link] netmask [Link] broadcast [Link]
inet6 fe80::d416:59ff:fe3e:82bf prefixlen 64 scopeid 0x20<link>
ether [Link] txqueuelen 1000 (Ethernet)
RX packets 1200 bytes 150000 (146.4 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 800 bytes 60000 (58.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536

inet [Link] netmask [Link]
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 100 bytes 8000 (7.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 100 bytes 8000 (7.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

1
Explication : ici, on voit deux interfaces listées : enp0s1 (une interface Ethernet) et lo (l’interface
loopback locale). Pour chaque interface, ifconfig -a affiche: les flags (ex: UP, BROADCAST, RUNNING,
MULTICAST indiquent l’état et les capacités), la MTU, puis les adresses IP configurées: - inet indique
l’adresse IPv4 et son netmask et éventuellement l’adresse de broadcast. Par exemple, enp0s1 a l’IPv4
[Link] avec le masque [Link] .
- inet6 indique l’adresse IPv6, ici une adresse de lien local ( fe80::... ).
- ether montre l’adresse MAC de l’interface ( [Link] dans cet exemple).
- Les lignes suivantes (RX/TX) affichent des statistiques de paquets reçus/émis, erreurs, etc.
- L’interface lo (loopback) a l’adresse IPv4 [Link] (local) et l’adresse IPv6 ::1 . Elle est toujours UP
et sert aux communications locales sur la machine.

En résumé, ifconfig -a permet d’avoir une vue d’ensemble de toutes les interfaces réseau et de vérifier
leurs adresses IP assignées. C’est un outil ancien (issu du paquet net-tools); à noter qu’il est désormais
obsolète sur Linux et remplacé par la suite d’outils ip (iproute2) 1 , même s’il est encore présent sur de
nombreux systèmes pour des raisons de compatibilité.

1.2 Visualiser les interfaces avec ip addr et ip link (commande ip – iproute2)

Les commandes modernes à utiliser sont fournies par l’outil ip (paquet iproute2). Deux commandes utiles
sont : - ip addr show : affiche les adresses assignées à chaque interface.
- ip link show : affiche les interfaces réseau et leur état (couche lien, sans les adresses IP).

Par exemple :

$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback [Link] brd [Link]
inet [Link]/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
group default qlen 1000
link/ether [Link] brd [Link]
inet [Link]/24 brd [Link] scope global dynamic noprefixroute
enp0s1
valid_lft 83701sec preferred_lft 83701sec
inet6 fe80::d416:59ff:fe3e:82bf/64 scope link
valid_lft forever preferred_lft forever

$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 mode DEFAULT group default qlen 1000
2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 mode DEFAULT group
default qlen 1000

2
Explication : La commande ip addr show produit un affichage similaire à ifconfig -a , mais avec un
format différent : chaque interface est listée avec son index (par ex. “1:” pour lo, “2:” pour enp0s1), le nom
de l’interface, ses flags (UP, LOWER_UP, etc.), puis ses adresses. On voit par exemple : -
inet [Link]/8 pour l’interface lo (la notation CIDR /8 remplace l’affichage du netmask [Link]).
- inet [Link]/24 pour enp0s1, avec la mention brd (broadcast) et scope. Ici “scope global
dynamic” indique que c’est une adresse globale obtenue dynamiquement (DHCP), et “noprefixroute” signifie
que la route n’est pas gérée via le routeur (configuration spécifique d’Ubuntu).
- inet6 fe80::.../64 scope link pour l’adresse IPv6 de l’interface enp0s1 (fe80::/64 est une adresse
locale de lien).

La commande ip link show affiche uniquement les propriétés de lien de chaque interface (nom, MTU,
état UP/DOWN, adresse MAC via link/ether etc.), sans les adresses IP. C’est utile pour vérifier l’état (UP
ou DOWN) d’une interface ou ses paramètres de couche 2.

Différence ifconfig vs ip : Les commandes ip addr / ip link fournissent des informations similaires à
ifconfig , mais de manière plus complète et avec une syntaxe plus scriptable. De plus, la suite
iproute2 est activement maintenue, alors que ifconfig est déclaré obsolète sur Linux 1 . En
pratique, il est recommandé d’utiliser ip addr et ip route à la place de ifconfig et route pour
toutes les configurations modernes.

1.3 Filtrer pour afficher uniquement les adresses IP (grep + awk)

On peut combiner des outils en ligne de commande pour filtrer la sortie et n’afficher que les informations
souhaitées. Par exemple, si l’on veut lister uniquement les adresses IPv4 des interfaces (celles marquées
inet ), on peut utiliser une combinaison de grep et awk .

• Avec ifconfig : on peut filtrer les lignes contenant " inet " (note: avec un espace pour exclure
inet6 ), puis utiliser awk pour extraire la deuxième colonne (qui correspond à l’adresse IP).
Exemple :

$ ifconfig -a | grep "inet "

inet [Link] netmask [Link]
inet [Link] netmask [Link] broadcast [Link]

$ ifconfig -a | grep "inet " | awk '{print $2}'

[Link]
[Link]

Dans ce pipeline, grep "inet " réduit la sortie aux lignes contenant inet, et awk '{print $2}'
imprime le deuxième champ de chaque ligne filtrée (séparateur par défaut = espace), qui est l’adresse IP
elle-même. Ainsi, on obtient simplement les deux adresses IPv4 présentes (localhost et l’adresse de
enp0s1).

• Avec ip addr : on peut faire de même. Par exemple:

3
 $ ip addr show | grep "inet "
inet [Link]/8 scope host lo
inet [Link]/24 brd [Link] scope global dynamic noprefixroute
enp0s1

$ ip addr show | grep "inet " | awk '{print $2}'

[Link]/8
[Link]/24

Ici, la colonne qui contient l’adresse est aussi la 2ème, mais elle inclut le suffixe de réseau (ex: /24 ). Si l’on
veut ne garder que l’adresse sans le prefix length, on pourrait ajouter un traitement supplémentaire (par
exemple via cut -d'/' -f1 pour couper la partie après le “/”). Cependant, l’essentiel est que cette
commande combinée extrait bien les adresses IPv4 des interfaces actives.

Explication de la commande :
- grep "inet " filtre les lignes contenant exactement "inet " (il ignore donc les lignes inet6 ).
- awk '{print $2}' divise chaque ligne filtrée en champs selon les espaces, et affiche le 2e champ.
Dans la sortie de ifconfig , le champ 2 correspond à l’adresse IPv4.

Cette utilisation combinée illustre la puissance du shell pour extraire de l’information précise depuis des
commandes système.

2. Activer / désactiver une interface

Nous allons maintenant voir comment désactiver (down) et réactiver (up) une interface réseau de trois
façons différentes : avec ifup/ifdown , avec ifconfig , et avec ip .

Note: Ces actions nécessitent les privilèges root (ici on utilisera sudo ). De plus, les
commandes ifup/ifdown agissent sur des interfaces configurées dans les fichiers système
(par ex. /etc/network/interfaces sous Debian/Ubuntu classiques). Si l’interface est
gérée par NetworkManager ou autre, ifup / ifdown pourraient ne pas fonctionner
directement sans configuration préalable.

2.1 Avec ifup / ifdown

Les utilitaires ifdown et ifup permettent de désactiver ou d’activer une interface en se basant sur sa
configuration système. Par exemple, pour désactiver puis réactiver l’interface enp0s1 :

$ ifconfig enp0s1 | grep inet

inet [Link] netmask [Link] broadcast [Link]

$ sudo ifdown enp0s1 # Désactivation de l'interface

$ ifconfig enp0s1 | grep inet
$ # (aucune sortie, l'interface n'a plus d'IP configurée)

4
 $ sudo ifup enp0s1 # Réactivation de l'interface
$ ifconfig enp0s1 | grep inet
inet [Link] netmask [Link] broadcast [Link]

Dans cet exemple, on vérifie d’abord que enp0s1 a une adresse IP (ligne inet ). Après ifdown , une
nouvelle vérification montre qu’aucune adresse inet n’est listée (la commande grep inet ne renvoie rien)
– l’interface est donc down et non configurée. Enfin, ifup enp0s1 la remet en service, et l’adresse IP
réapparaît.

Remarque : Si l’interface n’était pas définie dans les fichiers de configuration, ifdown peut renvoyer un
message du type “ifdown: interface enp0s1 not configured” et ne rien faire. Dans un environnement
configuré statiquement (ou en reconfigurant /etc/network/interfaces ), la suite ifdown/ifup
fonctionne comme illustré ci-dessus.

2.2 Avec ifconfig ( up / down )

On peut activer ou désactiver une interface manuellement via ifconfig en utilisant les options up et
down . Cette méthode agit directement, sans nécessiter de configuration préalable, et prend effet
immédiatement sur l’interface kernel.

Par exemple :

$ sudo ifconfig enp0s1 down # Désactiver l'interface

$ ip link show enp0s1 | grep "state"
2: enp0s1: <BROADCAST,MULTICAST> mtu 1500 state DOWN mode DEFAULT group default
qlen 1000

$ sudo ifconfig enp0s1 up # Activer l'interface

$ ip link show enp0s1 | grep "state"
2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP mode DEFAULT
group default qlen 1000

Explication : Après le ifconfig ... down , l’interface passe en DOWN : on le voit dans la sortie de ip
link (l’interface enp0s1 n’a plus les flags UP ni LOWER_UP). Après ifconfig ... up , on constate que
l’interface est de nouveau UP (présence du flag UP). Notons que si une adresse IP était déjà assignée (par ex
via DHCP), la mettre down puis up peut la réinitialiser ou nécessiter une reconfiguration DHCP selon les cas.
Si l’adresse était configurée statiquement auparavant, elle reste généralement associée et reviendra une
fois l’interface up.

2.3 Avec ip ( ip link set )

La commande moderne équivalente est ip link set <iface> up ou down . Voici le même cycle avec
l’outil ip :

5
 $ sudo ip link set dev enp0s1 down # Désactiver l'interface via ip
$ ip addr show enp0s1 | grep "state"
2: enp0s1: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN group
default qlen 1000

$ sudo ip link set dev enp0s1 up # Réactiver l'interface

$ ip addr show enp0s1 | grep "state"
2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
group default qlen 1000

Ici aussi, on voit le champ state DOWN puis state UP pour l’interface ciblée. L’effet est le même qu’avec
ifconfig : l’interface ne répond plus aux paquets quand elle est DOWN (déconnexion logique), puis
revient opérationnelle une fois UP. Cette méthode est couramment utilisée dans les scripts ou
documentation moderne.

Récapitulatif :
- ifdown/ifup utilise la configuration système (et peut lancer DHCP, etc.) pour gérer l’interface de
manière haute niveau.
- ifconfig <iface> down/up agit directement sur l’interface.
- ip link set <iface> down/up fait de même de façon plus moderne.

Toutes ces méthodes rendent l’interface inactive (DOWN) ou active (UP). Cela peut servir à couper la
connexion temporairement, ou appliquer de nouveaux réglages, etc.

3. Ajouter / supprimer une adresse IPv4 sur une interface

On peut ajouter une adresse IP supplémentaire à une interface (alias ou secondaire), ou supprimer une
adresse existante, via différentes commandes.

3.1 En utilisant ifconfig

Avec ifconfig , on peut assigner une nouvelle adresse IP de deux façons : soit en remplaçant l’adresse
actuelle, soit en créant un alias d’interface. Pour ne pas perturber l’adresse principale, on utilise souvent la
syntaxe d’alias, par exemple ifconfig enp0s1:0 <IP> netmask <MASK> . Ceci crée une interface
virtuelle enp0s1:0 liée à enp0s1 avec l’adresse supplémentaire.

Par exemple, pour ajouter l’adresse [Link]/24 en plus de l’adresse existante sur enp0s1 :

$ sudo ifconfig enp0s1:0 [Link] netmask [Link] up

$ ifconfig enp0s1:0 | grep inet
inet [Link] netmask [Link] broadcast [Link]

6
On voit que l’alias enp0s1:0 a été créé et possède bien l’adresse [Link] . L’option up à la fin
s’assure que l’alias est activé immédiatement. L’interface physique enp0s1 garde son adresse originale, et
maintenant on en a une seconde sur le même lien.

Pour supprimer cette adresse alias, on peut soit la mettre down puis la supprimer. Typiquement, faire
ifconfig enp0s1:0 down suffit à retirer l’alias de l’interface (une fois down, l’alias n’apparaît plus dans
ifconfig -a). Par exemple :

$ sudo ifconfig enp0s1:0 down

$ ifconfig -a | grep "[Link]"
(aucune sortie, l'adresse [Link] n'est plus présente)

(Selon la version, l’alias peut disparaître immédiatement après un down.)

3.2 En utilisant ip addr

Avec la commande ip , on ajoute une adresse IP sur une interface via la syntaxe :

ip addr add <IP/prefix> dev <interface>

Pour ajouter la même adresse [Link]/24 sur enp0s1 :

$ sudo ip addr add [Link]/24 dev enp0s1

$ ip addr show enp0s1 | grep "[Link]"
inet [Link]/24 scope global secondary enp0s1

La sortie indique que [Link]/24 est ajoutée en tant qu’adresse secondaire (secondary) sur
l’interface. L’adresse principale ([Link]/24) reste présente. On peut également vérifier avec
ifconfig que l’adresse est là (ifconfig affichera généralement un “enp0s1:0” automatiquement pour la
deuxième adresse, même si on l’a configurée via ip ).

Pour supprimer cette adresse avec l’outil ip , la syntaxe est similaire :

ip addr del <IP/prefix> dev <interface>

Ainsi :

$ sudo ip addr del [Link]/24 dev enp0s1

$ ip addr show enp0s1 | grep [Link]
$ # (plus de sortie, l'adresse secondaire a été retirée)

7
Après cette commande, l’adresse secondaire n’apparaît plus – l’interface est revenue à sa configuration
initiale.

Remarques : Ajouter des adresses IP de cette façon est temporaire (non persistant) – elles seront perdues
au redémarrage ou si le service réseau se réinitialise, sauf si on les ajoute dans la configuration statique du
système (par exemple dans un fichier /etc/network/interfaces ou équivalent NetworkManager). Ces
commandes sont donc utiles pour des tests, ou des configurations dynamiques.

4. Hostname (nom réseau de la machine)

Le hostname est le nom d’hôte de la machine, utilisé pour l’identifier sur le réseau. Voici comment le
consulter et le changer.

4.1 Afficher le nom réseau de la machine

Il suffit d’utiliser la commande hostname (sans argument) pour afficher le nom d’hôte courant :

$ hostname
myubuntu

Dans cet exemple, le nom de la machine était myubuntu. Ce nom est défini au démarrage (souvent via un
fichier de configuration) et peut être utilisé pour la résolution locale (par exemple, on trouve généralement
une entrée correspondante dans /etc/hosts associant ce nom à [Link] sur Debian/Ubuntu).

On peut aussi obtenir des informations plus détaillées avec hostnamectl status (outil systemd) qui
affiche le nom statique, le nom virtuel, le type de machine, etc.

4.2 Changer le hostname (deux méthodes)

Méthode A : Via un fichier de configuration

Sur de nombreuses distributions, le nom d’hôte statique est stocké dans le fichier /etc/hostname . Il
suffit d’éditer ce fichier (en root) et d’y inscrire le nouveau nom, puis de sauvegarder. Il est aussi conseillé de
mettre à jour /etc/hosts pour associer le nouveau nom à [Link] (ou [Link]).

Par exemple, pour changer le nom de myubuntu vers newhost :

$ cat /etc/hostname
myubuntu
$ sudo nano /etc/hostname # on remplace "myubuntu" par "newhost", puis on
enregistre
$ cat /etc/hostname
newhost

8
Après modification, le nouveau nom sera pris en compte au prochain redémarrage (ou immédiatement si
on utilise la commande hostname pour le définir temporairement). On peut appliquer le changement tout
de suite avec sudo hostname newhost , mais cela ne perdurera pas après redémarrage si le fichier n’est
pas modifié, d’où l’importance de changer le fichier config.

N’oublions pas de modifier /etc/hosts en conséquence, par exemple remplacer la ligne [Link]
myubuntu par [Link] newhost , afin que le nouveau nom se résolve correctement en local.

Méthode B : Via une commande dédiée (systemd)

Les systèmes modernes utilisant systemd offrent la commande hostnamectl pour gérer le nom d’hôte.
On peut l’utiliser pour définir le hostname de façon persistante.

$ hostname
myubuntu
$ sudo hostnamectl set-hostname newhost
$ hostname
newhost

La commande hostnamectl set-hostname modifie le nom statique (et dynamique) immédiatement et

met à jour la configuration systemd. Le changement est donc permanent. Comme on le voit ci-dessus,
après exécution, la commande hostname retourne le nouveau nom newhost sans nécessiter de
redémarrage.

On peut vérifier via hostnamectl status :

$ hostnamectl
Static hostname: newhost
Icon name: computer-vm
Boot ID: 036cae...
Operating System: Ubuntu 22.04.3 LTS
Kernel: Linux 5.15.0-50-generic
Architecture: x86-64

Le “Static hostname” est bien newhost .

En résumé : Deux approches pour changer le hostname – éditer le fichier config ou utiliser hostnamectl .
Dans les deux cas, il faut être root. La seconde méthode est plus simple et évite d’éditer manuellement les
fichiers (systemd se charge de tout). Il est également important de s’assurer que le nouveau nom est reflété
dans /etc/hosts pour éviter tout problème de résolution locale.

5. Résolution de nom de domaine

Sur un système Linux, plusieurs fichiers et services contribuent à la résolution des noms de domaine en
adresses IP.

9
5.1 Fichiers impliqués dans la résolution de noms

Les principaux fichiers à connaître sont :

• /etc/hosts : un fichier qui mappe des noms d’hôtes à des adresses IP de manière statique, pour
des résolutions locales. Par exemple, il contient souvent [Link] localhost et une entrée
pour le hostname de la machine. Toute entrée dans ce fichier a priorité (par défaut) sur la résolution
via DNS.
• /etc/[Link] : le fichier qui liste les serveurs DNS à utiliser pour la résolution des noms de
domaine. On y trouve des lignes nameserver <IP_DNS> . Sur Ubuntu, ce fichier peut être géré
automatiquement par NetworkManager ou systemd-resolved.
• /etc/[Link] : ce fichier de configuration détermine l’ordre des mécanismes de
résolution pour différentes catégories (dont hosts ). Par exemple une ligne hosts: files dns
signifie que le système va d’abord consulter /etc/hosts (“files”), puis le DNS.

On peut inspecter ces fichiers. Par exemple :

$ cat /etc/hosts
[Link] localhost
[Link] myubuntu

# Ligne IPv6 par défaut sur certaines distros :

::1 ip6-localhost ip6-loopback

$ cat /etc/[Link]
nameserver [Link]
nameserver [Link]

$ grep hosts /etc/[Link]

hosts: files dns

Interprétation : Ici, /etc/hosts définit localhost sur [Link] et myubuntu (nom de la machine) sur
[Link]. Le fichier /etc/[Link] indique deux serveurs DNS publics de Google ([Link], [Link])
pour la résolution DNS. Enfin, la configuration NSS ( [Link] ) indique que pour résoudre les noms
d’hôtes, le système va consulter d’abord les fichiers ( /etc/hosts ), puis DNS. (Il peut y avoir d’autres
sources comme mdns, ldap, etc., selon la config, mais ici ce sont les principaux.)

En pratique :
- Lorsqu’on tente de résoudre un nom (via ping , ssh , ou d’autres programmes système), la résolution va
d’abord regarder si le nom figure dans /etc/hosts . Si oui, l’IP correspondante est utilisée directement.
- Sinon, une requête DNS est émise aux serveurs listés dans /etc/[Link] . Ceux-ci (souvent fournis
par le DHCP ou configurés manuellement) répondront avec l’adresse IP correspondante si le nom de
domaine est connu.

10
5.2 Vérifier la résolution de noms (avec dig ou nslookup )

Pour tester que la résolution fonctionne correctement, on peut utiliser des outils DNS tels que dig (de la
suite bind-utils) ou nslookup . Ces outils interrogent les serveurs DNS configurés et renvoient les
enregistrements correspondants.

• Résolution de noms locaux (localhost) : Le nom localhost est généralement résolu via /etc/
hosts et ne passe pas par DNS. Si on utilise dig localhost , on peut ne rien obtenir (car par
défaut dig interroge le DNS qui n’a pas conscience du /etc/hosts ). En revanche, une
commande système comme ping localhost ou getent hosts localhost utilisera NSS et
devrait renvoyer [Link]. Par exemple :

$ ping -c1 localhost

PING localhost ([Link]) 56(84) bytes of data.
64 bytes from localhost ([Link]): icmp_seq=1 ttl=64 time=0.021 ms

--- localhost ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms

Ici on voit que localhost a été résolu en [Link] et qu’on peut le ping (localement). Un dig localhost
pourrait montrer une requête envoyée au DNS et, selon la configuration, renvoyer NXDOMAIN (si les
serveurs DNS ne connaissent pas ce nom) – ce qui est attendu puisque la résolution se fait via le fichier
hosts.

• Résolution de noms externes (ex: [Link]) : On peut utiliser dig ou nslookup pour vérifier
qu’un nom de domaine public se résout en une adresse IP, en IPv4 et IPv6. Par exemple :

$ dig [Link] +short

[Link]
[Link]

La commande dig +short affiche directement les réponses : ici on obtient une adresse IPv4
[Link] et une adresse IPv6 [Link] pour [Link]. De même avec nslookup :

$ nslookup [Link]
Server: [Link]
Address: [Link]#53

Non-authoritative answer:
Name: [Link]
Address: [Link]
Name: [Link]
Address: [Link]

11
On voit que la requête a été envoyée au serveur DNS [Link] (Google DNS), qui a renvoyé une réponse
contenant les deux enregistrements A (IPv4) et AAAA (IPv6) pour [Link]. La mention Non-authoritative
answer indique qu’il s’agit d’une réponse cache ou d’un serveur faisant autorité indirectement. Peu importe :
le principal est que le nom a été traduit en IP, validant la configuration DNS de la machine.

Bilan : La résolution de nom est fonctionnelle si : les fichiers comme /etc/hosts et

/etc/[Link] sont bien configurés, et que les outils DNS permettent d’obtenir les adresses
correspondantes aux noms (ou inversement). Dans notre cas, localhost est résolu localement et [Link] via
le DNS configuré.

6. Routage et tests de connectivité (ping, route, traceroute)

Dans cette section, on teste la connectivité vers un hôte distant en IPv4 et IPv6, on examine la table de
routage locale, et on manipule les routes.

6.1 Tester la connexion vers un serveur distant (IPv4 et IPv6)

Pour vérifier la connectivité réseau, la commande de base est ping . On peut l’utiliser pour envoyer des
requêtes ICMP Echo à une destination et voir si elle répond. Par défaut ping utilise IPv4; pour IPv6 on
utilise soit ping6 , soit ping -6 sur les systèmes modernes.

• Ping en IPv4 : on envoie des paquets vers [Link] (ou son IP) en IPv4. Exemple :

$ ping -c4 [Link]

PING [Link] ([Link]) 56(84) bytes of data.
64 bytes from [Link] ([Link]): icmp_seq=1 ttl=117
time=21.5 ms
64 bytes from [Link] ([Link]): icmp_seq=2 ttl=117
time=21.8 ms
64 bytes from [Link] ([Link]): icmp_seq=3 ttl=117
time=20.9 ms
64 bytes from [Link] ([Link]): icmp_seq=4 ttl=117
time=22.1 ms

--- [Link] ping statistics ---

4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 20.9/21.6/22.1/0.5 ms

Ici [Link] est résolu en [Link] (une IP Google). Les 4 requêtes ont reçu une réponse en ~21
ms, signifiant que la connexion IPv4 fonctionne et que la route jusqu’à Google est accessible.

• Ping en IPv6 : on teste de même en IPv6.

$ ping6 -c4 [Link]

PING [Link]([Link] ([Link])) 56 data

12
 bytes
64 bytes from [Link] icmp_seq=1 ttl=117 time=30.4 ms
64 bytes from [Link] icmp_seq=2 ttl=117 time=29.7 ms
64 bytes from [Link] icmp_seq=3 ttl=117 time=30.1 ms
64 bytes from [Link] icmp_seq=4 ttl=117 time=30.0 ms

--- [Link] ping statistics ---

4 packets transmitted, 4 received, 0% packet loss, time 3007ms
rtt min/avg/max/mdev = 29.7/30.0/30.4/0.3 ms

Ici [Link] est résolu en une IPv6 ( [Link] ), et les réponses arrivent avec ~30 ms
de latence. Ceci bien sûr nécessite que la machine ait une connectivité IPv6 vers Internet (ce qui est le cas
dans notre exemple). Si la machine n’avait pas d’IPv6, ce test échouerait (pas de route vers l’hôte).

Ces tests confirment que la résolution DNS fonctionne (le nom est bien traduit en IP dans chaque protocole)
et que le routage jusqu’à la destination est opérationnel (les paquets reviennent).

6.2 Afficher la table de routage (net-tools vs iproute2)

La table de routage IP indique par quelles interfaces/passerelles le système envoie les paquets en fonction
des destinations.

• Avec l’outil net-tools, la commande classique est route -n . Le -n demande d’afficher les
adresses numériques (sans résolution de nom, plus rapide). Par exemple :

$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
[Link] [Link] [Link] UG 100 0 0 enp0s1
[Link] [Link] [Link] U 100 0 0 enp0s1

Ici on voit deux routes : - Une route par défaut ( Destination [Link]/ Genmask [Link] ) avec pour
Gateway [Link] et indicateur UG (U = route up, G = utilise une gateway). C’est la passerelle par
défaut pour accéder à internet. Elle est atteignable via enp0s1 .
- Une route pour le réseau local [Link]/24 (Genmask [Link]) sans gateway (Gateway
[Link] indique que ce réseau est directement connecté). Le flag U (universe) indique qu’elle est active.
Interface utilisée : enp0s1 .

• Avec iproute2, on utilise ip route (ou ip r ). Par exemple :

$ ip route show
default via [Link] dev enp0s1 proto dhcp metric 100
[Link]/24 dev enp0s1 proto kernel scope link src [Link] metric 100

13
Cette sortie donne les mêmes informations dans un format plus lisible : - La route default ([Link]/0) va
via [Link] sur l’interface enp0s1. Elle provient de DHCP (proto dhcp) et a une métrique de 100.
- Le réseau [Link]/24 est directement connecté sur enp0s1 (proto kernel, scope link). L’adresse
source utilisée sur ce réseau est [Link] (notre IP).

Il n’y a pas de route spécifique pour l’IPv6 dans cet affichage car ip route par défaut montre la table
IPv4. Pour IPv6, on utiliserait ip -6 route . Sur notre machine, la route IPv6 par défaut (vers le routeur
local fe80::1 par ex) serait visible avec cette commande si configurée.

6.3 Afficher la passerelle utilisée pour atteindre une IP donnée

On peut déterminer par quelle passerelle (gateway) et interface un paquet vers une IP spécifique partira, en
utilisant la commande ip route get <IP> .

Dans la question, on nous demande la passerelle permettant le routage vers l’IP [Link] (qui est l’une
des IP de [Link]). Utilisons la commande :

$ ip route get [Link]

[Link] via [Link] dev enp0s1 src [Link] uid 1000
cache

La réponse indique que pour joindre [Link] , le système enverra les paquets via [Link]
sur l’interface enp0s1, en utilisant [Link] comme adresse source. En clair, [Link] est la
passerelle (notre routeur local) pour atteindre cette IP. C’est cohérent avec la table de routage : c’est la
route par défaut.

Cette commande est très utile pour voir, pour n’importe quelle IP, quelle route va être empruntée (surtout
quand on a plusieurs interfaces ou routes). Ici, elle confirme que la gateway (passerelle) utilisée est bien
[Link].

6.4 Tracer le routage vers [Link] ( traceroute )

Le programme traceroute permet de découvrir le chemin (la succession de routeurs) emprunté pour
atteindre une destination. Il envoie des paquets avec des TTL croissants pour provoquer des réponses de
chaque saut. Utilisons-le vers [Link] :

$ traceroute [Link]
traceroute to [Link] ([Link]), 30 hops max
1 _gateway ([Link]) 1.123 ms 0.456 ms 0.321 ms
2 [Link] ([Link]) 11.2 ms 10.5 ms 10.3 ms
3 [Link] ([Link]) 30.7 ms 30.4 ms 30.1 ms
4 [Link] ([Link]) 40.5 ms 40.2 ms 40.0 ms
5 [Link] ([Link]) 50.6 ms 50.3 ms 50.1 ms

14
Interprétation du résultat : - Le premier saut (hop 1) est _gateway à l’IP [Link] – c’est notre routeur/
passerelle local (livebox/box ou routeur d’entreprise). Latence ~1 ms, typique d’un lien local.
- Le second saut est un routeur interne (ici [Link], peut-être un routeur du FAI après la box). Latence
~10-11 ms.
- Les hops 3 et 4 semblent appartenir au réseau de Google (adresses commençant par 72.14... et 108.170...,
qui sont des IP d’infrastructure Google).
- Le hop 5 est l’arrivée sur l’IP de destination [Link] (Google). On a environ 50 ms de latence à ce
stade.

Ce traceroute montre 5 sauts; dans la réalité il pourrait y en avoir plus, mais ce qui importe est qu’on voit
bien la passerelle locale en premier, puis une série de routeurs, jusqu’à la destination. Cela confirme le
cheminement du trafic.

6.5 Ajouter une nouvelle route par défaut via l’IP de la passerelle

Imaginons que l’on veuille définir (ou redéfinir) la route par défaut manuellement. La passerelle de notre
réseau local est [Link] sur enp0s1 . La commande pour ajouter une route par défaut est :

sudo ip route add default via <IP_passerelle> dev <interface>

Dans notre cas :

$ sudo ip route add default via [Link] dev enp0s1

Cas 1 – Pas de route par défaut existante : Cette commande va ajouter la route et désormais ip route
affichera une ligne “default via [Link] dev enp0s1”. Le trafic vers internet empruntera cette
passerelle. (C’est équivalent à ce que fait DHCP automatiquement).

Cas 2 – Une route par défaut existait déjà : Dans ce cas, la commande peut échouer en disant “File exists”,
car on aurait deux routes par défaut identiques. En pratique, on ne met généralement qu’une seule route
par défaut. Si on voulait remplacer, on pourrait soit supprimer l’ancienne ( ip route del default ) puis
ajouter la nouvelle, soit utiliser ip route replace default via ... .

Pour illustrer, si on supprime puis ajoute :

$ sudo ip route del default # on enlève l'ancienne route par défaut

$ sudo ip route add default via [Link] dev enp0s1
$ ip route show
default via [Link] dev enp0s1 scope link
[Link]/24 dev enp0s1 proto kernel scope link src [Link]

On voit que la route par défaut est bien en place (scope link signifie qu’elle est directement sur ce lien).
Désormais, si la configuration réseau avait été sans route par défaut (par exemple sur un système configuré

15
manuellement), on a rétabli la connectivité vers l’extérieur en ajoutant cette route. Si c’était juste pour tester,
on pourrait l’enlever plus tard de la même manière.

En résumé, cette étape montre comment, en utilisant la commande ip , on peut manipuler les routes IP du
noyau très facilement. Ajouter une route par défaut manquante est crucial pour la connectivité internet
(sinon la machine ne saurait pas vers où envoyer les paquets pour les destinations extérieures à son réseau
local).

7. Transfert de données avec netcat ( nc )

L’outil Netcat (commande nc ) est connu comme le "couteau suisse" du réseau. Il peut établir des
connexions TCP ou UDP, écouter sur des ports, transférer des données, etc. Ici on va l’utiliser pour réaliser
une communication client/serveur simple entre deux terminaux, puis entre deux machines sur le réseau.
Netcat est très pratique pour tester et comprendre les flux réseau 2 3 .

7.1 Démarrer netcat en mode écoute (serveur)

Ouvrez un premier terminal sur la machine (Terminal 1). On va lancer netcat en mode “listen” sur un port
spécifique, par exemple le port 12345. La syntaxe diffère légèrement selon les versions de netcat, mais
fonctionne généralement avec l’option -l (listen) et -p <port> (port à écouter). On peut aussi écrire
nc -l <port> sur certaines versions.

Dans Terminal 1, tapez :

$ nc -l -p 12345

Cette commande met netcat en attente d’une connexion entrante sur le port 12345 (en TCP par défaut) sur
toutes les interfaces ([Link]). Aucune sortie n’apparaît, le curseur reste juste en place – netcat attend
qu’un client se connecte.

7.2 Établir la connexion depuis un second terminal (client)

Ouvrez un second terminal sur la même machine (Terminal 2). Ici, on va utiliser netcat en mode client pour
se connecter à notre serveur qui écoute. Étant sur la même machine pour ce test, on peut utiliser l’adresse
localhost ([Link]) comme destination, avec le même port.

Dans Terminal 2, tapez :

$ nc localhost 12345

Dès validation, si tout va bien, la connexion TCP est établie entre Terminal 2 et Terminal 1 via le port 12345.
Là encore, aucune confirmation textuelle n’apparaît, mais on peut maintenant échanger du texte entre les
deux terminaux.

16
7.3 Échanger des données entre les deux terminaux

Une fois la connexion netcat établie, tout ce que vous tapez dans l’un sera envoyé à l’autre, et vice-versa.
C’est comme une session de chat très simple.

• Dans Terminal 1, tapons par exemple : Hello from Terminal1 puis appuyez Entrée.
• Dans Terminal 2, on devrait voir apparaître cette ligne : Hello from Terminal1 (envoyée depuis
l’autre côté).
• Maintenant tapez quelque chose dans Terminal 2, par exemple : Hello from Terminal2 , puis
Entrée.
• Dans Terminal 1, la phrase tapée dans l’autre terminal apparaît à son tour.

Illustration :

Terminal 1 (serveur) :

$ nc -l -p 12345
Hello from Terminal2
Hello from Terminal1

Terminal 2 (client) :

$ nc localhost 12345
Hello from Terminal1
Hello from Terminal2

Comme on le voit, chaque terminal affiche le message envoyé par l’autre. L’ordre des lignes dépend de qui
parle en premier. Dans cet exemple, Terminal 1 a envoyé son message après que Terminal 2 ait envoyé le
sien, d’où l’ordre affiché. Mais l’important est qu’il y a bien une communication bidirectionnelle en temps
réel.

Pour terminer la session, il suffit de fermer un des netcat (par exemple Ctrl+C dans un terminal). L’autre côté
recevra un EOF (fin de fichier) et se terminera également.

Explication : Netcat a ouvert un socket TCP en écoute, le client s’y est connecté, et ensuite chaque côté lit
sur son entrée standard et envoie sur la socket tout ce qui est tapé. Cela prouve qu’on peut utiliser nc
pour établir rapidement une connexion TCP et échanger des données de manière brute (sans protocole
applicatif particulier).

7.4 Transfert de données entre deux machines distantes

Le test précédent était local (loopback). Netcat peut bien sûr fonctionner entre deux machines différentes
sur le réseau, ce qui est plus utile.

17
Pour reproduire l’exercice : - Choisissez deux machines sur le même réseau (ou avec connectivité entre
elles). Supposons Machine A et Machine B.
- Sur Machine A (Terminal 1 de A), lancez nc -l -p 12345 pour écouter sur un port.
- Sur Machine B (Terminal 1 de B), lancez nc <IP_de_A> 12345 pour vous connecter au port de A. Ici au
lieu de “localhost”, on utilise l’adresse IP de la machine A sur le réseau (par ex. [Link]).
- Une fois connecté, tout texte tapé sur A apparaîtra sur B et vice-versa, de la même manière que
précédemment.

On a simplement remplacé localhost par l’IP réseau de l’autre machine. Assurez-vous que le pare-feu
n’empêche pas la connexion sur ce port, et que les deux machines peuvent se joindre (ping, etc., doivent
fonctionner). En général sur un réseau local, ça marche si aucune règle ne bloque le port. Netcat peut ainsi
servir à échanger rapidement des messages ou tester la connectivité sur un port donné.

(Note : Ce genre de communication n’est pas chiffrée, c’est purement en clair sur le réseau, donc à éviter pour des
données sensibles sur un réseau non sécurisé. Netcat est toutefois très pratique pour des tests et transferts
temporaires sur des réseaux de confiance.)

8. Transfert de fichier avec netcat ( nc )

En plus de simples messages, netcat peut être utilisé pour transférer des fichiers entre machines, en
utilisant les redirections de l’interpréteur de commandes. L’idée est : on met netcat en écoute d’un côté et
on redirige ce qu’il reçoit vers un fichier, et de l’autre côté on redirige le contenu d’un fichier dans netcat.
Netcat va transférer l’ensemble des données brutes du fichier, permettant de recréer une copie à l’autre
bout 4 5 .

8.1 Préparation : deux terminaux (ou deux machines)

On va d’abord réaliser l’échange dans une même machine (deux terminaux), puis entre deux machines. Le
principe est identique, juste l’IP de destination qui change.

Créez d’abord un fichier à envoyer, par exemple appelé fichier_a_envoyer.txt , contenant quelques
données. (Cela peut être fait avec echo ou un éditeur).

Exemple de contenu :

Bonjour, ceci est un test de transfert de fichier via netcat.

Fin du fichier.

8.2 Terminal 1 : mode écoute pour recevoir le fichier

Dans Terminal 1, on lance nc en écoute sur un port (disons 12346 cette fois) et on redirige la sortie de
nc vers un fichier de destination. La syntaxe :

18
 $ nc -l -p 12346 > fichier_recu.txt

Ici, netcat attend une connexion sur le port 12346. Dès que quelqu’un se connectera et enverra des
données, ces données seront écrites (grâce au > ) dans le fichier fichier_recu.txt. Terminal 1 semble figé
en attente (ce qui est normal).

8.3 Terminal 2 : envoi du fichier via netcat

Dans Terminal 2, on va se connecter à Terminal 1 et envoyer le contenu du fichier. On utilise une redirection
d’entrée cette fois :

$ nc localhost 12346 < fichier_a_envoyer.txt

Cette commande va lire le contenu de fichier_a_envoyer.txt et l’envoyer directement dans la connexion

netcat vers localhost:12346 (où Terminal 1 écoute). Une fois l’envoi terminé (toute la fin du fichier envoyée),
netcat (côté client) va terminer la connexion et quitter. Terminal 2 reviendra à l’invite de commande.

Côté Terminal 1, netcat détecte la fin de la connexion (EOF) une fois le fichier reçu intégralement, et du coup
se termine aussi, rendant la main au shell. À ce moment, nous avons le fichier fichier_recu.txt
normalement rempli avec les données envoyées.

8.4 Vérification de la réception du fichier

Toujours sur la machine (Terminal 1, celui qui a reçu), on peut vérifier que le fichier a bien été créé et que
son contenu est correct. Par exemple :

$ ls -l fichier_a_envoyer.txt fichier_recu.txt
-rw-r--r-- 1 user user 70 Oct 10 12:00 fichier_a_envoyer.txt
-rw-r--r-- 1 user user 70 Oct 10 12:01 fichier_recu.txt

$ diff fichier_a_envoyer.txt fichier_recu.txt

$ # aucune différence => fichiers identiques

$ cat fichier_recu.txt
Bonjour, ceci est un test de transfert de fichier via netcat.
Fin du fichier.

On constate que les deux fichiers ont la même taille (70 octets dans cet exemple) et la comparaison ( diff )
ne montre aucune différence, ce qui confirme que le transfert s’est bien passé sans altération. Le contenu
de fichier_recu.txt est identique à celui du fichier source.

Ainsi, on a transféré un fichier complet via un simple canal netcat, sans FTP, sans SSH, juste par une
connexion TCP brute. C’est une méthode efficace et rapide pour échanger des fichiers en local ou sur des

19
réseaux fiables 4 5 . (Rappel de sécurité : le transfert se fait en clair, donc éviter d'envoyer des fichiers
sensibles de cette manière sur Internet.)

8.5 Transfert entre deux machines distinctes

Le même procédé fonctionne entre deux machines. Supposons Machine A (doit recevoir) et Machine B
(envoie).

• Sur Machine A (receveur) :

$ nc -l -p 12346 > fichier_recu.txt

(En attente sur, par exemple, l’adresse IP [Link]:12346)

• Sur Machine B (émetteur) :

$ nc [Link] 12346 < fichier_a_envoyer.txt

Ici, on utilise l’adresse IP de A. Une fois la connexion établie, Machine B envoie le fichier puis termine
la connexion.

Après cela, sur Machine A, netcat se termine et le fichier fichier_recu.txt est créé. Il suffit de comparer ou lire
le fichier sur A pour confirmer la réussite.

Conclusion : Netcat permet ainsi d’échanger rapidement des données ou des fichiers d’une machine à
l’autre, simplement en écoutant d’un côté et en se connectant de l’autre, puis en utilisant les redirections
shell pour lire/écrire dans des fichiers. C’est un outil très polyvalent pour le dépannage réseau et le transfert
ad-hoc de fichiers 4 5 .

Sources utilisées :

• Manuel et documentation Linux (commande ifconfig , ip , hostnamectl , etc.)

• Discussion sur la dépréciation de net-tools ( ifconfig ) au profit de iproute2 1

• Varonis – Comment utiliser les commandes Netcat (pour compréhension des usages de netcat) 2 3
• IT-Connect – Échanger rapidement des données en TCP via netcat (exemples de transfert de fichier avec
netcat) 4 5

1 linux - ip versus ifconfig - Super User

[Link]

2 3 4 5 Echanger rapidement des données en TCP via netcat | IT-Connect

[Link]

20