Cours Linux / Comprendre les adresses IP, le DNS, les ports et la connexion HTTPS

Une adresse IP désigne une destination dans un réseau, le DNS permet de rechercher des informations associées à un nom, et un port distingue des points de communication sur un hôte avec un protocole de transport donné. Pour accéder à un site HTTPS, il faut notamment résoudre le nom, disposer d’un chemin vers l’adresse, joindre le service et réussir l’échange sécurisé. Une résolution DNS réussie ne prouve donc pas que la page sera accessible.

Cette leçon s’appuie sur une machine virtuelle Ubuntu 26.04 LTS ou Rocky Linux 9 avec accès au terminal. Les consultations montrées ne changent ni les adresses ni les routes ni le pare-feu ; la commande curl émet une requête vers un site distant. Le cours sur l’environnement de pratique en machine virtuelle explique comment distinguer la machine invitée de l’hôte et vérifier sa connexion réseau.

Distinguer le nom, l’adresse et le port dans une URL

Prenons https://example.com/. https désigne le schéma, example.com le nom de l’hôte et / le chemin demandé. En l’absence d’un port explicite, HTTPS utilise 443. La machine doit obtenir une adresse utilisable pour ce nom et choisir un chemin vers elle avant de joindre le service.

IP signifie Internet Protocol. DNS signifie Domain Name System, le système de noms de domaine. Un enregistrement DNS peut porter une adresse, mais aussi d’autres informations : le DNS ne se résume pas à une table « un nom = une machine ».

Les blocs 192.0.2.0/24 et 2001:db8::/32 sont réservés aux exemples par les règles des adresses IPv4 de documentation et les règles du préfixe IPv6 de documentation. Ne les recopiez pas comme destination de connexion réelle. À l’inverse, example.com possède un service de présentation fourni au mieux par l’IANA ; sa politique des domaines d’exemple ne garantit pas un service permanent pour des applications.

Comprendre IPv4, IPv6, les adresses privées et la boucle locale

IPv4 utilise des adresses de 32 bits, habituellement écrites en quatre nombres décimaux séparés par des points. IPv6 utilise 128 bits et une écriture hexadécimale séparée par des deux-points, où :: peut abréger une suite de groupes nuls. Une interface peut porter plusieurs adresses, et une machine peut utiliser les deux familles.

127.0.0.1 en IPv4 et ::1 en IPv6 sont des adresses de boucle locale : elles ramènent à la machine elle-même. Une application qui écoute seulement sur cette boucle n’accepte pas directement les connexions vers une adresse réseau de la machine depuis un autre ordinateur. Un relais ou un proxy explicite pourrait rendre un autre chemin possible ; l’écoute locale seule ne l’établit pas. L’architecture des adresses IPv6 définit notamment ::1.

Les plages IPv4 privées sont 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16. La RFC 1918 les réserve aux réseaux privés ; elles peuvent être réutilisées dans des réseaux distincts et ne sont pas des adresses publiques globalement uniques. Attention à la limite : tout 172.0.0.0/8 n’est pas privé.

Un réseau privé peut joindre des services Internet grâce à un mécanisme comme la traduction d’adresses, ou NAT pour Network Address Translation. Cela ne rend pas automatiquement un service interne accessible depuis Internet. IPv6 a ses propres adresses, routes et règles de filtrage ; ne supposez ni qu’il remplace simplement « IPv4 sans NAT », ni qu’une règle IPv4 protège aussi IPv6.

Lire un préfixe réseau et une route par défaut

Dans 192.168.10.20/24, /24 indique que les 24 premiers bits forment le préfixe réseau : ici 192.168.10.0/24, correspondant au masque 255.255.255.0. Cette écriture suit le principe CIDR, Classless Inter-Domain Routing, qui exprime une longueur de préfixe plutôt qu’une ancienne classe d’adresse.

Le système recherche une route correspondant à la destination ; dans une table donnée, un préfixe plus précis l’emporte généralement sur un préfixe moins précis. Une route par défaut est le recours lorsqu’aucune route plus spécifique appropriée n’est retenue. Les règles de routage avancées, les tables multiples et les réseaux virtuels ajoutent d’autres critères ; ne réduisez pas tous les environnements à une seule passerelle.

ip -brief address
ip route
ip -6 route

