Quiz : Le modèle TCP/IP

Le premier décide à partir des informations de transport (adresses et ports, TCP ou UDP) sans lire le contenu ; le second comprend le protocole applicatif (HTTP : chemin, en-têtes, cookies) et peut router selon lui, terminer TLS, ajouter X-Forwarded-For. Les numéros viennent du modèle OSI, resté le vocabulaire commun. Leçon 1.

Ethernet 14 octets d'en-tête et 4 de FCS (hors MTU), IPv4 20, TCP 20. La MTU de 1 500 couvre IP et ce qu'il transporte : 1 500 − 20 − 20 = 1 460 octets de données, la MSS habituelle (1 448 sous Linux avec l'option d'horodatage). Leçons 1 et 6.

Celle de sa passerelle (la box, 192.168.1.1), pas celle de la destination finale : l'adresse IP de destination reste 203.0.113.10, mais la trame ne va qu'au prochain saut. Il obtient cette MAC par ARP (requête diffusée « qui a 192.168.1.1 ? »), puis la garde en cache (ip neigh). Leçons 2 et 5.

ARP n'a aucune authentification : n'importe quelle machine du réseau local peut répondre à la place d'une autre et détourner le trafic (usurpation ARP). Les commutateurs ont des protections (inspection ARP dynamique, limitation des MAC par port), mais la protection qui tient partout est le chiffrement de bout en bout (TLS, SSH) : un trafic détourné reste illisible et non modifiable. Leçon 2.

Masque 255.255.252.0. Le bloc va de 172.16.20.0 à 172.16.23.255 : diffusion 172.16.23.255. 2^10 − 2 = 1 022 hôtes, avant les adresses que réserve le fournisseur cloud. Leçons 3 et 4.

127.0.0.1 n'est joignable que depuis la machine elle-même : une connexion qui arrive sur l'adresse privée 172.16.20.11 ne trouve personne à l'écoute, et le noyau répond par un RST. Il faut écouter sur l'adresse privée (ou 0.0.0.0, en connaissant les conséquences). ss -ltn le montre. Leçons 3 et 12.

On emprunte 2 bits : quatre /24, 172.16.20.0/24, 172.16.21.0/24, 172.16.22.0/24, 172.16.23.0/24. Chaque bit emprunté double le nombre de sous-réseaux et divise leur taille par deux. Leçon 4.

Le pont docker0 utilise par défaut 172.17.0.0/16 : son poste a une route directe vers ce bloc, plus longue que la route qui mène au VPN, et le trafic part vers Docker. Un chevauchement de plages privées ; on le voit avec ip route get 172.17.0.30. Remède : déplacer la plage de Docker, et tenir un registre des plages. Leçons 4 et 5.

Le plus long préfixe l'emporte. 172.16.20.50 correspond aux trois routes ; la plus précise est le /24 : via 172.16.20.9. 172.16.22.4 correspond au /22 et à la route par défaut : remise directe sur ens2. Leçon 5.

Non : beaucoup de pare-feux et de groupes de sécurité jettent les échos ICMP. Un ping échoué ne prouve presque rien ; un ping réussi ne prouve que la joignabilité IP pour de petits paquets. On teste un service par le service (nc -vz, curl). Leçon 6.

Un trou noir PMTU : un lien du chemin a une MTU plus petite (tunnel, VPN), les gros paquets avec DF sont jetés, et l'ICMP « fragmentation nécessaire » qui devrait prévenir l'émetteur est filtré. Les petits paquets passent, les gros non. Remèdes : laisser passer cet ICMP, MSS clamping, ou MTU réduite. Leçon 6.

Le répartiteur ouvre ses propres connexions vers les instances, depuis son adresse privée : l'adresse d'origine est perdue au niveau IP (comme derrière un NAT source). Un répartiteur HTTP la transmet dans l'en-tête X-Forwarded-For, un répartiteur TCP par le protocole PROXY ; l'application ne doit faire confiance à ces informations que si elles viennent du répartiteur. Leçons 7 et 12.

Le NAT n'est pas un pare-feu : son effet de filtrage n'est qu'un effet de bord (aucune entrée de traduction pour une connexion entrante non prévue), qui disparaît avec une redirection de port, avec IPv6, ou depuis le réseau interne. La sécurité vient de règles de filtrage explicites. Leçon 7.

2001:db8::10 (zéros de tête supprimés, :: pour la plus longue suite de groupes nuls, minuscules). URL : http://[2001:db8::10]:8000/sante, les crochets séparant l'adresse du port. Leçon 8.

IPv6 en dépend : NDP (découverte des voisins et des routeurs, remplaçant d'ARP) passe par ICMPv6, et comme les routeurs ne fragmentent jamais, le message « paquet trop gros » est indispensable à la découverte du MTU du chemin. La RFC 4890 liste ce qu'il faut laisser passer. Leçons 6 et 8.

Protocole, adresse source, port source, adresse de destination, port de destination : il identifie une connexion. Chaque connexion du client reçoit un port source éphémère différent (32768 à 60999 par défaut sous Linux), donc un quintuplet différent. Leçon 9.

Par exemple DNS, NTP, DHCP, syslog, QUIC (HTTP/3), WireGuard. UDP ne garantit ni la remise, ni l'ordre, ni l'unicité : l'application gère elle-même les pertes (réémission, délais), l'ordre et le contrôle du débit. Leçon 9.

« Refused » : la machine est joignable et son noyau a répondu au SYN par un RST : rien n'écoute sur ce port (ou un pare-feu rejette activement). « Timed out » : aucune réponse, le SYN ou sa réponse sont jetés en route (groupe de sécurité, pare-feu en drop, machine éteinte, file accept pleine). C'est la première bifurcation de tout diagnostic. Leçons 10 et 12.

Dans l'application : CLOSE-WAIT signifie que l'autre côté a fermé (FIN reçu) et que le programme local n'a pas encore fermé sa socket. Une accumulation est un bogue applicatif (socket jamais fermée, fuite dans un pool). TIME-WAIT, à l'inverse, est normal et disparaît seul. Leçon 10.

Il faut une poignée de main (un aller-retour), puis le démarrage lent : la fenêtre de congestion part de 10 segments et double à chaque aller-retour. Sur un long trajet, ces allers-retours dominent. Le plus efficace est de réutiliser les connexions (keep-alive HTTP, pool de connexions vers PostgreSQL) plutôt que d'en ouvrir une par requête. Leçon 11.