Cours Réseau — modèle en couches, IP, routage, DNS, TCP/UDP et diagnostic sur macOS

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. situer un protocole dans le modèle en couches et décrire l'encapsulation ;
2. distinguer adresse MAC, adresse IP, port, et dire à quoi sert un VLAN ;
3. lire une notation CIDR, calculer taille et plage d'un sous-réseau ;
4. expliquer le routage (passerelle par défaut, table de routage) ;
5. décrire le rôle de DNS et de DHCP et ce qu'un client en obtient ;
6. comparer TCP et UDP ; lire l'état d'une connexion ;
7. expliquer en surface ce que TLS garantit, et ce que font NAT et pare-feu ;
8. conduire un diagnostic du bas vers le haut avec des commandes macOS en lecture seule, et dire ce qu'une commande ne prouve pas.

Prérequis

• Savoir ouvrir Terminal et lire une commande avant de la valider (cours « Terminal macOS »).
• Notions de binaire (un octet = 8 bits) et de base 2.
• Aucun accès à un réseau d'entreprise n'est requis ; si Stéphane veut pratiquer, uniquement sur son propre poste et son propre réseau local.

Parcours et chapitres

1. Le modèle en couches et l'encapsulation

Le RFC 1122 (octobre 1989) décrit l'architecture d'Internet en quatre couches : application (protocoles utilisateur et de soutien comme DNS), transport (TCP, UDP), Internet (IP, avec ICMP pour les erreurs) et liaison (accès au support, propre à chaque type de réseau). Il décrit aussi l'encapsulation : une trame est un en-tête de liaison suivi d'un paquet, qui est un en-tête IP suivi des données de transport ; un segment TCP est un en-tête TCP suivi des données applicatives.

Le modèle OSI à sept couches (norme ISO/IEC 7498-1) est souvent cité dans les formations. Sa norme n'a pas été lue pour ce cours : le découpage exact et la correspondance avec les quatre couches ci-dessus sont non vérifiés ici. Retenir seulement que « couche 2 » désigne couramment Ethernet et « couche 3 » IP.

2. Ethernet, adresses MAC et VLAN

Sur un réseau local, l'envoi se fait par adresse MAC (48 bits). Le RFC 826 (novembre 1982, ARP) explique comment un hôte qui connaît une adresse IP mais pas l'adresse matérielle diffuse une requête ARP ; la cible répond avec son adresse, que l'émetteur met en cache.

Un VLAN découpe un commutateur en plusieurs réseaux locaux logiques isolés : deux machines de VLAN différents ne se parlent qu'en passant par un routeur. La norme est IEEE 802.1Q (révision 802.1Q-2022, publiée le 22 décembre 2022 d'après la page de l'IEEE, qui indique un téléchargement sans frais via le programme GET). Le contenu de la norme n'a pas été lu : le format de l'étiquette (tag), les trunks et les VLAN natifs sont non vérifiés dans ce cours.

Côté macOS, networksetup sait lister les VLAN et les interfaces qui en acceptent (-listVLANs, -listdevicesthatsupportVLAN), voir chapitre 9.

3. IP, CIDR et sous-réseaux

IPv4. Une adresse fait 32 bits, écrite en quatre octets. Le RFC 4632 (BCP 122, août 2006) définit la notation CIDR : une adresse suivie de « / » et d'un nombre de 0 à 32, qui donne le nombre de bits de la partie réseau ; il remplace les anciennes classes A, B, C et permet l'agrégation des routes.

Par convention, la première adresse désigne le réseau et la dernière la diffusion (broadcast), d'où 254 hôtes utilisables dans un /24. Cette convention ne figure pas dans le RFC 4632 lu : elle est non vérifiée ici (RFC 1122 à relire). Découper 192.0.2.0/24 en quatre /26 donne 192.0.2.0/26, 192.0.2.64/26, 192.0.2.128/26 et 192.0.2.192/26.

Adresses réservées. Le RFC 1918 (BCP 5, février 1996) réserve aux réseaux privés 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16, utilisables sans coordination avec un registre. Le RFC 5737 (janvier 2010) réserve trois blocs pour la documentation : 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 (c'est ce que ce corpus emploie).

IPv6. Le RFC 4291 (février 2006) : adresses de 128 bits, huit groupes de 16 bits en hexadécimal, un seul :: pour condenser des zéros consécutifs, notation de préfixe adresse/longueur comme en CIDR ; types unicast, anycast et multicast ; le multicast remplace la diffusion ; adresses de lien local FE80::/10. Le RFC 3849 (juillet 2004) réserve 2001:db8::/32 à la documentation.

4. Routage et passerelle par défaut

Un hôte compare l'adresse de destination à son propre sous-réseau : si elle y est, il envoie directement (après résolution ARP) ; sinon, il envoie à sa passerelle par défaut (un routeur), qui consulte sa table de routage et transmet au saut suivant. À chaque saut, le champ TTL de l'en-tête IP diminue ; à zéro, le paquet est jeté et un message ICMP « Time Exceeded » (type 11) est renvoyé. ICMP (RFC 792) sert aussi à signaler « Destination Unreachable » (type 3) et à l'écho (types 8 et 0) utilisé par ping.

Les protocoles de routage dynamique (OSPF, BGP) ne sont pas traités : non couverts, sources non lues.

5. DNS : transformer un nom en adresse

D'après le RFC 1034 (novembre 1987) : l'espace de noms est un arbre (étiquettes séparées par des points, racine en haut) ; trois composants : l'espace de noms avec ses enregistrements (RR), les serveurs de noms (qui détiennent des zones et répondent ou renvoient vers un autre serveur) et les résolveurs (côté client, avec un cache). Les réponses sont gardées en cache selon leur TTL. Le RFC 1035 (même série, STD 13) définit les enregistrements usuels : A (adresse IPv4), NS, CNAME (alias), MX (messagerie), PTR (résolution inverse), TXT, SOA ; le transport est UDP port 53 pour les requêtes courantes, TCP pour les gros messages et les transferts de zone.

Les enregistrements IPv6 (AAAA), DNSSEC et DNS chiffré ne sont pas dans ces RFC : non vérifiés ici.

6. DHCP : obtenir sa configuration

Le RFC 2131 (mars 1997) : un client sans configuration diffuse un DHCPDISCOVER ; des serveurs répondent par DHCPOFFER ; le client choisit et diffuse un DHCPREQUEST ; le serveur retenu valide par DHCPACK. Le bail (lease) est limité dans le temps : le client peut le prolonger ou rendre l'adresse. Le serveur fournit au-delà de l'adresse : masque, routeurs par défaut, serveurs DNS et autres options.

7. TCP et UDP

UDP (RFC 768, 28 août 1980) : sans connexion, sans garantie de livraison ni de protection contre les doublons ; en-tête minimal (ports source et destination, longueur, somme de contrôle). Convient aux échanges courts tolérants à la perte, comme une requête DNS.

TCP (RFC 9293, août 2022, qui remplace le RFC 793) : un flux d'octets fiable et ordonné, avec connexion. L'ouverture se fait par un échange en trois temps (SYN, SYN-ACK, ACK) ; les états usuels sont LISTEN (serveur en attente), SYN-SENT et SYN-RECEIVED (ouverture), ESTABLISHED (échange) et TIME-WAIT (nettoyage). Les ports identifient les services.

8. TLS, NAT et pare-feu en surface

TLS 1.3 (RFC 8446, août 2018, voie des normes) établit un canal sécurisé avec trois garanties : confidentialité, intégrité, authentification (toujours du serveur, du client en option). Le serveur présente un certificat que le client valide, puis prouve qu'il possède la clé privée associée. Le client annonce ses versions, suites et paramètres d'échange de clés (ClientHello), le serveur choisit (ServerHello), puis les deux dérivent des clés de trafic. TLS ne cache ni les adresses ni les ports, et ne protège pas contre un serveur malveillant authentifié.

NAT (RFC 3022, janvier 2001, informationnel) : le NAT de base associe une adresse privée à une adresse publique ; le NAPT fait partager une seule adresse publique à plusieurs hôtes en traduisant aussi les ports. Limites citées : fragments TCP/UDP, bris du chiffrement IP de bout en bout (IPsec), diagnostic plus difficile, certaines applications exigeant des passerelles applicatives. Un NAT n'est pas un pare-feu.

Pare-feu sur macOS. La documentation Apple (« Block connections to your Mac with a firewall », guide Aide macOS) décrit l'activation dans Réglages Système > Réseau > Pare-feu et les réglages par app ou service. Le filtre de paquets système s'appelle pf et se pilote avec pfctl (nécessite les droits root). La page de manuel lue provient du miroir précité, sa version est non vérifiée ; le lien entre l'interface Apple et pf est non vérifié.

Attention, effet notable. Cette commande peut s'exécuter avec des droits élevés. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

sudo pfctl -s info

• Contexte : Terminal macOS, version non confirmée.
• Droits : administrateur (sudo).
• Effet : lecture seule de l'état du filtre ; aucun changement.
• Vérification : une ligne « Status: Enabled » ou « Disabled » (libellé exact non vérifié).
• Retour arrière : sans objet.

9. Diagnostic sur macOS, en lecture seule

Méthode : du bas vers le haut. Une seule hypothèse à la fois, une commande à la fois, un résultat noté.

Étape 1 : mon interface et mes réglages (couches liaison, Internet).

networksetup -listallnetworkservicesnetworksetup -listallhardwareportsnetworksetup -getinfo "Wi-Fi"networksetup -getdnsservers "Wi-Fi"

• Contexte : Terminal macOS ; le nom de service (Wi-Fi, Ethernet…) vient de la première commande.
• Droits : utilisateur courant (selon la page de manuel, networksetup exige des droits d'administrateur pour modifier, pas pour lire ; non vérifié pour chaque option).
• Effet : affichage de la configuration ; rien n'est modifié.
• Vérification : adresse, masque et routeur cohérents avec le réseau.
• Retour arrière : sans objet.

Étape 2 : table de routage et DNS vus par le système.

netstat -rnnetstat -iscutil --dns

• Contexte : Terminal macOS, version non confirmée.
• Droits : utilisateur.
• Effet : lecture seule (netstat ne modifie rien, scutil --dns et --proxy sont des lectures).
• Vérification : une route default vers le routeur attendu ; des serveurs DNS attendus.
• Retour arrière : sans objet.

Étape 3 : joindre la passerelle, puis un tiers (ICMP). ping envoie des ICMP ECHO_REQUEST et mesure les temps et les pertes ; -c limite le nombre d'envois. traceroute joue sur le TTL pour obtenir un « Time Exceeded » de chaque saut ; -n évite les résolutions DNS et * indique l'absence de réponse dans le délai (équipement silencieux ou filtré, pas forcément une panne).

ping -c 3 192.0.2.1traceroute -n -m 8 198.51.100.10

• Contexte : exemples avec adresses de documentation, qui ne répondront pas sur Internet : les remplacer par ses propres équipements.
• Droits : utilisateur courant.
• Effet : émission de quelques paquets ; aucun scan. Ne jamais viser un réseau qui n'est pas le sien.
• Vérification : 0 % de perte vers la passerelle avant d'accuser l'amont.
• Retour arrière : sans objet.

Étape 4 : DNS. dig interroge un serveur de noms (@serveur, type d'enregistrement avec -t, +short pour une réponse concise, +trace pour suivre la délégation depuis la racine, +tcp pour forcer TCP). La page lue est celle de la documentation BIND 9 ; la version fournie avec macOS est non vérifiée.

dig example.com A +shortdig example.com MXdig @192.0.2.53 www.example.com A

• Contexte : Terminal macOS ; 192.0.2.53 est un serveur fictif à remplacer par le sien.
• Droits : utilisateur.
• Effet : émission de requêtes DNS ; aucune modification.
• Vérification : section ANSWER cohérente avec la zone attendue.
• Retour arrière : sans objet.

Étape 5 : service d'écoute et connexions. lsof -i -n -P -sTCP:LISTEN liste les ports TCP en écoute (-n et -P évitent noms d'hôtes et de services) ; sans sudo, seuls les processus de l'utilisateur courant sont visibles. netstat -an montre les sockets et leurs états.

lsof -i -n -P -sTCP:LISTENnetstat -an -p tcp

• Contexte : Terminal macOS.
• Droits : utilisateur (sudo pour les ports d'autres comptes).
• Effet : lecture seule.
• Vérification : seuls les services attendus écoutent.
• Retour arrière : sans objet.

Étape 6 : la couche application avec curl. -I ne demande que les en-têtes, -v détaille la connexion, --connect-timeout et --max-time bornent la durée, -w affiche des temps (time_namelookup, time_connect, time_appconnect) qui séparent DNS, connexion TCP et poignée de main TLS ; --resolve force une adresse sans changer le DNS du poste.

curl -sI --max-time 10 https://example.com/curl -s -o /dev/null --max-time 10 -w "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect}\n" https://example.com/

• Contexte : Terminal macOS ; example.com est un nom de documentation.
• Droits : utilisateur.
• Effet : une requête HTTPS ; le contenu est jeté (-o /dev/null).
• Vérification : trois temps croissants (DNS, TCP, TLS).
• Retour arrière : sans objet.

La page lue décrit curl 8.23.0 ; la version installée sur le Mac est non vérifiée. -o /dev/null jette le contenu : aucun fichier créé.

10. iSCSI et réseaux de stockage : renvoi

Le trafic de stockage (iSCSI notamment) emploie TCP/IP mais pose des exigences propres (réseaux dédiés, chemins multiples). Ce cours ne l'aborde pas : voir le thème Stockage bloc NetApp (chemin SAN, initiateurs, chemins multiples) et le thème VMware ESXi.

Exercices et vérifications de fin de cours

Tous sont sur papier ou en lecture seule, sur le poste de Stéphane.

1. CIDR. Découper 203.0.113.0/24 en quatre sous-réseaux égaux ; donner préfixe, première et dernière adresse de chacun.
2. Couches. Pour « la page de example.com ne s'ouvre pas », écrire une hypothèse par couche et la commande qui la teste.
3. Lecture. Lancer networksetup -getinfo et netstat -rn sur son Mac, repérer adresse, masque, routeur, route par défaut (sans les noter dans le dépôt : adresses réelles).
4. DNS. Comparer dig example.com A +short et dig example.com MX ; expliquer la différence de type.
5. Temps. Avec curl -w, relever DNS, TCP et TLS ; dire lequel domine.
6. DHCP. Écrire les quatre messages dans l'ordre et dire lesquels sont diffusés.
7. Limites. Citer deux raisons pour lesquelles un ping sans réponse ne prouve pas la panne.

Critères de réussite

• Placer protocole et commande dans la bonne couche.
• Calculer un sous-réseau sans aide.
• Ne lancer que des commandes de lecture, et ne viser que ses équipements.
• Dire ce qui n'a pas été vérifié (OSI, 802.1Q, versions macOS).