La première commande résume les interfaces, leur état et leurs adresses. Les deux suivantes consultent les routes IPv4 et IPv6 habituelles. Relevez le nom réel de l’interface de la machine virtuelle et les préfixes affichés ; ne supposez pas qu’il s’appelle eth0. Une interface affichée UP ne prouve pas à elle seule que le serveur distant est joignable.

Une ligne contenant default via indique une route par défaut avec un prochain saut, par exemple un routeur ; dev désigne l’interface concernée. Toutes les routes par défaut n’ont pas nécessairement une forme via, notamment sur certains liens. Le manuel ip route explique ces champs. La passerelle et le serveur DNS peuvent avoir la même adresse dans un réseau domestique, mais le premier achemine les paquets et le second répond aux recherches de noms.

ip appartient au projet iproute2. Sur Ubuntu, le paquet porte le nom iproute2 ; sur Rocky Linux 9, il s’appelle iproute. Vous pouvez consulter le paquet de votre seule distribution :

dpkg-query -W iproute2

Ou, sur Rocky Linux :

rpm -q iproute

Le manuel d’ip pour Ubuntu 26.04 et le dépôt officiel BaseOS de Rocky Linux 9 permettent de vérifier ces noms. Ces requêtes ne servent pas à installer un gestionnaire d’une autre distribution.

Observer la résolution d’un nom sans la confondre avec une connexion

Un enregistrement A associe un nom à une adresse IPv4 ; AAAA fait de même pour IPv6. MX concerne les serveurs de messagerie. Les définitions figurent notamment dans la spécification des enregistrements DNS et l’extension DNS pour IPv6. Un même nom peut avoir plusieurs réponses et des caches peuvent conserver des informations pendant leur durée de validité.

getent ahosts example.com

Sur ces distributions utilisant la bibliothèque GNU C, getent consulte les sources prévues par le mécanisme NSS, Name Service Switch, selon la configuration du système. Il peut employer /etc/hosts, DNS ou d’autres sources. Son résultat montre des adresses obtenues par ce parcours système, sans établir qu’une requête DNS a nécessairement été envoyée à cet instant.

Plusieurs lignes pour une adresse peuvent correspondre à différents types de sockets ; ne comptez pas mécaniquement chaque ligne comme un serveur distinct. Les familles disponibles et la configuration influencent aussi le résultat. Le manuel de getent décrit ahosts et l’appel de résolution utilisé.

Un navigateur peut avoir son propre cache, un proxy ou un autre parcours de résolution. Il n’est donc pas garanti qu’il utilise exactement la même réponse que getent. Si le système utilise systemd-resolved, consultez aussi ses paramètres par interface :

resolvectl status

Relevez les serveurs DNS et les domaines associés aux liens pertinents. La présence de resolvectl ne prouve pas que toutes les applications passent par ce résolveur. Si la commande ou le service n’est pas disponible, vérifiez le gestionnaire réseau et le résolveur réellement utilisés ; la documentation de resolvectl concerne systemd-resolved. Écraser /etc/resolv.conf sans comprendre qui le gère peut faire disparaître une configuration ou être annulé au prochain renouvellement.

Associer un port à son protocole et à son adresse d’écoute

Un port est un numéro de point de communication au niveau du transport. TCP, Transmission Control Protocol, et UDP, User Datagram Protocol, utilisent des espaces distincts : TCP 443 et UDP 443 ne sont pas le même point de communication. Une règle de pare-feu doit donc préciser le protocole concerné.

Le registre IANA des services et ports associe des usages à des numéros et protocoles. Cette inscription ne prouve pas qu’une application donnée écoute sur votre machine, ni que tout trafic sur ce numéro est authentique ou autorisé.

ss -lnt

Cette commande décrit les sockets TCP en écoute sur la machine où elle est lancée : -l sélectionne l’écoute, -n conserve les numéros et -t sélectionne TCP. Elle ne scanne pas le serveur example.com et ne liste pas les sockets UDP. Le manuel de ss définit ces sélections.

Dans la colonne d’adresse locale, une forme comme 127.0.0.1:PORT limite l’écoute à la boucle locale IPv4. Une adresse d’interface, une écoute générique IPv4 ou une écoute IPv6 désignent d’autres portées. Ces formes sont des exemples de lecture, pas des lignes promises sur votre système ; remplacez PORT par le numéro observé. Même une écoute générique ne prouve pas l’accès depuis Internet : routage, filtrage, traduction éventuelle et configuration IPv6 restent à vérifier.

Un client utilise aussi un port source, souvent choisi temporairement par le système. Il n’a pas besoin d’écouter lui-même sur TCP 443 pour demander une page à un serveur HTTPS sur ce port. Il faut distinguer le côté client, le côté serveur et le sens de la communication.

Situer TCP, TLS et HTTP dans l’accès HTTPS

HTTP signifie Hypertext Transfer Protocol, le protocole des requêtes et réponses web. HTTPS est HTTP protégé par TLS, Transport Layer Security. Pour une nouvelle connexion directe en HTTP/1.1 ou HTTP/2 sur HTTPS, le parcours comprend habituellement l’obtention d’une adresse, le choix d’une route, la connexion TCP, l’établissement de TLS puis la requête HTTP.

Ce parcours est une explication des rôles, pas la promesse d’une nouvelle requête DNS et d’une nouvelle connexion à chaque page : caches et connexions réutilisées interviennent. HTTP/3 utilise QUIC sur UDP, avec la sécurité TLS intégrée à ce transport, au lieu du même enchaînement TCP puis TLS. La spécification HTTP/3 explique cette différence ; QUIC est le nom du protocole, sans développement d’acronyme imposé ici.

Si curl est présent, vous pouvez demander les en-têtes du domaine d’exemple :

curl -I --connect-timeout 5 --max-time 15 https://example.com/

-I émet une requête HTTP HEAD. --connect-timeout limite à 5 secondes la phase de connexion, qui inclut la résolution et les négociations nécessaires ; --max-time fixe une limite globale de 15 secondes pour ce transfert. Les options sont définies dans le manuel officiel de curl. Un délai dépassé ne désigne pas à lui seul la couche responsable.

En cas de réponse, examinez la version HTTP, le code et les en-têtes ; ne vous attendez pas à une adresse ou une date fixe. Un code 200, une redirection ou un refus ne répondent pas à la même question. Par défaut, curl peut terminer avec l’état 0 malgré un code HTTP d’erreur : lisez aussi la réponse applicative. Un serveur qui refuse HEAD peut accepter GET ; le refus de cette méthode ne suffit pas à conclure à une panne DNS.

Si curl manque, vérifiez sa disponibilité avec le gestionnaire de votre distribution : sudo apt install curl sur Ubuntu ou sudo dnf install curl sur Rocky Linux, après examen du plan. Cette installation facultative modifie les paquets, contrairement aux consultations réseau ; le cours de gestion des paquets APT et DNF détaille ce contrôle.

Un proxy ou une politique réseau peut modifier le chemin effectivement suivi. Une erreur de certificat doit être analysée avec le nom demandé, l’heure de la machine et la chaîne de confiance ; contourner sa vérification ne démontre pas que la connexion d’origine est correcte. Obtenir une réponse HTTP d’un intermédiaire ne prouve pas toujours que l’origine souhaitée a été atteinte directement.

Choisir ce qu’il faut vérifier à partir des observations

1. Si l’interface attendue n’a pas d’adresse utilisable, examinez sa connexion et le mode réseau de la machine virtuelle avant d’accuser le DNS.
2. Si une adresse est présente, lisez les routes de la bonne famille et la passerelle pertinente. Une adresse locale valide ne garantit pas un chemin jusqu’à la destination.
3. Si le nom ne se résout pas par le parcours testé, vérifiez les sources de noms, le résolveur, les caches et les paramètres du lien concerné.
4. Si la résolution aboutit mais la connexion échoue, distinguez l’adresse sélectionnée, le protocole, l’écoute du serveur et le filtrage. ss lancé sur le client ne remplace pas une consultation du serveur.
5. Si l’échange sécurisé ou HTTP échoue, lisez son message précis : certificat, méthode refusée, authentification et ressource absente ne se corrigent pas tous en changeant le DNS.

Une consultation donne une preuve limitée à son périmètre et à son instant. Conservez le nom demandé, la famille d’adresse, le port, la machine interrogée et le résultat pour comparer des essais équivalents. Cette distinction permet de chercher dans la couche concernée sans changer simultanément l’adresse, le résolveur et le pare-feu.