Chapitre 6.1 — TCP/IP & ports

⏱️ TL;DR — Deux notions suffisent pour tout le réseau de ce cours. L’IP est l’adresse de la machine (comme l’adresse d’un immeuble) ; le port est l’adresse du service sur cette machine (comme le numéro d’appartement). Une connexion, c’est toujours un couple IP + port : 203.0.113.10:443 = « le service HTTPS de cette machine ». Tu apprends ici à lire une IPv4 et une IPv6, à reconnaître les ports connus (22, 80, 443, 5432…), et surtout la distinction qui protège ou expose ton serveur : un service qui écoute sur 127.0.0.1 n’est joignable que depuis la machine elle-même ; sur 0.0.0.0, il est ouvert à tout Internet. Confondre les deux, c’est offrir sa base de données au premier scanner venu.

🎯 Objectifs

• Expliquer la différence entre une IP (la machine) et un port (le service), et lire un couple IP:port.
• Lire la notation IPv4 et IPv6, et savoir pourquoi l’IPv6 existe (pénurie d’IPv4).
• Reconnaître les ports connus et savoir à quel service chacun correspond.
• Comprendre la différence entre TCP et UDP en une phrase.
• Maîtriser le concept clé de sécurité : écouter sur 127.0.0.1 (local) vs 0.0.0.0 (toutes les interfaces).
• Lister les interfaces réseau de ta machine avec ip a et distinguer IP privée et publique.

IP et port : l’immeuble et l’appartement

Quand deux machines se parlent sur un réseau, il leur faut deux informations : quelle machine, et quel service sur cette machine.

• L’adresse IP identifie la machine sur le réseau. C’est l’équivalent de l’adresse postale d’un immeuble : 203.0.113.10. Le réseau sait router un paquet vers cette adresse.
• Le port identifie le service à l’intérieur de la machine. Une même machine fait tourner plusieurs services en même temps : un serveur web, un serveur SSH, une base de données. Le port dit auquel s’adresser. C’est le numéro d’appartement dans l’immeuble.

Une connexion s’écrit donc toujours comme un couple IP:port. 203.0.113.10:22, c’est « le service SSH de la machine 203.0.113.10 ». 203.0.113.10:443, c’est « son service HTTPS ». Même immeuble, appartements différents.

💡 Réflexe — Dès qu’un service « ne répond pas », pose-toi les deux questions séparément : la machine est-elle joignable (l’IP répond-elle) et le bon port est-il ouvert et écouté ? Ce sont deux maillons distincts. On ne les diagnostique pas avec les mêmes outils (chapitre 6.4).

IPv4 et IPv6 : deux notations

Il existe deux versions d’adresses IP, et ton VPS en a probablement des deux.

• IPv4 : quatre nombres de 0 à 255 séparés par des points, par exemple 203.0.113.10. C’est la notation historique, celle que tout le monde connaît. Problème : elle ne permet qu’environ 4,3 milliards d’adresses — largement insuffisant aujourd’hui. On parle de pénurie d’IPv4 : les adresses sont rares, et un fournisseur de VPS peut même facturer en supplément une IPv4 dédiée.
• IPv6 : huit groupes hexadécimaux séparés par des deux-points, par exemple 2001:db8::1. Beaucoup plus long, mais l’espace est gigantesque (de quoi adresser chaque grain de sable de la planète, et bien plus). Les zéros consécutifs peuvent se compresser avec :: (une seule fois par adresse).

En pratique, tu configures souvent les deux : un enregistrement DNS A pointe vers ton IPv4, un enregistrement AAAA vers ton IPv6 (chapitre 6.2). Le visiteur utilisera l’une ou l’autre selon sa connexion, de façon transparente.

📚 La doc — Les adresses 203.0.113.x, 2001:db8:: et quelques autres plages sont réservées à la documentation (RFC 5737 et RFC 3849). On les emploie dans les exemples pour ne jamais pointer par erreur vers une vraie machine. Ton VPS, lui, aura de vraies adresses fournies par ton hébergeur.

Les ports connus

Certains ports sont attribués par convention à des services standards. Les connaître par cœur fait gagner un temps fou en diagnostic.

Les ports inférieurs à 1024 (dits « privilégiés ») sont réservés au système : seul root — ou un processus explicitement autorisé — peut les ouvrir. C’est pour ça que Nginx (qui écoute sur 80 et 443) tourne avec les privilèges qu’il faut, tandis que ton app Node écoute plus haut, sur 3000 par exemple, sans privilège spécial.

💡 Réflexe — Ton app Next.js ne doit pas écouter directement sur 443. Elle écoute sur un port haut et local (3000), et c’est Nginx qui prend le 443 public et relaie vers elle. On voit ce montage en Partie 7. Retiens juste : port public (Nginx) ≠ port de l’app (interne).

TCP vs UDP : en deux phrases

Sous l’IP et les ports, deux protocoles de transport se partagent le travail. TCP établit une connexion fiable et ordonnée (poignée de main, accusés de réception, retransmission des paquets perdus) : c’est ce qu’utilisent le web, SSH et les bases de données — tout ce qui exige que rien ne se perde. UDP envoie les paquets sans garantie ni connexion préalable : plus rapide, plus léger, il sert quand un paquet perdu n’est pas grave (DNS, streaming, jeux, VoIP).

Le concept clé : 127.0.0.1 vs 0.0.0.0

Voici la notion de sécurité de ce chapitre. Quand un service démarre, il choisit sur quelle interface écouter — c’est-à-dire d’où il accepte les connexions. Ce choix détermine s’il est privé ou exposé au monde.

