Education numérique
Comprendre un réseau informatique
Comme tu aurais voulu qu’on te l’explique… (j’espère)
Que sais-tu déjà?
Tu sais ce qu’est un réseau informatique?
On t’as bassiné avec les couches OSI proposé par l’organisation ISO?
C’est bien…
Ne pas oublier d’ajouter la “couche 8” qui est l’utilisateur.
On t’a (peut-être) expliqué que la multitude historique de protocoles réseaux: DECNET, IBM SNA, X25 (Transpac), Novell IPX, Microsoft Netbeui, … , ont fini par céder la place au seul et unique Internet, avec le protocole IP… (fin du dernier siècle)
Sauf que non, il existe toujours multiples réseaux et protocoles, hors IP. (USB en est un aussi, mais il y a plein d’autres “standards” industriels qui existent, même si le “tout sur IP” s’est largement répandu).
Et pas de bol, TCP/IP colle assez mal avec le modèle théorique OSI:
L’ISO a voulu normaliser, mais la réalité du terrain s’en fiche, et c’est TCP/IP qui c’est imposé au monde, et l’OSI a dû s’y adapter…
Mais cela permet de construire une représentation avec un modèle théorique. Il y a eu pourtant un vrai protocol OSI: DSA de Bull, mais qui n’a pas “pris”.
On t’a aussi expliqué les xAN?
LAN, WLAN, MAN, WAN?
LAN = Local Area Network, WLAN=Wifi, M=Métropolitan (ville), W=Wide (large). PAN = Personel (USB, Bluetooth).
Mais peut-on faire un WAN avec un réseau de “niveau” 2, comme avec de l'Ethernet (ne pas confondre avec l’Internet), même en utilisant un support fibre optique (couche 1), sans devoir faire appel à un protocole de niveau 3?
La réponse est non!
Sais-tu comment cela fonctionne?
Pourrais tu me dire si ce schéma de réseau informatique, utilisé par Wikipédia, représente-t-il les couches 1, 2 ou 3, ou 4? Et question bonus: Il y a combien de réseaux sur ce schéma?
Pour documenter correctement un réseau informatique, ou lire une documentation, il faut comprendre comment cela fonctionne. Au moins les bases.
Je vais t’expliquer en 2 parties: Une petite révision des 4 premières couches de ce modèle OSI, et puis une histoire de paquets, à suivre leurs aventures.
Partie 1 — Les couches OSI de l’ISO
La couche 1, physique
Le plus facile, c’est la partie (im)matérielle du réseau: De la fibre optique, un câble cuivre torsadé avec des prises RJ45 aux extrémités, ou des ondes électromagnétiques dans une bande passante et une puissance bien déterminée. C’est une interface matérielle ajoutée ou incluse dans l’équipement informatique qui va te permettre de t’y raccorder:
- Une carte réseau (interface): RJ45 GB (gigabit) Ethernet le plus souvent,
- ou Wifi, ajoutée sur un PC fixe, ou incluse dans un laptop, un smarpthone, ou une tablette…
- ou carte réseau fibre optique (FX/SC)…
Mais elle sera nécessairement associée à un standard établi de la couche 2: Cela pourrait être du “Bluetooth” par exemple, ou bien un Wifi Ethernet.
Les topologies réseaux sont associées à cette couche physique
selon les types de réseaux utilisés:
bus 10B2 coaxial, 10B5... cercle: Token ring
étoile: 10BT, 100BT, 1000BT, 1000BX (fibre).
De nos jours l'étoile s'est imposée, mais des bus persistent:
USB, HDMI, utilisent des topologies "bus". Mais ce ne sont pas des "LAN".La couche 2, Liaison (data link)
Elle va présenter les données sur le support physique, le plus souvent on rencontre Ethernet (IEEE 802.3), y compris sur de la fibre ou du Wifi. Mais il y en a eu d’autres comme Tokenring (IEEE 802.5), et il y a encore ISDN(RNIS), X25, MPLS, FDDI…
C’est elle qui fabrique le paquet de données qui va circuler sur le réseau. Mais du coup, elle va t’attribuer une adresse physique unique, appelée MAC.
Il y a en fait plusieurs formes possibles de trames Ethernet (Ethernet II, Novell 802.3 et IEEE 802.3 avec SNAP qui s’impose désormais).
- Le préambule sert à “synchroniser” la lecture du paquet.
- Type va comprendre l’EtherType qui permet de faire cohabiter plusieurs protocoles sur le même réseau Ethernet. Une table IEEE définie les standards établies: 2 octets, 0x6003 pour DECNET (0x devant pour hexadécimal), 0x809b Appletalk, 0x8138 Novell, etc…
Pour IPv4, c’est 0x8000 et IPv6 c’est 0x86DD.
- le CRC est un “checksum” qui permet de vérifier l’intégrité du paquet.
C’est une version simplifiée, voici plus de détails
Domaine de broadcast vs collision
Tu peux aussi cascader des switchs, mais fais en sorte de ne jamais dépasser 3 répéteurs entre 2 équipements: Cela veut dire un seul niveau de cascades, avec un répéteur central et des répéteurs périphériques sur ce central. Contrairement à des idées reçues, et lues sur le Net, les commutateurs ne refabriquent pas les paquets émis sur chaque port, mais vont répéter le même paquet, ou pas, selon si la MAC destinataire est présente dans la liste associée à chaque port. Des commutateurs évolués pourront aussi gérer intelligemment des multicasts sans les répéter “partout”. Toutefois les broadcasts sont répétés sur tous les ports, et c’est la raison pour laquelle si tu chaînes 20 Switchs, ou 200, pour connecter 2 machines (à 1km, ou 10), cela va fonctionner (et heureusement, c’est ce qui est fait pour les fibres optiques sous-marines intercontinentales, mais 2 uniques équipements aux extrémités). Mais si c’est avec 200 ordinateurs, cela ne se passera pas bien… Ceux qui racontent qu’il n’y a pas de limite pour cascader des Switchs sur les forums sont des ânes, même si tu peux faire 2 niveaux, ou plus, et que cela fonctionne. Cela va dépendre de plein de facteurs avant de pécloter.
Le LAN est à la base, un domaine de Broadcast, c’est à dire le réseau de tous les équipements qui vont partager la réception des paquets de type broadcast: A savoir, un paquet émis à l’attention de tous les équipements raccordés avec l’adresse destinataire réservée: FF-FF-FF-FF-FF-FF.
Par extension et déformation: On parle aussi de LAN pour désigner un réseau localisé sur un même site/campus, composé de plusieurs vLAN interconnectés pour des routeurs “internes”.
Les Switchs présentent la particularité de séparer les réseaux en “domaines de collisions”, pour chaque prise (full-duplex). Contrairement à une antenne Wifi qui est un répéteur half-duplex dont les “clients” sont obligés de partager la même bande passante, ce qui était aussi le cas avec les Hubs. Mais à moins de créer des “VLAN”, tous les ports (les prises rj45) du Switch partagent un même domaine de Broadcast (ou de diffusion en français).
Si un serveur est connecté sur une prise en gigabit, et 10 pcs en 100 megabits, cela ne fera pas de surcharges, mais au-delà, Ethernet va gérer les “collisions” en répétant le message, et cela va rapidement ralentir les performances du réseau.
L’adresse MAC, niveau 2, réseau type Ethernet
Tu peux retrouver ton adresse MAC en tapant “ipconfig /all” sur Windows, et elle doit être sur un sticker sur les relais réseaux et imprimantes LAN.
ipconfig /all
Carte Ethernet Ethernet 2 :
Suffixe DNS propre à la connexion. . . : home
Description. . . . . . . . . . . . . . : Surface Ethernet Adapter
Adresse physique . . . . . . . . . . . : 1C-3B-DF-C2-54-2B
Et tu peux aller voir qui est le constructeur d’une adresse ici par ex.: MAC Address Vendor Lookup | MAC Address Lookup (maclookup.app), car les 3 premiers octets sont assignés par IEEE à chaque industriel qui fabriquent des interfaces Ethernet (Wifi incluses). On peut déterminer l’âge approximatif. Il peut ensuite produire 16'777'216 interfaces ethernet avec les 3 derniers octets (sachant qu’un switch 24 ports, va en consommer 24). Selon le constructeur, c’est toutefois possible que cela lui suffise pour un grand nombre d’années. Ensuite, il redemande un autre paquet à IEEE. Il est possible de commander des “demi-blocs” de 12 bits au lieu de 24, soit 4'096 unités d’adresses MAC.
Le réseau de base, va raccorder les équipements “locaux” ensemble à travers un répéteur réseau, LAN ou wifi. C’est le Switch réseau, anciennement HUB, parfois appelé routeur au domicile (car il va intégrer des fonctions des couches supplémentaires. Mais il intègre bien un Switch avec 4 prises le plus souvent). Tu peux raccorder 2 équipements directement et faire un réseau de 2 machines, sans répéteur (historiquement il fallait un câble croisé, mais ce n’est plus nécessaire, l’interface adapte automatiquement).
Si ton ordinateur ou ton smartphone doit envoyer un paquet à une autre machine, si elle utilise Ethernet (et non Bluetooth par exemple), alors il lui faudra son adresse MAC. Si elle ne la connaît pas, elle doit impérativement la réclamer et avec un réseau IP (couche 3), c’est le protocole ARP qui va le faire. Tu peux voir les MAC connues par ton Windows avec leur IP associée, via la commande:
arp -a
C:\>arp -a
Interface : 192.168.1.125 --- 0x10
Adresse Internet Adresse physique Type
192.168.1.1 b0-ea-bc-a7-30-70 dynamique
192.168.1.105 b0-2a-43-93-e3-60 dynamique
192.168.1.255 ff-ff-ff-ff-ff-ff statique
224.0.0.22 01-00-5e-00-00-16 statiqueDe la redondance au niveau 2: C’est possible avec STP, et même RSTP pour aller plus vite: Spanning Tree Protocol (802.1q). Ex. 3 Switchs en boucle. (vidéo en annexe).
De la qualité de service au niveau 2: C’est possible et même nécessaire car cela ne serait pas très utile de le faire au niveau 3, sans “tagger” les paquets “urgents” au niveau 2. C’est associé aux VLAN. Utile pour des ip-phones!
Le protocole ARP bien que situé dans les couches OSI entre la couche 2 et 3, sera associé à la couche 3, car il est spécifique à IP.
La couche 3, réseau
Cette couche et les suivantes seront interdépendantes, et souvent on va désigner un réseau avec les abréviations des couches 3 et 4:
- TCP/IP est devenu le standard car il est utilisé par l’Internet. La couche 3 est IP = Internet protocol. TCP est une des couches 4 de l’Internet.
Alors que c’est IEEE qui gère le standard Ethernet et attribue des adresses MAC, c’est IANA qui gère et régule les attributions d’IP. Vraiment 2 couches séparées!
- SPX/IPX est le protocole Novell, créé en 1983, mais abandonné depuis 2010, après avoir dominé le monde des LAN dans les années 90…
- Microsoft avait utilisé Netbeui (que je surnomme Netbeurk, car assez moisi comme protocole, même pas routable, et des relais WINS étaient nécessaires). Les requêtes Netbios (couche 5: fileshare, printshare), pouvaient toutefois utiliser aussi SPX/IPX avec NBX ou TCP/IP avec NBT, et devenir routable. Avec SMB/NBT on conserve la syntaxe \\SERVER\FILESHARE, mais Netbios est en cours d’abandon...
IP est devenu le standard réseau de niveau 3 planétaire
Le paquet IP, est inclus dans la partie “Data” du paquet Ethernet. Pour assurer une communication entre deux équipements, comme pour Ethernet, il faudra connaître l’adresse IP de la machine de destination, et fournir l’adresse IP de l’émetteur, pour recevoir la réponse.
Tu trouve ton adresse IP avec la commande Windows: ipconfig
ipconfig
Carte Ethernet Ethernet 2 :
Suffixe DNS propre à la connexion. . . : home
Adresse IPv6. . . . . . . . . . . . . .: 2a02:1210:76ad:de00:d101:c9a3:ecdd:e94f
Adresse IPv6 temporaire . . . . . . . .: 2a02:1210:76ad:de00:1858:764d:f9ee:6451
Adresse IPv6 de liaison locale. . . . .: fe80::75b4:8a5b:d77f:aa72%16
Adresse IPv4. . . . . . . . . . . . . .: 192.168.1.125
Masque de sous-réseau. . . . . . . . . : 255.255.255.0
Passerelle par défaut. . . . . . . . . : fe80::b2ea:bcff:fea7:3070%16
192.168.1.1Les 2 octets du type dans l’en-tête (Ethertype) de la trame Ethernet seront: 0800 pour IPv4 et 86DD pour IPv6 (valeurs en hexadécimal).
Le contenu de la partie data, comprendra une en-tête IP avec entre autres données, l’adresse IP de destination, et l’IP source. C’est encapsulé!
Quand IP va envoyer une requête à tous les postes du même subnet IP (Sous-réseau), alors un Broadcast IP est émis à ce “sous-réseau” IP déterminé (couche 3), exemple subnet 192.168.1.0/24 dans le graphique ci-dessus (IP de broadcast 192.168.1.255). La couche 2 doit alors nécessairement envoyer un paquet général à toutes les machines du domaine de Broadcast (avec tous les bit à 1, donc les 6 octets à FF). Toutes les machines présentes lisent et traitent le paquet reçu au niveau 2, mais à la couche 3, seules les machines du subnet concerné vont conserver et traiter le paquet au niveau 4. Les autres machines vont l’ignorer. Le même domaine de broadcast Erthernet, pourrait héberger multiples subnets IP, qui ne pourraient communiquer entre eux qu’en ajoutant un service de routage, dont l’interface possèdera multiples adresses IP (pour chaque subnet), généralement configurées sur la même carte Ethernet (inutile d’en avoir plusieurs).
Avec 6 octets, le nombre total d’interfaces Ethernet peut monter à 281 billions (12 zéros, pas 9 comme avec les anglo-saxons), mais en IPv4, avec 4 octets, bien moins de 4 milliards (à cause d’adresses réservées)… Or le nombre de trucs connectés sur Internet dépasse de loin les 4 milliards désormais. Tout n’est pas encore passé encore sur IPv6 (capacité 34 suivi de 37 zéros…). Pourtant le Net fonctionne encore principalement en IPv4, grâce à la magie du NAT et des adresses IPv4 privées:
Car une seule adresse IP publique, sur le routeur, est alors partagée par toutes les machines du LAN qui réutilise les mêmes IP privées que tout le monde.
En fait, IPv6 est un autre protocole, comme si cela était un autre language réseau. Mais il va faire fonctionner les services de l’Internet des couches supérieures (4 et 7) de façon transparente. Mais dessous, au niveau 3, nous avons 2 réseaux: IPv4 et IPv6, et ils sont juxtaposés. Pour les faire communiquer, c’est galère… Mais c’est une autre histoire.
On verra dans la seconde partie comment transitent les paquets IP.
Story: Savoir ne pas mélanger les couches 2 et 3, cela peut être utile. Cette séparation entre Ethernet (2) et l’Internet (IP couche 3) est importante, et le comprendre peut apporter des éclairages sur des “vieux systèmes” qui supportent mal les évolutions techniques. Exemple ci-dessous:
Comment obtenir une adresse IP pour son appareil, sans avoir à le configurer à la main? Cela c’est le travail du protocole DHCP, et de son serveur d’adresse, qui va arbitrer les affectations depuis un “pool ip” (étendues). C’est un protocole entre la couche 2 et 3, mais rattaché à la couche 3 pour la partie cliente de DHCP, comme ARP. La partie serveur de DHCP est dans la couche 7 applicative, c’est un service réseau, avec sa base de données pour gérer MAC et subnets.
Quand tu saisies une adresse email, tu mets @domaine.ch derrière l’identifiant de ton interlocuteur et non l’adresse IP de son serveur de messagerie, et quand tu vas sur un site web, tu vas taper www.domaine.ch et non une adresse IP. Pourtant, cette information n’est pas exploitable par IP… Donc il faut convertir ces “noms”, en adresse IP, avant de pouvoir envoyer les requêtes sur le réseau. C’est le travail de DNS, et je t’ai mis lien vers mon support en annexe, car c’est un sujet en soi. Et comme ce n’est pas bien “normalisé” et n’entre pas dans l’OSI, c’est un protocole de niveau 7, pour servir à la couche 3. Les applications doivent toutes “résoudre l’ip” (en demandant à DNS) pour convertir dès le début en une adresse IP, qui passera ensuite, à la couche 4, pour être passé à la couche 3 (on ne court-circuite pas!).
Rappel: Il n’y a pas (vraiment) de couches 5 et 6 pour l’Internet.
Comme pour Ethernet (niveau 2), qui peut faire cohabiter plusieurs protocoles niveau 3, avec un Ethertype qui assure l’étiquetage dans le paquet. L’en-tête IPv4 va inclure un champ “type” nommé ‘protocol’ pour mentionner quel type de paquets IP au niveau 4 sera présent dans les données:
Pour IPv6, l’en-tête devenue fixe, va mentionner un code “next header”, pour permettre d’ouvrir à l’infini le type de trames possibles.
Dans IPv4, la partie données va inclure le contenu selon le format et les “règles” établies par le protocole de couche 4, sur IP.
Petit info en plus, un champ TTL au niveau 3, IP, va donner le nombre maximum de Hop autorisés, afin d’éviter un bouclage infini infernal. A chaque hop, le TTL est changé avec -1 la valeur existante. A 0, le paquet IP est jeté…
La couche 4, transport
C’est lui qui traite et met en forme le paquet de données, qui sera le datagramme, en découpant pour en faire plusieurs si besoin était pour être “conforme” à l’envoi, et le réassembler à la réception. Alors que la couche 5 (ou 7 pour l’Internet), va envoyer un fichier complet, la couche 4 va le fragmenter et assurer la mise en forme pour l’envoi sur le réseau, et inversement à la réception.
Sur IP, il va y avoir deux principaux protocoles pour la couche Transport:
- TCP: Qui va assurer une totale intégrité des données transmises, mais à moindres performances, pour afficher une page web par exemple, on la préfère entière et le contenu dans l’ordre… Les datagrammes sont numérotés et ordonnés, et redemandés si le récepteur détecte un manque. La couche 4 TCP de l’émetteur va renvoyer les datagrammes manquants pour compléter les données.
- UDP: Qui va assurer plus de performances, mais au risque de perdre des paquets. (Quand tu téléphones, cela passe sur UDP, si on perds un paquet, cela fait un micro-blanc peu détectable, si on n’en perd pas trop). Les datagrammes perdus ou mal ordonnés, ne sont ni redemandés, ni réordonnés: Cela peut donner des “lags” ou “clippings” dans un jeux en ligne, ou des “blancs” dans une conversation téléphonique…
Mais ce n’est pas exhaustif, regarde donc la liste en lien précédemment.
Comme pour les bateaux ou avions, effectivement, un port va désigner un numéro de quai de débarquement/embarquement.
Comme pour le codage du “protocole” (UDP, TCP) à la couche 3, la couche 4 va coder des numéros de ports, prédéfinis, pour préciser le type de données que la couche 4 va transporter: Email (25 SMTP pour envoyer, 143 IMAP pour recevoir), page web (80 pour http, et 443 pour https), pour DHCP ce sera les port UDP 67 et 68, et il y a du monde:
La couche 5, session
Pour l’Internet, il n’y en a pas (c’est 7 directement). Mais cela n’empêche pas de tenter de découper des protocoles de niveau 7 en plusieurs parties et de les interpréter dans OSI, comme cela a été fait pour HTTP dans la première figure. Mais d’autres réseaux que TCP/IP fonctionnent plus “proprement”, avec une vraie couche “session”: Appletalk, RCP, …
Pour Netbios, son successeur SMB (couche 6) va désormais s’appuyer sur NBT (couche 5), qui est le vrai nom de ce qui va s’appeler improprement “Netbios sur TCP/IP”, car on arrête Netbios en fait. Comme quoi Microsoft, auteur de “Netbeurk” (NBF, NetBEUI), a fini par s’améliorer et faire plus “OSI”, mais en patouillant dans les désignations et très peu de clarté dans le bazar…
Les couches 6 et 7, Présentation et Application
Je ne vais pas les détailler.
Au niveau 6, tu y retrouves beaucoup de standards d’échanges et de présentation, exemple HTML (le language pour lire des sites webs), mais aussi XML et JSON, des standards de présentation de données structurées, pour faciliter leurs échanges. On y trouve SMB mentionné avant.
Au niveau 7, ce sont les applications, qui sont normalisées avec un “port” spécifique et enregistré, afin de ne pas avoir à “configurer” cela manuellement sur chaque client, vu à la couche 4. Ainsi les services Web (sites web) sont associé au port 80 pour http (non chiffré), et port 443 pour https (html chiffré). L’envoi d’un email utilise le protocole SMTP (niveau 7) sur le port 25 (ou 465 sécurisé). Mais on peut expliciter et changer ce “port” applicatif souhaité en ajoutant son numéro derrière l’IP (ou le nom), ex. http://monsiteweb.domaine.ch:8080
Plus d’infos sur les ports logiciels, cf. https://www.malekal.com/liste-des-ports-ports-reseaux-de-connexion-et-ce-que-cest/
On y retrouve aussi des applications propriétaires, qui peuvent utiliser des couches 6 et 5: Comme le partage de fichiers et imprimantes Microsoft, qui va s’appuyer sur SMB en couche 6, et NBT en couche 5, pour traverser l’Internet si besoin était, ou juste rester sur son LAN…
Alors maintenant que tu as “tes couches”
apprenons à marcher!
DHCP est dans la couche 7 (application qui regroupe 5+6+7 en fait), mais la partie cliente de DHCP est dans la couche 3 (internet). Transport=4, Réseau=2.
Partie 2 — Histoire de paquets
Pour comprendre un réseau, je te propose de suivre l’histoire de ta machine, que tu vas allumer, pour te connecter sur YouTube par exemple, qui n’est juste qu’un site web parmi les autres...
Allumage de la machine
Un smartphone, une tablette, un PC, un Mac, un Linux, c’est pareil. Tu le mets en route. Il va avoir besoin de se connecter à l’Internet, et le faire dès le démarrage. Que ce soit en mode Wifi ou via un câble, nous appellerons “répéteur” le point de raccordement de ta machine et “routeur” l’appareil qui te raccorde à ton accès Internet, même si c’est dans le même boitier. C’est effectivement deux parties différentes, y compris dans ton boitier.
Ta machine va émettre un premier paquet Ethernet (couche 2) au démarrage, qui va réclamer en ‘broadcast’ une adresse IP (à moins que tu l’ais désactivé et que l’IP soit fixée, ce qui est devenu rare, alors que c’était normal “à mon époque”). C’est un DHCP request.
Le serveur DHCP va lui en donner une. A la maison, le serveur DHCP est dans ton boitier routeur d’accès Internet. Si tu es dans une entreprise ou une école, le serveur DHCP n’est pas sur le même réseau que toi (hors de ton domaine de broadcast), mais tes équipements routeurs sont configurés pour relayer ta demande spécifique (IP helper), sur son port spécifique, vers un serveur DHCP d’un autre subnet. Et donc la réponse sera aussi relayé, sans que tu disposes encore d’une adresse IP. DCHP est (souvent) mis (uniquement) dans les couches applicatives, 4 ou 7, mais la partie “cliente” est bien en fait une requête intermédiaire entre la couche 2 et 3.
En vrai, le Bios de ta machine va en demander une première fois, c’est le PXE boot, sauf si désactivé, et ensuite, au chargement de ton OS, il y aura une seconde demande qui fournira la même IP, car ce sera la même MAC qui le demande, avec toutefois un “Vendor ID” différent (option 60).
Le serveur DHCP ne se contente pas de te donner une adresse IP, il te donne aussi l’adresse de ton routeur, pour te permettre de communiquer avec les autres réseaux, et aller sur l’Internet.
La commande pour voir les détails de tes interfaces Ethernet (et Internet), sur Windows déjà vue précédemment, est “ipconfig /all”, tu y trouves:
- DHCP activé (ou pas), avec une option (préféré) ou pas, à savoir que le serveur DHCP a accepté de te redonner l’adresse que tu avais reçu la fois d’avant, et que tu lui avais signalé. Ton masque de sous-réseau (subnet).
- L’IP du serveur DHCP qui t’a donné ton “bail”, quand (obtenu), et pour quelle durée (expirant).
Le serveur DHCP peut aussi fournir une adresse IPv6. DHCPv6 est la version du protocole DHCP pour IPv6. Il peut fournir des adresses IPv6 temporaires et locales. Les adresses IPv6 temporaires sont utilisées pour préserver la confidentialité de l’adresse IPv6 publique de l’équipement. Elles sont générées automatiquement et sont valables pendant une durée limitée. Les adresses IPv6 locales sont utilisées pour les communications entre équipements connectés au même réseau local. Elles sont générées automatiquement et ne sont pas routables sur Internet
C:\Users\pasca>ipconfig /all
Configuration IP de Windows
Nom de l’hôte . . . . . . . . . . : Acer-pako
Suffixe DNS principal . . . . . . :
Type de noeud. . . . . . . . . . : Hybride
Routage IP activé . . . . . . . . : Non
Proxy WINS activé . . . . . . . . : Non
Liste de recherche du suffixe DNS.: home
Carte Ethernet Ethernet 2 :
Suffixe DNS propre à la connexion. . . : home
Description. . . . . . . . . . . . . . : Surface Ethernet Adapter
Adresse physique . . . . . . . . . . . : 4C-3B-DF-C2-54-2B
DHCP activé. . . . . . . . . . . . . . : Oui
Configuration automatique activée. . . : Oui
Adresse IPv6. . . . . . . . . . . . . .: 2a02:1210:76ad:de00:d101:c9a3:ecdd:e94f(préféré)
Adresse IPv6 temporaire . . . . . . . .: 2a02:1210:76ad:de00:4cdc:97b2:95da:c1b4(préféré)
Adresse IPv6 de liaison locale. . . . .: fe80::75b4:8a5b:d77f:aa72%16(préféré)
Adresse IPv4. . . . . . . . . . . . . .: 192.168.1.125(préféré)
Masque de sous-réseau. . . . . . . . . : 255.255.255.0
Bail obtenu. . . . . . . . . . . . . . : samedi, 26 août 2023 19:51:19
Bail expirant. . . . . . . . . . . . . : vendredi, 1 septembre 2023 07:27:53
Passerelle par défaut. . . . . . . . . : fe80::b2ea:bcff:fea7:3070%16
192.168.1.1
Serveur DHCP . . . . . . . . . . . . . : 192.168.1.1
IAID DHCPv6 . . . . . . . . . . . : 189545439
DUID de client DHCPv6. . . . . . . . : 00-01-00-01-2C-11-8F-86-4C-3B-DF-C2-54-2B
Serveurs DNS. . . . . . . . . . . . . : 2a02:1210:76ad:de00:b2ea:bcff:fea7:3070
192.168.1.1
NetBIOS sur Tcpip. . . . . . . . . . . : Activé
Liste de recherche de suffixes DNS propres à la connexion :
homeSi un serveur DHCP ne répond pas, c’est APIPA l’adresse automatique qui va prendre le relais, si cela n’a pas été désactivé. Si ton IP est 169.254.x.x, alors c’est que ton service DHCP est mort, ou alors, que ta route vers le serveur DHCP a été coupée. Si tu viens d’installer le vLAN, c’est que le relais DHCP n’a pas été correctement configuré. Car on va pas mettre un serveur DHCP dans chaque vLAN, tu n’as qu’un serveur DHCP, pour tous tes vLAN, mais ton routeur configure un relais de chaque vLAN (subnet), vers ce serveur.
Ouverture d’une page Web
Tu lances ensuite ton navigateur, et tapes ou cliques sur un bouton “raccourci” YouTube.com…
Ta machine va avoir besoin de convertir l’URL YouTube.com en une adresse IP, et elle va faire une requête DNS, que tu peux aussi faire manuellement, avec la commande: nslookup YouTube.com
C:\>nslookup YouTube.com
Serveur : internetbox.home
Address: 2a02:1210:76ad:de00:b2ea:bcff:fea7:3070
Réponse ne faisant pas autorité :
Nom : YouTube.com
Addresses: 2a00:1450:400a:801::200e
142.250.203.110A noter que tu as une adresse (2 avec l’IPv6), mais depuis une autre machine, tu pourras obtenir une autre adresse… (Tu ne crois quand même pas que YouTube tourne sur une seule machine? Même avec un très gros serveur, cela ne suffirait pas). La réponse ne fait pas autorité, car cela a été relayé par un DNS qui conserve une copie de la réponse, mais qui n’est pas le DNS de Youtube.com… Cf. http://dns.quicklearn.ch pour en savoir plus sur DNS.
Tu vois 2 adresses, une IPv6 et une IPv4… Cela veut dire que ton FAI (Fournisseur d’Accès Internet) semble compatible IPv6. Tu peux checker ici si tu dispose d’une IPv6 publique, ou pas… https://ipcost.com/fr
Il existe de nombreux site pour checker ton ip publique, sauf que rare sont ceux qui vont le faire pro et complet, sans se limiter à ton ipv4 publique: comme mon-ip.com
Ou uniquement ton IPv6, comme https://www.myip.com/
L’IPv4 qui est affichée n’est pas celle de mon ordinateur, l’IPv6 oui, mais mentionnée “Temporaire”… Tu peux regarder via la commande ipconfig.
C:\>ipconfig
Configuration IP de Windows
Carte Ethernet Ethernet 2 :
Suffixe DNS propre à la connexion. . . : home
Adresse IPv6. . . . . . . . . . . . . .: 2a02:1210:76ad:de00:d101:c9a3:ecdd:e94f
Adresse IPv6 temporaire . . . . . . . .: 2a02:1210:76ad:de00:e5a4:5105:4cba:2f37
Adresse IPv6 de liaison locale. . . . .: fe80::75b4:8a5b:d77f:aa72%16
Adresse IPv4. . . . . . . . . . . . . .: 192.168.1.125
Masque de sous-réseau. . . . . . . . . : 255.255.255.0
Passerelle par défaut. . . . . . . . . : fe80::b2ea:bcff:fea7:3070%16
192.168.1.1Si tu as noté ce que j’ai expliqué plus haut: Les IPv4 sont devenues rares et ton FAI va te faire utiliser une seule IP publique partagée avec plein d’autres abonnés clients… Grâce à la magie du NAT et des adresses IPv4 privées:
Une seule adresse IPv4 publique, peux être partagée par un très grand nombre de machines… Du coup, quand https://ipcost.com/fr m’annonce que mon IP est “exposée”, et bien c’est à nouveau pour te faire acheter un truc (probablement) inutile, un VPN. Car en réalité, c’est faux.
Par contre, mon IPv6 n’est pas “translatée” et elle est exposée directement? Et bien pas plus, car d’abord c’est une ip temporaire qui va changer, et en plus, si tu essayes de te connecter dessus depuis l’Internet, avec un ping ou autres choses, cela ne va pas répondre. Tu peux sortir, mais tu ne peux pas entrer sans faire une configuration du routeur pour l’autoriser. C’est pour cela que les hackers, ils veulent te faire cliquer sur un truc où tu vas sortir pour te faire choper. Ben il fallait pas cliquer, si tu sais pas…
Pour en revenir à ton navigateur qui maintenant dispose d’une IP pour sa requête, il va envoyer une requête http “GET URL http://YouTube.com” vers l’IP que DNS lui a donné: 142.250.203.110, dans un datagramme tout petit (mais pas exactement sous cette forme) pour obtenir la “home” page de YouTube.com…
L’URL de la page demandée est intégrée dans la partie data du paquet. C’est important car un seul serveur web, ou un cluster de services serveurs web, peuvent partager la même IP publique, et donc, c’est l’URL dans la data qui permet d’aller chercher la bonne page à répondre avec le bon site web.
Le datagramme est envoyé à la couche 4 TCP pour une mise en forme. Pas besoin de découper, moins de 1460 octets, elle fait un seul paquet TCP avec la requête, qui inclus l’IP de destination, 142.250.203.110 (on va prendre l’option plus complexe, avec IPv4 translaté, au lieu de l’option IPv6).
La couche 3 IP va ajouter l’en-tête avec l’IP de destination, mais va déterminer quel sera le prochain routeur à utiliser pour prendre le bon chemin, et le passera à la couche 2. Elle va vérifier les “routes IP” pour déterminer quel sera le prochain routeur, que tu peux customiser et modifier avec la commande “Route” (Route -help pour voir la syntaxe et les paramètres). La plupart du temps, tu es sur un réseau privé avec un seul routeur (default gateway) pour en sortir, alors le choix est vite fait. Mais tu as aussi une IP de “bouclage” (loopback) et donc tu en auras au moins 2, des routeurs possibles, et les routes peuvent adresser des réseaux IP, ou des machines.
>route print
===========================================================================
Liste d'Interfaces
16...4c 3b df c2 54 2b ......Surface Ethernet Adapter
13...58 1c f8 92 71 c5 ......Microsoft Wi-Fi Direct Virtual Adapter #3
15...5a 1c f8 92 71 c4 ......Microsoft Wi-Fi Direct Virtual Adapter #4
10...58 1c f8 92 71 c4 ......Intel(R) Wi-Fi 6E AX211 160MHz
1...........................Software Loopback Interface 1
===========================================================================
IPv4 Table de routage
===========================================================================
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.125 25
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
192.168.1.0 255.255.255.0 On-link 192.168.1.125 281
192.168.1.125 255.255.255.255 On-link 192.168.1.125 281
192.168.1.255 255.255.255.255 On-link 192.168.1.125 281
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 192.168.1.125 281
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 192.168.1.125 281
===========================================================================
Itinéraires persistants :
Aucun
IPv6 Table de routage
===========================================================================
Itinéraires actifs :
If Metric Network Destination Gateway
16 41 ::/0 fe80::b2ea:bcff:fea7:3070
1 331 ::1/128 On-link
16 41 2a02:1210:76ad:de00::/64 On-link
16 281 2a02:1210:76ad:de00:c458:9667:ab2e:b76c/128
On-link
16 281 2a02:1210:76ad:de00:d101:c9a3:ecdd:e94f/128
On-link
16 281 fe80::/64 On-link
16 281 fe80::75b4:8a5b:d77f:aa72/128
On-link
1 331 ff00::/8 On-link
16 281 ff00::/8 On-link
===========================================================================
Itinéraires persistants :
AucunLa partie qui numérote les réseaux dans une IP est déterminée par la longueur du “masque de réseau” (ex. 0.0.255.255), ou au format CIDR (/16).
S’il n’y a pas de routeurs prédéfinis pour la destination demandée, c’est le routeur, “passerelle par défaut” (affiché ci-dessus par ipconfig) qui est utilisé. Il va donner les 3 IPs: source, destination, prochain hop (routeur)
Rappel: ces 2 adresses étant privées, elle ne peuvent pas circuler sur le Net…
Les 3 IPs sont “locales” à ton domaine de broadcast, et grâce à ARP, ta machine connait la MAC du routeur. Le paquet Ethernet est monté par la couche 2: MAC Source ton PC, MAC destination ton routeur, alors que l’IP destination en couche 3, reste ton but final, et ton IP source 192.168.1.125.
Le routeur reçoit un paquet qui lui est bien destiné alors il le traite: Comme c’est un routeur avec NAT (uniquement pour IPv4), il va d’abord remplacer les IP privées, par l’IP publique que le FAI lui a donné (et qui peut changer dans le temps), 62.202.189.146 à la place de 196.168.1.125, directement dans la couche 3 de la trame. Mais il va déterminer quel sera le prochain routeur à partir de l’IP destination, et va prendre l’adresse MAC du prochain routeur (car les serveurs Youtube ne sont que rarement directement situés sur le réseau de ton FAI, et il va falloir traverser plusieurs réseaux, c’est à dire, plusieurs routeurs). Ton routeur ne les connait pas tous, mais il trouvera le routeur suivant à utiliser. Tu peux reconstituer toute cette route avec la commande: tracert 142.250.203.110
C:\>tracert 142.250.203.110
Détermination de l’itinéraire vers zrh04s16-in-f14.1e100.net [142.250.203.110]
avec un maximum de 30 sauts :
1 2 ms 1 ms 1 ms internetbox.home [192.168.1.1]
2 4 ms 4 ms 4 ms 100.85.192.1
3 3 ms 3 ms 3 ms ae22-1150.ipc-lss690-m-pe-48.bluewin.ch [213.3.220.253]
4 3 ms 3 ms 3 ms etht22-1150.lssic20p-cgn001.bluewin.ch [213.3.220.254]
5 15 ms 14 ms 16 ms 213.3.220.169
6 18 ms 13 ms 16 ms i69lsp-015-ae11.bb.ip-plus.net [193.5.72.24]
7 * * * Délai d’attente de la demande dépassé.
8 94 ms 132 ms 151 ms 72.14.214.100
9 60 ms 62 ms 62 ms 216.239.43.179
10 82 ms 84 ms 81 ms 142.251.70.185
11 104 ms 104 ms 103 ms zrh04s16-in-f14.1e100.net [142.250.203.110]
Itinéraire déterminé.A noter que la route affichée est celle utilisée par ICMP (Ping), et donc, pas si sûr que ta requête http/TCP suive le même chemin, même si on regarde au “même moment”… C’est très probable toutefois.
Grâce à ARP, ton routeur connait la MAC du routeur suivant d’IP 100.85.192.1 (mais nous non, on n’est pas sur le même réseau). Sa couche 2 va reconstruire le paquet Ethernet avec cette MAC en destination, est sa propre MAC de l’interface externe (côté FAI).
Le processus va se répéter de proche en proche, jusqu’au serveur Youtube, ou plus exactement un service simulant un serveur, mais géré par multiple container applicatifs tournant sur des myriades de machines virtuelles. Et elle va très certainement traverser d’abord des machines de filtrages, redondances et gestion de charges, et d’analyses de sécurité, avant d’être répondu par un service web.
Ce service va répondre à la requête GET, par le contenu de la page demandée (URL), mais aussi selon le contexte d’identification de la requête (langue, géolocalisation, cookies, identification Google, navigateur, OS, IP publique…) pour déterminer le contenu qui sera proposé initialement, selon tes abonnements YouTube, y compris des pubs le plus personnalisées possible pour augmenter les chances que tu cliques sur l’une d’elle, pour gagner des milliards (sur la masse: pay per click). C’est une page “dynamique”, et non statique. Tout le monde n’aura pas la même. C’est la même chose sur une page Google.com, c’est dynamique aussi et personalisé.
La page de données en langage html est transmise à la couche 4 TCP du serveur web: Qui va découper en datagrammes (de 1460 octets en général) toute la page, numéroter 1 le premier, puis les autres et inclure le nombre total à venir. Il va ensuite les envoyer tous à la couche 3. IP va ajouter l’en-tête IP avec l’adresse IP publique de ton routeur, depuis l’adresse source reçue dans la trame, pour suivre un chemin de retour, pas nécessairement identique à l’aller, et qui peut même changer en cours de route, et peut-être faire transiter par des chemins différents tous les 1'000 paquets de réponses (la page pèse près de 1.5 Mo), qui peuvent arriver partiellement dans le désordre.
Ton routeur NAT reçoit les 1'000 paquets de réponses, mais tu n’es pas tout seul sur le réseau privé. Il doit alors “savoir” à qui il doit délivrer cette réponse. Comme il a gardé ton numéro de session dans ta requête, il sait à quelle adresse ip privée il doit transposer les paquets pour te les transmettre, tout autant en vrac qu’il les a reçu (NAT est de niveau 3, pas 4). Il va donc remplacer la couche 3 avec l’adresse IP destination par ton IP publique, et l’IP source par sa propre IP privée sur son interface interne, et même modifier le “port de session” dans la trame (car tu as le droit d’ouvrir plusieurs sessions, plusieurs pages web, et le routeur NAT doit les changer en cas de conflit avec un autre usager sur le même réseau que toi, qui aurait le numéro de session).
Ta machine reçoit les 1'000 paquets, sauf 1, perdu en route… Elle redemande à YouTube le paquet numéroté qui lui manque. Rebelotte pour un seul paquet, qui revient bien cette fois. La couche 4 TCP de ta machine va remettre tous les paquets dans le bon ordre et reconstituer le bloc de texte de 1.5 Mo en langage html que va pouvoir interpréter ton navigateur web.
Ton Browser va convertir le code html en texte et image sur ton écran pour les rendre lisibles, et affiche ta page web. Dès que tu vas cliquer un lien, un bouton, une entrée d’un menu déroulant, cela génère une nouvelle requête, pour recevoir une nouvelle page, selon le choix de ton clic…
TK qq graphiques à construire pour illustrer cela (à venir?)…
Envoi et réception d’un email
Si tu utilises un navigateur web (browser) pour ouvrir un webmail, comme Gmail, ou outlook.com en ligne, les échanges https seront les mêmes que pour YouTube ou toutes pages web. Si tu utilises un “client de messagerie”, comme l’application Outlook, Thunderbird ou Eudora, ou si tu configures depuis un smartphone, alors ce sera différent.
Tu as configuré ton client pour envoyer des messages via SMTP à l’adresse de ton fournisseur d’email, qui peut aussi être ton FAI, mais pas obligatoirement. Tu as aussi configuré ton client pour lire les messages reçus, normalement via IMAP, mais possiblement avec le vieux POP3.
SMTP, IMAP et POP3 sont de la couche “Application” mais qui amalgame les couches 5, 6 et 7 du modèle OSI. Mais on devrait les penser comme des couches 5 ou plutôt 6 (sauf que cela n’existe pas, pour TCP/IP).
Il est à noter que tu peux aussi utiliser un webmail, comme kmail, gmail ou outlook.com (ex hotmail.com), pour aller lire des boîtes email via IMAP ou POP3. Il devient alors ton client de messagerie, mais “dans le Cloud” et non sur ta machine. Le serveur webmail de ton fournisseur va lui se connecter sur ton serveur de boîtes emails, pour aller lire tes messages, avec les codes que tu lui as donné. Faudra lui faire confiance…
Tu as déjà ouvert ton “client email” (Eudora), et tu cliques sur nouveau message: Tu ajoutes un email destinataire, tu rédiges, et tu cliques Envoi.
A ton avis, la couche 4 qui sera utilisée pour la suite, ce sera UDP, ou TCP?
Le client de messagerie, va envoyer une requête DNS pour chaque email destinataire ou copie, et demander qui est le serveur à utiliser pour recevoir la requête SMTP (envoi email). Il va poser la question avec la partie “domaine” de l’adresse email (derrière le sigle @).
Tu peux simuler cette requête manuellement avec la commande, nslookup, puis “set type=MX”, puis <domain.tld> (où <domain.tld> est le truc derrière @).
C:\>nslookup
Serveur par dÚfaut : internetbox.home
Address: 2a02:1210:76ad:de00:b2ea:bcff:fea7:3070
> set type=MX
> gmail.com
Serveur : internetbox.home
Address: 2a02:1210:76ad:de00:b2ea:bcff:fea7:3070
Réponse ne faisant pas autorité :
gmail.com MX preference = 40, mail exchanger = alt4.gmail-smtp-in.l.google.com
gmail.com MX preference = 20, mail exchanger = alt2.gmail-smtp-in.l.google.com
gmail.com MX preference = 30, mail exchanger = alt3.gmail-smtp-in.l.google.com
gmail.com MX preference = 10, mail exchanger = alt1.gmail-smtp-in.l.google.com
gmail.com MX preference = 5, mail exchanger = gmail-smtp-in.l.google.com
gmail-smtp-in.l.google.com internet address = 142.250.145.26Une fois que le premier serveur distant STMP sera sélectionné, ta machine va composer un paquet TCP sur le port standard numéro 25, ou faire mieux avec une requête SMTP chiffrée sur SSL (SMTPS) au port 465. Car dans le passé, les emails, c’était “en clair” sur le Net. Ils ne doutaient de rien nos aïeux. L’IP destinataire sera ici 142.250.145.26. Dans la requête SMTP, pour chaque destinataire email, il va mettre l’alias demandé (le texte devant le symbole @) afin de vérifier la disponibilité, ou la validité. (Il y a en réalité plusieurs échanges pour faire cela, je simplifie…)
La couche 2 (Ethernet, liaison) va faire les mêmes hops de proche en proche en changeant les MAC, comme expliqué précédemment.
Le serveur STMP distant va répondre avec un code OK ou d’erreur avec un code standard qui précise le problème: alias inexistant (rejet), boite pleine, pas dispo, etc… Et à part si OK (passe dans le dossier emails envoyés) ou inexistant (là il crie de suite, sans retenter), il va normalement t’avertir plus ou moins rapidement, qu’un des destinataires n’est pas immédiatement disponible pour recevoir, mais qu’il va retenter (2 à 3 jours max).
Explications de Bing/ChatGPT: Les délais entre chaque tentative varient selon le client de messagerie utilisé. Par exemple, Gmail effectue une première tentative après 5 minutes, puis 15 minutes, puis 1 heure, puis 4 heures, puis 12 heures et enfin 24 heures. Outlook effectue une première tentative après 1 minute, puis toutes les 2 minutes pendant 20 minutes, puis toutes les 5 minutes pendant 4 heures et enfin toutes les 30 minutes pendant 24 heures.
Sur un retour OK, alors la couche 4 TCP va découper l’email avec son en-tête et ses blocs MIME (une sorte de couche 6, et SMTP une couche 5?) en datagrammes numérotés et ordonnés, pour les passer à la couche 3 IP, etc…
A noter que j’ai simplifié, car en réalité, ce n’est pas ton client email, qui va envoyer au serveur SMTP du destinataire, mais au relais SMTP de ton fournisseur, que tu as configuré. Et c’est ce relais SMTP qui va trouver le serveur distant, via des relais STMP intermédiaires le cas échéant. Ainsi, ce n’est pas ton client de messagerie qui va SMTP ton email aux destinataires, et c’est ce relais qui va ensuite te relayer le message d’erreur éventuel qu’il a reçu, ou parce que le serveur destinataire est “down” (éteint ou hors ligne) et qu’il n’a pas eu de réponse… Mais, on peut aussi installer un relais SMTP sur sa propre machine cliente, en plus du client email, alors on va dire que cela ira comme simplification… L’intérêt des relais, c’est d’assurer l’acheminement des emails même en cas de ruptures réseaux, soit plus tard, soit par d’autres chemins.
Le message arrive sur le client email en face comme toi tu reçois les tiens.
Ton client de messagerie, à intervalle de temps régulière que tu configures, va aller demander à ton serveur de messagerie, qui héberge ta boîte email, de lui délivrer les nouveaux emails depuis sa dernière demande.
- Soit avec le vieux protocole POP3, qui va déplacer les emails de ta boîte sur le serveur, vers ta boîte dans ton client de messagerie. Mais du coup, si tu perds ton PC, sans sauvegardes, tu perds tes emails. Mais aussi, si tu as 1 smartphone, 1 tablette, 1 pc, tous les 3 configurés POP3, et bien même en configurant le POP3 de laisser 1 semaine de répits avant de vider la boîte côté serveur, tu vas te retrouver avec certains emails qui ne seront que sur le smartphone, et d’autres que sur la tablette (si tu ouvres pas durant 10 jours), etc… Guère pratique. Alors on a conçu IMAP. C’est aussi lié à l’augmentation des capacités de stockage des matériels.
- Soit avec IMAP, il y aura synchronisation des emails, reçus, lus ou pas, envoyés, archivés (dans un dossier du serveur)… Et donc tes 3 clients emails, pc, téléphone, tablette, vont cette fois afficher la même chose. Mais si tu fais un “dossier” d’archives locales sur ton PC (et non sur le serveur), alors les autres équipements ne verront pas ce dossier.
Ton client va questionner le serveur que tu as mentionné dans la configuration, selon un des 3 ou 4 “standards” utilisables, et sur un des 2 ou 3 ports que tu peux configurer. Tu as donc largement de quoi perdre en jouant à la bataille navale, mieux vaut lire la documentation de ton fournisseur de ta boite email. Parfois, le mode automatique fonctionne!
Et des fois, tu peux envoyer, mais la réception ne fonctionne pas, ou inversement: Je peux aider à distance: http://callme.kotte.net
Pour la réception aussi, ton client d’email va devoir faire une requête DNS pour déterminer l’IP effective du moment pour le serveur IMAP de ton fournisseur. Ensuite couche 4 TCP, couche 3 IP, couche 2 Ethernet, autant de fois que de hop (routeurs à traverser).
J’espère que tout cela éclaire ta compréhension du fonctionnement des réseaux. Tu peux “liker” (et même “applause” 50 fois) et poser un commentaire.
Voir aussi
Même auteur
Autres auteurs
Pour regarder ces paquets par soi-même:
