Observer les ports et les connexions

Objectifs

À la fin de cette leçon, vous saurez :

• cartographier les ports en écoute avec ss -lntp, ligne par ligne ;
• distinguer une écoute sur 127.0.0.1 d'une écoute sur 0.0.0.0 — et prédire la joignabilité ;
• diagnostiquer un conflit de port (EADDRINUSE) et identifier le processus fautif ;
• observer des connexions TCP vivantes avec ss -tnp.

🔗 Pour vous rafraîchir la mémoire : observer les processus · TCP, UDP et sockets

Lister ce qui écoute : ss -lntp

ss -lntp

Décodage des options : listen (uniquement en écoute), numérique (ne résous pas les noms, plus rapide et sans dépendance DNS), tcp, processus.

Sortie type, annotée :

State   Recv-Q  Local Address:Port    Peer Address:Port   Process
LISTEN  0       0.0.0.0:22            0.0.0.0:*           users:(("sshd",pid=512))
LISTEN  0       127.0.0.1:3000        0.0.0.0:*           users:(("node",pid=2041))
LISTEN  0       [::]:22               [::]:*              users:(("sshd",pid=512))

Colonne par colonne :

• State LISTEN : le processus attend des connexions entrantes (vs connexions établies, voir plus bas) ;
• Local Address:Port : OÙ il attend — c'est la colonne décisive ;
• Peer : en écoute, toujours * (« n'importe qui ») ;
• Process : le propriétaire, nom + PID — le lien direct avec le chapitre processus.

La distinction qui explique 80 % des mystères de connexion

Regardez les deux lignes Node/SSH ci-dessus : même machine, ports différents, mais surtout adresses d'écoute différentes :

Écoute sur	Signification	Joignable depuis
0.0.0.0:3000	toutes les interfaces réseau de la machine	le monde entier (si firewall/NAT le permettent)
127.0.0.1:3000	uniquement la boucle locale	la machine elle-même, point final
192.168.65.3:3000	uniquement cette interface précise	ce segment réseau seulement

([::] est l'équivalent IPv6 de 0.0.0.0.)

C'est LA cause n°1 du classique « mon serveur tourne mais je n'y accède pas depuis l'autre machine » : le serveur écoute sur 127.0.0.1, donc il ne répond qu'à son propre hôte — comportement souvent voulu (défaut prudent de beaucoup de frameworks), jamais accidentel à ignorer. Le réflexe professionnel avant toute autre investigation : ss -lntp | grep <port> et lire l'adresse d'écoute.

Créons un serveur pour expérimenter

Lançons un petit serveur HTTP jetable :

$ python3 -m http.server 8000
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

Dans un second terminal, vérifions :

ss -lntp | grep 8000
LISTEN 0  2048  0.0.0.0:8000  0.0.0.0:*  users:(("python3",pid=4120,fd=3))

Le serveur écoute sur toutes interfaces : joignable depuis le réseau local (sous réserve firewall/NAT, comme toujours). Notez au passage le PID 4120 : nous savons désormais exactement quel processus possède ce port.

Provoquer le conflit : EADDRINUSE

Tentons un second serveur sur le même port :

$ python3 -m http.server 8000
Traceback (most recent call last):
  ...
OSError: [Errno 98] Address already in use

Le noyau refuse : rappel de la théorie, une seule socket en écoute par couple adresse/port — sinon, qui recevrait les paquets ? Ce message (EADDRINUSE) est l'un des plus fréquents de votre carrière ; il a maintenant un sens précis.

Trois issues possibles, dans l'ordre logique :

1. Changer de port pour le nouveau processus (le plus simple) ;
2. Arrêter l'occupant si c'est un vestige oublié — vous avez son PID :

   kill 4120          # signal poli SIGTERM (chapitre 2)
   ss -lntp | grep 8000   # réponse vide → port libéré
   

3. Comprendre que l'occupant est légitime (un vrai service tourne déjà là !) et ne rien toucher.

⚠️ Cas subtil à connaître : le port semble libre mais l'erreur persiste après avoir tué le processus. Cause fréquente : une connexion TCP encore en cours de fermeture retient le port quelques dizaines de secondes (TIME_WAIT) ; ou bien un autre utilisateur/service détient le port mais ss ne vous montre pas son PID sans droits suffisants. Diagnostic : sudo ss -lntp | grep 8000 révèle tout.

Observer les connexions vivantes : ss -tnp

Sans -l, on voit les connexions établies plutôt que les écoutes :

ss -tnp
ESTAB 0 0 192.168.65.3:22      192.168.65.1:51234  users:(("sshd",pid=512))

Lecture : votre session SSH actuelle ! Chaque ligne EST un quadruplet complet de la théorie : IP locale + port local ↔ IP distante + port distant. Remarquez le port distant 51234 : c'est le port source éphémère choisi par le client SSH côté hôte — la théorie du quadruplet sous vos yeux.

Faites l'expérience complète : lancez le serveur Python ci-dessus, puis dans un autre terminal connectez-vous dessus :

curl http://localhost:8000 > /dev/null &
ss -tnp | grep 8000
ESTAB 0 0 127.0.0.1:8000   127.0.0.1:45678  users:(("python3",pid=4120))

Deux extrémités, deux rôles : python3 sur SON port d'écoute (8000), curl sur un port éphémère (45678). La connexion meurt aussitôt après l'échange — relancez le grep, elle aura disparu.

Exercice

1. Listez les ports en écoute de votre VM. Quels services tournent déjà ? Lesquels sont accessibles depuis l'extérieur ?
2. Lancez python3 -m http.server 8000 et retrouvez-le dans ss -lntp. Sur quelle adresse écoute-t-il ? Que peut-on en déduire sur sa joignabilité ?
3. Tentez d'en lancer un second sur le même port : notez l'erreur exacte, puis libérez le port proprement.
4. Faites une requête curl vers lui pendant qu'il tourne et attrapez la connexion ESTAB avec ss -tnp. Identifiez le quadruplet.
5. Question de réflexion : PostgreSQL (port 5432) devrait-il écouter sur 0.0.0.0 ou 127.0.0.1 sur un serveur web ? Pourquoi ?

Résumé

• ss -lntp = la cartographie des portes ouvertes de la machine, avec propriétaires.
• Adresse d'écoute = décision de sécurité : 127.0.0.1 (invisible) vs 0.0.0.0 (exposé).
• EADDRINUSE = un couple adresse/port, un seul propriétaire ; diagnostic avant démarrage.
• ss -tnp montre les quadruplets vivants : la théorie rendue visible.

OSError: [Errno 98] Address already in use

ss -lntp | grep 8000              # retrouver le PID
kill <pid>                        # SIGTERM poli
ss -lntp | grep 8000              # vide → libéré, vérifié

ESTAB 0 0 127.0.0.1:8000  127.0.0.1:<port_éphémère>  users:(("python3",...))