• 127.0.0.1 (aussi appelé localhost ou l’interface loopback) est une adresse spéciale qui désigne la machine elle-même. Un service qui écoute sur 127.0.0.1 n’accepte que les connexions venant de la machine locale. Depuis l’extérieur, il est invisible : les paquets d’Internet ne l’atteignent même pas. C’est le réglage sûr pour tout ce qui ne doit parler qu’à d’autres processus de la même machine.
• 0.0.0.0 est un joker qui signifie « toutes les interfaces réseau de la machine ». Un service qui écoute sur 0.0.0.0 accepte les connexions de partout — y compris depuis Internet, si l’IP publique est joignable et le pare-feu ouvert. C’est nécessaire pour un service public (Nginx sur 80/443), et dangereux pour tout le reste.

Prends une base de données. Elle ne doit parler qu’à ton application, qui tourne sur la même machine. Donc elle doit écouter sur 127.0.0.1 : l’app la joint en local, personne d’autre n’y touche. Si par erreur elle écoute sur 0.0.0.0, elle devient visible depuis Internet — et les robots qui scannent en permanence le port 5432 la trouveront en quelques heures.

# Voir qui écoute quoi, et sur quelle interface
ss -tulpn
# Colonne "Local Address:Port" :
#   127.0.0.1:5432  -> Postgres n'ecoute qu'en local. Bien.
#   0.0.0.0:5432    -> Postgres ecoute sur toutes les interfaces. DANGER.
#   0.0.0.0:443     -> Nginx ecoute partout. Normal, c'est fait pour etre public.

🔒 Sécurité — La règle d’or : un service n’écoute sur 0.0.0.0 que s’il a vocation à être public. Nginx : oui, sur 80 et 443. Une base de données, un cache Redis, un panneau d’admin interne, un service Node avant Nginx : non, ils écoutent sur 127.0.0.1. Beaucoup de fuites de données massives viennent exactement de ça — une base laissée à l’écoute sur 0.0.0.0, sans mot de passe ou avec le mot de passe par défaut. Le pare-feu (UFW, Partie 5) est une seconde barrière, mais la première défense, c’est de ne pas écouter là où il ne faut pas.

⚠️ Piège — « Ça marche en local mais pas en prod » vient souvent de l’inverse : un service configuré pour écouter uniquement sur 127.0.0.1 alors qu’il devait être joignable d’ailleurs. Avant de toucher au pare-feu ou au DNS, vérifie sur quelle adresse le service écoute vraiment avec ss -tulpn. Un service qui n’écoute que sur 127.0.0.1 ne sera jamais joignable de l’extérieur, quel que soit l’état du pare-feu.

Les interfaces réseau : ip a

Ta machine a plusieurs interfaces réseau — des « prises » virtuelles ou physiques par lesquelles elle communique. La commande ip a (raccourci de ip address) les liste.

ip a
# lo    -> l'interface loopback (127.0.0.1). Toujours presente, purement locale.
# eth0  -> l'interface Ethernet principale, avec l'IP du reseau (souvent l'IP publique du VPS)

Tu y verras au minimum deux interfaces :

• lo : le loopback, qui porte 127.0.0.1. C’est la machine qui se parle à elle-même. Elle existe toujours, même sans réseau.
• eth0 (ou un nom voisin comme ens3, enp1s0) : l’interface réseau réelle, qui porte l’IP par laquelle la machine est jointe sur son réseau.

🐚 Au terminal — Pour aller droit à l’IP d’une interface sans le reste :

ip -brief a          # vue condensee, une ligne par interface
ip a show eth0       # detaille une interface precise

IP privée vs publique, et le NAT (en survol)

Deux dernières notions, en survol, pour ne pas être surpris.

Toutes les IP ne sont pas routables sur Internet. Certaines plages sont privées — réservées aux réseaux locaux — et jamais visibles publiquement : 10.x.x.x, 172.16.x.x à 172.31.x.x, et 192.168.x.x (ton réseau domestique, typiquement 192.168.1.x). À l’inverse, une IP publique est unique sur Internet et joignable de partout : c’est celle de ton VPS.

Le NAT (Network Address Translation) est le mécanisme qui fait le pont : chez toi, une seule IP publique (celle de ta box) « masque » plusieurs machines aux IP privées. C’est pour ça que ton portable en 192.168.1.20 peut naviguer sur le web sans avoir d’IP publique à lui.

🧭 Sur FormaCampus — Le VPS de FormaCampus a une IP publique fixe, disons 203.0.113.10 (IPv4) et 2001:db8::10 (IPv6). C’est vers elle que pointera le domaine formacampus.fr (chapitre 6.3). Sur cette machine, l’équipe applique la règle à la lettre : Nginx écoute sur 0.0.0.0:443 (il est public, c’est son rôle) ; le front Next.js écoute sur 127.0.0.1:3000 et l’API Symfony sur 127.0.0.1:8000 (internes, joignables seulement par Nginx) ; Postgres écoute sur 127.0.0.1:5432 (la base ne parle qu’à l’API, sur la même machine). Résultat : de l’extérieur, seuls 22 (SSH), 80 et 443 répondent. Tout le reste est invisible — exactement ce qu’on veut.

✏️ Exercices

Exercice 1 — Lis les adresses. Pour chaque couple, dis quelle machine, quel service, et si le service est local ou exposé : (a) 127.0.0.1:5432 ; (b) 0.0.0.0:443 ; (c) 203.0.113.10:22.

Exercice 2 — Repère le danger. Tu lances ss -tulpn sur ton VPS et tu vois ces lignes. Laquelle est un problème de sécurité, et pourquoi ?

0.0.0.0:443    nginx
127.0.0.1:3000 node
0.0.0.0:5432   postgres
127.0.0.1:6379 redis-server

🧠 Quiz de révision

Chapitre suivant : Comment marche le DNS — l’annuaire qui traduit formacampus.fr en IP, et pourquoi un changement n’est jamais instantané.