Services réseau : DHCP, DNS et autres

DHCP, le protocole de configuration dynamique des hôtes, fournit une adresse IPv4 et des paramètres pour une durée limitée appelée bail. Le serveur écoute sur le port UDP 67 ; le client utilise le port UDP 68. Les ordinateurs portables, les imprimantes, les téléphones et les interfaces de routeur peuvent tous être des clients. Sur Cisco IOS, ip address dhcp permet à une interface de demander ses paramètres.

Obtenir le premier bail

Un nouveau client utilise quatre messages, désignés par DORA :

1. Discover : sans adresse utilisable ni serveur connu, le client envoie une diffusion de 0.0.0.0 à 255.255.255.255.
2. Offer : un serveur propose une adresse, une durée de bail et des paramètres.
3. Request : le client demande l’offre choisie. Cette requête est normalement diffusée afin que les autres serveurs ayant fait une offre sachent qu’ils n’ont pas été sélectionnés.
4. Acknowledge : le serveur choisi confirme le bail. Le client peut maintenant utiliser l’adresse.

Par exemple, un ordinateur portable reçoit 192.168.10.57/24, la passerelle 192.168.10.1, le serveur DNS 192.168.10.5 et un bail de 8 heures. De nombreux clients vérifient l’adresse avec ARP avant de l’utiliser. Si un autre hôte répond pour cette adresse, le client envoie DHCPDECLINE et recommence.

Les paramètres arrivent sous forme d’options numérotées. L’option 1 fournit le masque de sous-réseau, la 3 le routeur, la 6 les serveurs DNS, la 15 le nom de domaine et la 51 la durée du bail. Des options comme 43 ou 150 aident les téléphones et les points d’accès à trouver un contrôleur ou un serveur de configuration. Une adresse correcte accompagnée d’un serveur DNS incorrect reste donc un problème de configuration DHCP.

Renouveler avant la fin du bail

Le bail comporte deux échéances de renouvellement par défaut, mesurées depuis son début :

Une confirmation pendant le renouvellement fait repartir le bail, généralement pour la même adresse. Les utilisateurs continuent à travailler pendant le renouvellement normal en arrière-plan ; un bail court ne les déconnecte pas à intervalles réguliers.

Sous Windows, ipconfig /all affiche le serveur et les heures du bail. ipconfig /release restitue l’adresse et ipconfig /renew demande un bail. Un appareil qui part sans libérer son adresse conserve son bail jusqu’à son expiration. Si DHCP échoue, Windows peut s’attribuer une adresse locale au lien APIPA, comme 169.254.37.112. Elle permet de communiquer avec les autres hôtes locaux au lien sur ce segment, mais ne donne pas d’accès routé à Internet.

Comparer la configuration des adresses IPv6

Avec SLAAC, un hôte construit une adresse IPv6 à partir d’un préfixe /64 annoncé par un routeur. Les indicateurs de l’annonce de routeur orientent les hôtes vers DHCPv6 : M demande une configuration d’adresse avec état ; O demande d’autres paramètres comme DNS. DHCPv6 avec état fournit une adresse ; DHCPv6 sans état fournit des paramètres supplémentaires tandis que SLAAC fournit l’adresse. DHCPv6 utilise UDP 546 pour les clients et 547 pour les serveurs. La passerelle par défaut provient des annonces de routeur ou d’une configuration manuelle, et non de DHCPv6.

Une étendue, appelée pool sur les équipements Cisco, associe les adresses attribuables par bail d’un sous-réseau aux paramètres dont les clients y ont besoin. Planifie les adresses avant de saisir les commandes, afin que le serveur DHCP et les appareils configurés manuellement ne revendiquent jamais la même adresse.

Choisir la plage disponible

Commence par le réseau, le préfixe et la plage d’adresses hôtes utilisables. Répertorie la passerelle, les serveurs et les autres appareils à adresse fixe, puis exclus leurs adresses. Pour 192.168.10.0/24, la plage utilisable va de .1 à .254. L’exclusion de .1 à .20 laisse .21 à .254 :

Ce pool permet d’attribuer 234 baux. Il ne suffit pas pour les 260 clients attendus ; utilise un sous-réseau plus grand, comme un /23 avec 510 adresses utilisables, ou un autre sous-réseau. Pour prévoir l’extension, compte les espaces exclus et réservés ainsi que les utilisateurs actifs.

Une exclusion indique au serveur de ne jamais attribuer une adresse par bail. Une réservation DHCP associe une adresse à une adresse MAC ou à un identifiant client précis, tandis que l’appareil continue d’utiliser DHCP. Une imprimante avec réservation reçoit les paramètres DNS mis à jour lors du renouvellement. Une imprimante dont la configuration statique a été saisie manuellement doit être mise à jour sur l’appareil lui-même.

Configurer un pool sur Cisco IOS

Saisis l’exclusion en configuration globale. Les autres paramètres appartiennent au pool :

ip dhcp excluded-address 192.168.10.1 192.168.10.20
ip dhcp pool OFFICE
 network 192.168.10.0 255.255.255.0
 default-router 192.168.10.1
 dns-server 192.168.10.5
 domain-name example.com
 lease 0 8

lease 0 8 signifie 0 jour et 8 heures. Sans commande de bail, IOS utilise 1 jour par défaut. La passerelle doit correspondre à ce sous-réseau ; copier le default-router d’un autre pool peut laisser les clients joindre les hôtes locaux sans pouvoir sortir de leur réseau.

Vérifie le résultat avec show ip dhcp pool pour la capacité du pool, show ip dhcp binding pour les clients et les heures d’expiration, et show ip dhcp conflict pour les adresses retirées après un conflit. Windows Server utilise les mêmes concepts d’étendue, d’exclusion, de réservation et d’option ; les options d’étendue peuvent remplacer celles définies pour tout le serveur.

Adapter la durée du bail et la redondance aux besoins

Des baux d’environ 1 à 4 heures conviennent au Wi-Fi invité, car les adresses des appareils partis sont libérées plus tôt à l’expiration des baux. Les postes fixes stables peuvent utiliser des baux de plusieurs jours ; Windows Server utilise 8 jours par défaut. Un pool de 200 adresses accueillant 60 nouveaux appareils invités par jour peut se remplir en environ 3,3 jours si ces baux restent actifs. Réduire la durée configurée aide à mesure que les nouveaux baux et les renouvellements prennent effet ; cela n’efface pas instantanément les baux existants.

Deux serveurs peuvent se partager la plage sans chevauchement, par exemple selon une répartition 80/20, ou utiliser une fonction de basculement prise en charge qui partage l’état des baux. Deux serveurs indépendants ne doivent pas attribuer librement les mêmes adresses : chacun pourrait sinon donner une même adresse à un client différent.

Un client diffuse son message Discover sur son segment local. Un routeur ordinaire ne transmet pas cette diffusion : un serveur DHCP situé dans un autre sous-réseau a donc besoin d’un relais DHCP pour la recevoir. Le relais fonctionne généralement sur l’interface du routeur ou du commutateur de couche 3 qui sert de passerelle au sous-réseau du client.

Relayer la requête et identifier le sous-réseau

Le relais reçoit la diffusion et envoie une requête en monodiffusion au serveur. Il insère l’adresse de son interface tournée vers le client dans giaddr, le champ d’adresse IP de la passerelle. Le serveur utilise cette adresse pour sélectionner l’étendue du client et renvoie sa réponse par le relais.

Pour le VLAN 20, supposons que la passerelle soit 192.168.20.1 sur GigabitEthernet0/1 et que le serveur soit 10.0.0.10. Configure :

interface GigabitEthernet0/1
 ip helper-address 10.0.0.10

La commande doit être placée sur l’interface tournée vers le client. Un relais configuré sur l’interface tournée vers le serveur ne reçoit pas la diffusion du client. Le serveur a aussi besoin d’une étendue pour 192.168.20.0/24 et d’une route de retour vers 192.168.20.1. Une seconde ligne de relais peut désigner un serveur de secours. Sur IOS, les adresses de relais transmettent par défaut plusieurs services UDP diffusés, dont DNS et TFTP ; examine donc ce comportement lors de la conception du réseau.

Partir du client pour examiner le réseau

Utilise le symptôme pour choisir la prochaine vérification :

Inspecte ensuite le chemin. Vérifie le VLAN du port du commutateur, l’adresse du serveur dans la configuration du relais, le routage dans les deux sens et les règles d’ACL ou de pare-feu pour DHCP. Les clients utilisent UDP 68 et les serveurs UDP 67 ; le trafic du relais vers le serveur utilise le port du serveur. Le bon fonctionnement de DNS ne prouve pas que le trafic DHCP est autorisé.

Par exemple, le VLAN 10 fonctionne, mais un nouveau VLAN 30 ne reçoit que des adresses APIPA. Si le serveur est distant et que le VLAN 30 n’a pas de relais configuré, son Discover n’atteint jamais le serveur. Ajoute le relais sur la passerelle de ce VLAN et vérifie que le serveur possède une étendue correspondante avant de tester à nouveau le renouvellement.

Corriger la cause avant d’effacer les informations d’état

Un pool épuisé ne possède aucune adresse libre à proposer. Dans show ip dhcp pool, compare les adresses attribuées au total diminué des adresses exclues, puis consulte la liste des conflits pour trouver d’autres adresses indisponibles. Répéter ipconfig /renew ne crée pas de capacité. Examine les exclusions et les réservations obsolètes, adapte la durée du bail au renouvellement des appareils ou agrandis l’espace d’adressage.

Un appareil à adresse statique dans le pool dynamique peut provoquer des avertissements d’adresse en double. Trouve et corrige ce chevauchement, puis efface les entrées de conflit résolues avec clear ip dhcp conflict * lorsque c’est approprié. Effacer la liste alors que l’adresse en double existe encore risque de reproduire la même panne.

Un serveur DHCP non autorisé, souvent un routeur domestique branché au réseau, peut fournir une mauvaise passerelle. Identifie-le à partir de la configuration du client et retire-le. La surveillance DHCP empêche les ports non fiables des commutateurs d’envoyer des réponses de serveur, protégeant ainsi les clients suivants de la même erreur.

La gestion des adresses IP (IPAM) associe la planification à la tenue des registres et à la découverte des adresses. Elle répond à des questions pratiques : quel sous-réseau appartient à ce VLAN ? Qui est responsable de cette adresse ? Est-elle statique, réservée ou attribuée par bail ? Quelle plage a encore de la place ? Un tableur peut contenir un petit plan ; un outil dédié peut aussi comparer ce plan aux appareils présents sur le réseau. Les produits qui associent DNS, DHCP et IPAM sont appelés DDI.

Enregistrer les informations nécessaires au prochain changement

Pour chaque sous-réseau, enregistre le réseau et le préfixe, l’identifiant VLAN, la passerelle, l’usage, l’emplacement, la plage DHCP et les exclusions. Pour chaque attribution statique, enregistre le nom d’hôte, l’adresse MAC, le type d’appareil, son responsable et la date d’attribution. Ces champs permettent de distinguer une adresse simplement silencieuse d’une adresse disponible pour une nouvelle attribution.

Un site utilisant 10.20.0.0/16 pourrait attribuer :

Dans chaque sous-réseau, .1 peut être la passerelle, .2 à .20 la plage fixe et .21 à .254 la plage DHCP. Documenter cette organisation aide un technicien à reconnaître le rôle d’un appareil et empêche deux équipes d’attribuer des espaces qui se chevauchent. Le plan nécessite toujours un enregistrement individuel lors de l’attribution d’une adresse fixe.

Mesurer la marge disponible

Le taux d’utilisation des adresses compare les adresses utilisées aux adresses utilisables :

Un /22 compte 1 022 adresses IPv4 utilisables. Si 870 sont utilisées, le taux d’utilisation est d’environ 85,1 %. Un seuil d’alerte de 80 % aurait déjà déclenché la planification d’un espace supplémentaire. Distingue cette mesure du sous-réseau de la disponibilité du pool DHCP : les exclusions et les réservations peuvent remplir un pool dynamique alors que le sous-réseau possède encore des adresses non attribuées.

Confronter le plan aux observations

La découverte IPAM peut lire les baux DHCP, les enregistrements DNS et les tables ARP des routeurs, ainsi que balayer les sous-réseaux. Compare ces vues : une adresse découverte sans responsable peut correspondre à un appareil non documenté ; un serveur enregistré dont on ne trouve aucune trace actuelle peut avoir été retiré du service. Examine l’écart avant de modifier l’attribution.

Avant d’attribuer une adresse statique, vérifie l’enregistrement IPAM, les baux DHCP et le DNS. L’absence de réponse à un ping ne suffit pas : l’appareil qui utilise actuellement l’adresse peut être éteint ou bloquer les pings. Après l’attribution, enregistre l’appareil et empêche DHCP d’attribuer la même adresse. Lors de sa mise hors service, récupère l’adresse et supprime les enregistrements DNS obsolètes afin qu’un futur utilisateur ne reçoive pas l’ancien nom.

DHCP peut mettre à jour DNS dynamiquement afin que les enregistrements A et PTR d’un client restent cohérents avec son bail. IPAM rassemble ces enregistrements dans une même vue, mais la découverte automatique a toujours besoin d’un plan exact et d’informations sur les responsables pour expliquer le rôle prévu d’un appareil.

IPv6 supprime la nécessité de compter chaque adresse d’hôte possible dans un /64. Il ne supprime pas le besoin de planifier. Enregistre le préfixe /64 qui appartient à chaque site et à chaque VLAN, ainsi que les passerelles et les attributions fixes importantes. Suis la structure de l’espace d’adressage et les responsabilités associées, même lorsque les adresses d’hôtes individuelles changent souvent.

DNS, le système de noms de domaine, stocke des informations sous des noms organisés en arborescence. Lis www.example.com. de droite à gauche : la racine est le point final, com est le domaine de premier niveau, et example et www désignent les niveaux inférieurs. Un nom de domaine pleinement qualifié (FQDN) indique le chemin complet jusqu’à la racine.

Trouver qui détient la réponse

Une zone est une partie administrée de cette arborescence, détenue par des serveurs de noms faisant autorité. Le serveur principal possède la copie modifiable ; les serveurs secondaires détiennent des copies en lecture seule obtenues par transfert de zone sur TCP 53. Le numéro de série SOA permet aux serveurs secondaires de détecter une version plus récente. Plusieurs serveurs faisant autorité maintiennent les réponses disponibles lorsqu’un serveur tombe en panne.

Lire le type d’enregistrement avant sa valeur

Par exemple, "www.example.com. 3600 IN A 203.0.113.10" associe un nom à une adresse IPv4. "www.example.com. 3600 IN AAAA 2001:db8::10" fournit l’adresse IPv6. Dans ces enregistrements, 3600 est la durée de conservation en cache en secondes et IN est la classe Internet.

Un alias tel que "shop.example.com. 3600 IN CNAME www.example.com." pointe vers le nom et non directement vers son adresse. Une requête suit cette cible pour obtenir une réponse A ou AAAA. Un CNAME ne peut pas partager son nom avec des données ordinaires telles que des enregistrements A, MX, SOA ou NS. Les métadonnées DNSSEC constituent une exception particulière. Le sommet de zone a besoin d’enregistrements SOA et NS ; on ne peut donc pas y placer un CNAME standard. Les fonctions d’alias ou d’aplatissement des fournisseurs traitent les enregistrements autrement.

Les préférences MX fonctionnent dans le sens inverse d’un score où « plus c’est élevé, mieux c’est ». Avec la préférence 10 pour mail1.example.com. et 20 pour mail2.example.com., les expéditeurs essaient d’abord mail1. Les valeurs MX doivent être des noms d’hôtes dotés d’enregistrements A ou AAAA directs. Les cibles MX et NS ne doivent pas être des alias CNAME.

Inverser l’adresse et contrôler la mise en cache

Une résolution directe part d’un nom ; une résolution inverse part d’une adresse. Pour l’adresse IPv4 203.0.113.25, le nom associé à l’enregistrement PTR est 25.113.0.203.in-addr.arpa.. La résolution inverse IPv6 utilise les chiffres hexadécimaux dans l’ordre inverse sous ip6.arpa. Ajouter un enregistrement A ne crée pas de PTR, sauf si une fonction de mise à jour le fait.

La durée de vie (TTL) est la durée maximale normale de conservation en cache, en secondes : 300 correspond à 5 minutes, 3600 à une heure et 86400 à un jour. Avant un changement d’adresse, réduis la durée de vie de 86400 à 300 et attends au moins l’ancienne durée de vie d’un jour. Modifie ensuite l’adresse, ce qui permet aux caches ordinaires de se mettre à jour dans les 5 minutes, puis augmente à nouveau la durée de vie après le déplacement.

Dans un fichier de zone, un nom sans point final est relatif à la zone courante. Écrire mail.example.com dans la zone example.com produit mail.example.com.example.com. Utilise mail.example.com. pour le nom complet, ou le nom relatif mail.

Un ordinateur ne contacte normalement pas lui-même chaque serveur DNS. Son résolveur minimal demande à un résolveur récursif d’obtenir la réponse. Le résolveur dispose soit d’une réponse utilisable en cache, soit contacte les serveurs faisant autorité pour certaines parties du nom.

Commencer sur le client

Les sources locales comprennent le fichier hosts et le cache DNS du client. Une entrée hosts peut prendre le pas sur DNS pour cet ordinateur. Le chemin sous Windows est C:\Windows\System32\drivers\etc\hosts ; Linux et macOS utilisent /etc/hosts. Une entrée de test oubliée peut expliquer pourquoi un ordinateur joint un ancien serveur alors que tous les autres fonctionnent.

Le client apprend l’adresse de son résolveur par l’option DHCP 6 ou par une configuration manuelle. Sa requête est récursive : il demande au résolveur la réponse finale. Le client délègue la recherche, il ne demande pas vers quel serveur DNS se diriger ensuite.

Partir de la racine vers le nom

Pour une requête sur www.example.com avec des caches vides :

1. Le client interroge son résolveur récursif.
2. Le résolveur interroge un serveur racine, qui le renvoie vers les serveurs com.
3. Un serveur com le renvoie vers les serveurs faisant autorité pour example.com.
4. Un serveur du domaine renvoie "A 203.0.113.10", avec une durée de vie de 3600.
5. Le résolveur met cette réponse en cache et la renvoie au client.

Les requêtes du résolveur dans la hiérarchie sont itératives : chaque serveur fournit la meilleure réponse ou le meilleur renvoi dont il dispose. La racine ne détient pas l’adresse de chaque site. Il existe 13 identités de serveur racine, nommées de a à m, chacune étant desservie par de nombreux systèmes physiques utilisant des adresses anycast.

Le client suivant peut recevoir la réponse en cache sans répéter cette recherche. Un outil peut l’indiquer comme "Non-authoritative answer" ; cela désigne la source de la réponse, et non une erreur. Les renvois et les réponses négatives sont aussi mis en cache. Un résultat NXDOMAIN peut donc rester visible après l’ajout d’un nom manquant, jusqu’à l’expiration de sa durée de mise en cache négative.

Utiliser un redirecteur lorsqu’un autre résolveur doit chercher

Un résolveur peut envoyer les requêtes auxquelles il ne répond pas à un redirecteur en amont, qui effectue la recherche. Un redirecteur conditionnel envoie les requêtes pour un domaine particulier à des serveurs désignés. Par exemple, une entreprise peut diriger le domaine interne d’un partenaire vers le résolveur de ce partenaire, tout en envoyant les noms publics ordinaires ailleurs.

Distinguer confidentialité et authenticité

DNS ordinaire utilise le port UDP ou TCP 53. La plupart des petites requêtes utilisent UDP ; les transferts de zone et de nombreuses réponses volumineuses utilisent TCP. DNS sur TLS (DoT) chiffre la connexion entre le client et le résolveur sur TCP 853. DNS sur HTTPS (DoH) transporte les requêtes par HTTPS sur le port 443 et peut contourner un filtrage qui ne surveille que DNS ordinaire.

DNSSEC, quant à lui, permet à un résolveur qui valide les signatures de détecter les données DNS modifiées ou falsifiées. Il ne chiffre ni les requêtes ni les réponses. Le chiffrement protège le chemin de transport ; les données signées permettent de vérifier l’authenticité.

Après la modification d’une adresse, les serveurs faisant autorité publient les nouvelles données, mais ne les envoient pas dans chaque cache de résolveur. Les utilisateurs peuvent temporairement recevoir des réponses différentes parce que les durées de vie restantes de leurs copies en cache diffèrent. Cette durée de conservation explique le délai habituellement décrit comme la « propagation DNS ».

Commence par relever l’erreur exacte. « Hôte introuvable » signifie qu’une résolution de nom a échoué. « Connexion refusée » après une résolution réussie indique un problème ailleurs. Tester une adresse connue, puis son nom, aide à distinguer la résolution de noms de l’accès à la destination.

Si ping 203.0.113.10 fonctionne mais que ping www.example.com indique qu’il ne trouve pas l’hôte, examine la résolution. Si les deux échouent, vérifie l’adressage et le routage, mais rappelle-toi qu’un ping peut aussi être filtré. Un ping qui échoue ne suffit pas à établir que DNS est en panne ou que le service est inaccessible.

Interroger directement le bon serveur

Trouve les serveurs DNS configurés à l’aide de ipconfig /all, resolvectl status ou /etc/resolv.conf, selon le cas. Compare ensuite les requêtes :

nslookup www.example.com
nslookup www.example.com 192.0.2.53
nslookup -type=MX example.com
dig @192.0.2.53 example.com MX
dig -x 203.0.113.25
dig +trace www.example.com
Resolve-DnsName www.example.com -Type AAAA

La première requête teste le résolveur choisi par le client ; une adresse de serveur indiquée explicitement teste un résolveur ou un serveur faisant autorité choisi. dig +trace suit les renvois. Si une requête directe réussit mais que la résolution par une application échoue, examine les paramètres locaux, le cache ou le fichier hosts.

Interpréter la réponse

SERVFAIL peut résulter d’un serveur faisant autorité inaccessible ou d’un échec de validation DNSSEC. REFUSED indique autre chose : un serveur joignable peut n’autoriser la récursion que pour les clients internes. Dans dig, l’indicateur aa désigne une réponse faisant autorité.

Comparer les anciennes et les nouvelles données

Supposons qu’un serveur soit passé de 203.0.113.10 à 203.0.113.80. Le serveur faisant autorité renvoie .80 tandis que le résolveur du bureau renvoie .10 avec une partie de l’ancienne durée de vie de 86400 secondes encore disponible. La modification est publiée ; le cache du bureau est obsolète. Attends son expiration ou vide les caches concernés du résolveur et des clients. ipconfig /flushdns vide le cache du client Windows, pas tous les caches en amont. Réduire la durée de vie à l’avance évite une longue attente lors d’un déplacement prévu.

Lorsqu’un seul ordinateur donne un résultat différent, examine son fichier hosts et son cache local. Lorsque les serveurs faisant autorité ne sont pas d’accord, compare les numéros de série SOA : une zone principale modifiée dont le numéro de série n’a pas changé peut ne pas être transférée aux serveurs secondaires.

Associer le service en panne à ses enregistrements

Un enregistrement A incorrect affecte IPv4. Un enregistrement AAAA incorrect ou inutilisable peut retarder les connexions IPv6 même si IPv4 fonctionne ; un serveur uniquement IPv4 n’a pas besoin d’enregistrement AAAA. Pour la messagerie, vérifie les noms MX et leurs enregistrements A ou AAAA directs. Sans MX, les expéditeurs peuvent essayer les enregistrements d’adresse du domaine lui-même. Un PTR manquant peut affecter l’acceptation des messages et rendre les journaux plus difficiles à lire.

Enfin, autorise à la fois UDP et TCP 53 là où DNS ordinaire en a besoin. Un pare-feu qui n’autorise qu’UDP peut laisser passer les petites réponses tout en empêchant les réponses volumineuses et les transferts de zone.

Une heure commune rend les événements comparables. Si un commutateur enregistre une panne de port et qu’un routeur enregistre la perte d’un voisin, des horodatages exacts aident à établir leur ordre. L’heure influe aussi sur la validité des certificats et sur l’authentification : par défaut, Kerberos dans Active Directory n’autorise que 5 minutes d’écart entre les horloges.

Comprendre la hiérarchie des horloges

NTP, le protocole de synchronisation de l’heure réseau, échange des paquets horodatés sur UDP 123. Quatre horodatages permettent au client d’estimer le décalage de son horloge et le délai réseau. Il renouvelle ses interrogations, généralement à des intervalles de 64 à 1 024 secondes. Les petites corrections sont généralement effectuées de façon progressive : cet ajustement progressif de l’horloge évite les reculs brusques de l’heure.

Une strate décrit la distance par rapport à une horloge de référence :

Les strates réseau utilisables vont de 1 à 15. La strate n’est pas un indicateur de précision : un serveur de strate 2 proche peut donner de meilleurs résultats qu’une source de strate 1 distante, accessible par un chemin dont le délai varie.

Utilise plusieurs sources en amont, idéalement au moins quatre, pour les serveurs de temps internes. NTP peut ainsi comparer les sources et rejeter une source erronée. Les autres équipements réseau peuvent se synchroniser sur ces serveurs internes, ce qui limite le trafic externe et assure une chronologie locale cohérente.

Configurer et vérifier un client

Sur Cisco IOS, ntp server 192.0.2.123 sélectionne un serveur en amont ; l’ajout de prefer désigne une source préférée. Un équipement synchronisé peut ensuite répondre aux requêtes de temps d’autres équipements. ntp master 4 annonce quant à lui l’horloge du routeur comme source de strate 4. La strate par défaut est 8 lorsque le numéro est omis. N’utilise une telle référence locale que lorsqu’aucune meilleure source n’existe, par exemple dans un laboratoire isolé.

Consulte show ntp status pour vérifier la synchronisation et la strate locale. Si le serveur en amont est de strate 2, le client synchronisé devient de strate 3. Dans show ntp associations, un astérisque marque la source sélectionnée. Laisse plusieurs minutes à une nouvelle association pour se stabiliser avant de considérer l’état initial non synchronisé comme une panne persistante.

NTP distribue l’heure UTC. La configuration du fuseau horaire et de l’heure d’été de l’équipement détermine l’heure locale affichée. Par exemple, clock timezone CET 1 définit sur IOS un décalage standard d’une heure. Une erreur correspondant exactement à un nombre entier d’heures oriente vers les paramètres d’affichage. De nombreuses organisations enregistrent leurs journaux en UTC pour éviter les conversions entre sites pendant un incident.

Protéger l’heure et choisir la précision nécessaire

L’authentification par clé symétrique limite les sources de temps acceptées à celles qui partagent la clé configurée. NTS utilise un échange de clés fondé sur TLS sur TCP 4460, puis authentifie les paquets NTP qui continuent de transiter sur UDP 123. Limite aussi les hôtes autorisés à interroger ou à contrôler les services de temps.

PTP (IEEE 1588) suit une horloge grand maître et utilise des horodatages matériels dans les cartes réseau et les commutateurs pour atteindre une précision inférieure à la microseconde sur des réseaux locaux adaptés. Il répond à des besoins comme ceux des réseaux mobiles et du contrôle industriel, pour lesquels la précision de NTP ordinaire, de l’ordre de la milliseconde, est insuffisante. PTP peut fonctionner sur Ethernet ou sur IP ; le transport IP utilise UDP 319 pour les messages d’événement et UDP 320 pour les messages généraux. SNTP est une implémentation plus simple de NTP destinée aux clients dont les besoins de précision sont moins exigeants.

SNMP, le protocole simple de gestion de réseau, permet à un gestionnaire de supervision de lire les données d’un agent sur un équipement. Les données sont décrites par une base d’informations de gestion (MIB). Chaque objet possède un identifiant d’objet (OID), un chemin composé de nombres séparés par des points dans une arborescence. Par exemple, 1.3.6.1.2.1.1.5.0 identifie sysName ; 1.3.6.1.2.1.1.3.0 identifie sysUpTime. Les objets des fournisseurs se trouvent sous la branche enterprises, 1.3.6.1.4.1.

Associer les interrogations périodiques aux alertes

L’agent écoute les requêtes sur UDP 161. Le gestionnaire reçoit les traps et les informs sur UDP 162.

Un gestionnaire peut interroger le trafic, le processeur et la mémoire toutes les 5 minutes pour construire des graphiques. Un trap peut signaler immédiatement une liaison en panne. Utilise les deux : les traps peuvent être perdus sur UDP et un équipement en panne peut être incapable d’envoyer la moindre notification. Les informs sont renvoyés selon les paramètres de délai et de nouvelle tentative, mais peuvent tout de même échouer une fois les tentatives épuisées.

Choisir une version sécurisée

SNMPv1 et v2c envoient une chaîne de communauté en clair. L’accès en lecture seule (RO) permet de lire ; l’accès en lecture-écriture (RW) permet aussi les modifications prises en charge. La version 2c ajoute GetBulk, les informs et les compteurs haute capacité. SNMPv3 utilise des comptes avec les niveaux de sécurité noAuthNoPriv, authNoPriv et authPriv. Privilégie authPriv, qui authentifie et chiffre les messages, lorsqu’il est pris en charge.

Une configuration IOS v2c peut utiliser snmp-server community N3tM0n-RO RO 10 pour restreindre la lecture avec l’ACL 10. snmp-server host 192.0.2.50 version 2c N3tM0n-RO sélectionne le destinataire des notifications et snmp-server enable traps active les traps. Voici un exemple pour v3 :

snmp-server group NMS v3 priv
snmp-server user monitor NMS v3 auth sha <auth-password> priv aes 128 <priv-password>

Évite les communautés par défaut telles que "public" et "private", limite l’accès aux hôtes d’administration et n’accorde l’accès en écriture que si nécessaire. SNMP expose les objets de la MIB ; ce n’est pas un interpréteur de commandes distant.

Convertir une différence de compteur en taux d’utilisation

Les compteurs mesurent un total d’octets, appelés bytes en anglais. Supposons que ifHCInOctets passe de 18 250 000 000 à 19 750 000 000 en 300 secondes :

1. Soustrais les relevés : 1 500 000 000 octets sont arrivés.
2. Multiplie par 8 : 12 000 000 000 bits sont arrivés.
3. Divise par 300 secondes : 40 000 000 bit/s, soit 40 Mbit/s.
4. Divise par le débit de la liaison de 100 Mbit/s : le taux d’utilisation moyen en entrée était de 40 %.

Il s’agit d’une moyenne sur l’intervalle ; de brefs pics peuvent donc être plus élevés. Oublier le facteur de conversion des octets en bits donne un débit huit fois trop faible.

Un compteur 32 bits atteint 4 294 967 295 et revient à zéro. À 1 Gbit/s, il revient à zéro en environ 34 secondes ; un intervalle d’interrogation de 5 minutes peut donc manquer plusieurs retours à zéro. Pour les liaisons rapides, utilise ifHCInOctets et ifHCOutOctets sur 64 bits, pris en charge par v2c et v3. Vérifie la continuité du compteur avant d’interpréter une différence négative comme un trafic négatif.

Syslog envoie des messages d’événement à un collecteur central. La collecte centralisée conserve les traces malgré les redémarrages des équipements et permet à un technicien d’effectuer des recherches sur plusieurs équipements ensemble. Un système de gestion des informations et des événements de sécurité (SIEM) peut utiliser ces enregistrements pour mettre les événements en relation.

Syslog traditionnel utilise UDP 514. Le transport TCP fournit des accusés de réception au niveau de la couche transport ; TLS sur TCP 6514 protège aussi la connexion. Même avec un transport fiable, la collecte et le stockage doivent fonctionner : vérifie donc que les messages arrivent effectivement.

Lire correctement le seuil de gravité

Les niveaux syslog vont de 0 à 7, les nombres les plus faibles correspondant aux événements les plus graves :

Un seuil configuré inclut ce niveau et tous les niveaux plus graves. logging trap warnings envoie les niveaux 0 à 4, pas seulement le niveau 4. Par défaut, la journalisation distante IOS utilise le niveau informational, soit les niveaux 0 à 6. L’activation du débogage envoie tous les niveaux et peut générer beaucoup de trafic et de travail de traitement.

Distinguer la catégorie du niveau de gravité

La catégorie syslog identifie une catégorie de source. Les exemples comprennent kern (0), user (1), mail (2) et auth (4). Local0 à local7, codes 16 à 23, sont disponibles pour un usage local ; les équipements Cisco utilisent local7 par défaut. Un collecteur peut trier les messages des équipements réseau à l’aide de ce code.

La priorité d’un message combine les deux champs :

Local7 au niveau de gravité 3 produit 187, écrit "<187>". Ce nombre est une paire de valeurs encodée, et non une échelle de gravité distincte.

Le modèle visible des messages Cisco est "%FACILITY-SEVERITY-MNEMONIC: description". Dans "%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down", LINEPROTO nomme la fonction IOS, 5 signifie Notice et UPDOWN identifie l’événement. Ce nom de fonction est distinct de la catégorie de transport local7. "%SYS-5-CONFIG_I: Configured from console by admin on vty0" enregistre une modification de configuration.

Choisir les destinations et synchroniser les horodatages

Les destinations ont des paramètres distincts. logging buffered 16384 informational conserve un tampon en mémoire, consultable avec show logging. logging host 192.0.2.50 sélectionne un collecteur. logging trap warnings définit son seuil. Dans une session de terminal distante, terminal monitor affiche les messages surveillés. L’envoi des messages de débogage à la console peut surcharger le processeur d’un équipement très sollicité.

Utilise service timestamps log datetime msec pour ajouter la date et l’heure à la milliseconde près, et NTP pour synchroniser les horloges. Un événement de désactivation de port à 10:42:13.208, une perte de voisin sur un routeur à 10:42:13.350 et le rétablissement du port à 10:42:17.511 forment une séquence utile. Ils suggèrent un problème de liaison associé qu’il faut examiner ; ils ne désignent pas à eux seuls un câble défectueux. Sans heure commune, l’ordre apparent peut simplement refléter un décalage des horloges.

Un appel vocal et un transfert de fichiers ne réagissent pas de la même façon à la congestion. Un fichier peut attendre pendant que TCP retransmet les données manquantes. Une conversation souffre lorsque les paquets arrivent en retard, de manière irrégulière ou disparaissent. La qualité de service (QoS) permet au réseau de traiter différemment les différents trafics.

Identifier les besoins du service

Quatre caractéristiques comptent : la bande passante, la quantité envoyée par seconde ; le délai, le temps de trajet de bout en bout ; la gigue, les fluctuations de ce délai ; et la perte, la part des paquets rejetés. Les objectifs courants pour la voix sont un délai aller simple d’au plus 150 ms, une gigue d’au plus 30 ms et une perte d’au plus 1 %. Ce sont des objectifs de planification pour rendre la voix interactive utilisable, et non une capacité supplémentaire créée par une politique.

La qualité de service repose sur un comportement par saut (PHB). Chaque routeur ou commutateur applique sa propre politique. Un paquet marqué comme prioritaire nécessite tout de même que chaque saut congestionné reconnaisse et serve cette classe. Les priorités de file d’attente modifient l’ordre de service lorsque les trafics sont en concurrence ; la classification, le marquage et les limites de débit peuvent agir même sur une liaison non congestionnée.

Classer d’abord, puis marquer

La classification du trafic identifie le trafic à l’aide des adresses et des ports, d’une interface d’entrée, d’un marquage existant ou de la reconnaissance des applications, comme Cisco NBAR. Le marquage inscrit une valeur dans une trame ou un paquet afin que les équipements suivants puissent identifier sa classe à moindre coût.

DSCP occupe six bits de l’octet ToS d’IPv4 ou Traffic Class d’IPv6. Les deux bits restants servent à ECN, la notification explicite de congestion. CoS ne peut pas apparaître dans une trame envoyée sans l’étiquette VLAN.

Décoder les valeurs DSCP courantes

Le service au mieux vaut 0. Le transfert accéléré (EF) vaut 46, soit 101110 en binaire, et sert couramment au flux vocal. Le transfert assuré (AFxy) indique la classe x, de 1 à 4, et la priorité de rejet y, de 1 à 3 :

Ainsi, AF11, AF21, AF31 et AF41 valent 10, 18, 26 et 34. Pour AF32, calcule 8 fois 3 plus 2 fois 2 pour obtenir 28. Dans la classe 4, AF43 (38) a une priorité de rejet plus élevée qu’AF42 (36), elle-même plus élevée que celle d’AF41 (34). Une priorité de rejet plus élevée signifie que le paquet est plus susceptible d’être rejeté pendant une congestion, et non qu’il est mieux protégé. La politique configurée détermine les ressources attribuées aux différentes classes AF.

Les sélecteurs de classe valent 8 fois leur numéro : CS3 vaut 24, souvent utilisé pour la signalisation des appels ; CS6 vaut 48, couramment utilisé pour le trafic de routage.

Décider à quels marquages faire confiance

À une frontière de confiance, le réseau décide quels marquages entrants il respectera. Un commutateur d’accès peut faire confiance à un téléphone IP tout en ramenant le marquage du trafic du PC connecté au service au mieux. Sinon, un utilisateur pourrait marquer un téléchargement volumineux EF et entrer en concurrence avec les appels. Les services ordinaires des fournisseurs d’accès Internet ne préservent généralement pas le traitement de qualité de service d’un client de bout en bout.

Pour dimensionner la capacité vocale, inclus les en-têtes. Un appel G.711 qui envoie 50 paquets par seconde, chacun contenant 160 octets de voix et 40 octets d’en-têtes, utilise 200 octets par paquet. Multiplier par 8 puis par 50 donne 80 000 bit/s, soit 80 kbit/s par sens. Vingt appels utilisent 1,6 Mbit/s dans chaque sens à la couche IP, avant la surcharge de couche 2.

La congestion commence lorsque les paquets arrivent plus vite qu’une interface ne peut les envoyer. Un réseau local à 1 Gbit/s qui alimente un réseau étendu à 100 Mbit/s peut créer ce goulot d’étranglement même si le réseau local lui-même est peu chargé. Les paquets en attente entrent dans une file de sortie ; le temps passé dans cette file ajoute du délai.

Sélectionner le prochain paquet à envoyer

FIFO, premier entré, premier sorti, envoie les paquets dans leur ordre d’arrivée. La mise en file d’attente équitable pondérée par classes (CBWFQ) donne aux classes de trafic des parts minimales de bande passante pendant une congestion. La mise en file d’attente à faible latence (LLQ) ajoute une file strictement prioritaire pour le trafic sensible au délai, avec une limite configurée pour protéger les autres classes.

Sur un réseau étendu à 100 Mbit/s, une politique pourrait attribuer à la voix une classe prioritaire de 10 Mbit/s, garantir 30 % aux applications métier et laisser le reste au trafic par défaut. Une garantie de bande passante est une part minimale en cas de concurrence, pas nécessairement un maximum lorsque les autres classes sont inactives. La limite prioritaire empêche le trafic de la classe vocale de consommer toute la liaison congestionnée.

Rejeter des paquets avant que toutes les files se remplissent ensemble

Le rejet en fin de file écarte les nouveaux paquets lorsque la file est pleine. Si de nombreux flux TCP subissent cette perte ensemble, ils peuvent tous ralentir puis accélérer à nouveau en même temps. Cette synchronisation globale gaspille de la capacité.

La détection précoce aléatoire pondérée (WRED) commence à rejeter certains paquets avant que la file soit pleine. Les flux ralentissent alors à des moments différents. Une politique qui tient compte de DSCP peut rejeter AF13 plus facilement qu’AF11, car tous deux appartiennent à la classe 1 mais AF13 a une priorité de rejet plus élevée. La voix UDP ne réduit pas son débit d’envoi en réponse à une telle perte ; WRED n’est donc pas le traitement habituel de la file prioritaire vocale.

Distinguer contrôle de débit et lissage

Un fournisseur peut appliquer un contrôle de débit au débit garanti (CIR). Les rafales qui dépassent le contrat peuvent être rejetées même si le port physique est plus rapide. TCP peut présenter une courbe en dents de scie lorsqu’il reprend de la vitesse puis est à nouveau ralenti.

Un dispositif de lissage met les rafales en tampon localement et libère le trafic au débit configuré. La quantité autorisée par rafale sur un intervalle est :

Pour 200 Mbit/s et un intervalle de 10 ms, convertis 10 ms en 0,010 s. La multiplication donne 2 000 000 bits par intervalle ; la division par 8 donne 250 000 octets.

Supposons que le site possède un raccordement à 1 Gbit/s, mais que le fournisseur applique un contrôle de débit à 200 Mbit/s. Lisse le trafic sortant du site à 200 Mbit/s et applique la file vocale dans ce dispositif de lissage. L’attente se produit alors là où le site contrôle la priorité, avant que le fournisseur ne rejette les paquets excédentaires.

Appliquer et examiner la politique

Sur IOS, une class-map identifie le trafic, une policy-map définit les actions et service-policy associe la politique à une interface et à un sens. Une politique de file d’attente ne modifie la concurrence que pendant une congestion. Le contrôle de débit et le lissage imposent toujours leur débit configuré sur une liaison par ailleurs inactive. Des files surdimensionnées peuvent aggraver le délai de la voix en augmentant le temps d’attente.

Un proxy reçoit une requête et émet une requête distincte vers sa destination. Le client se connecte au proxy, puis le proxy se connecte à la destination. Ce rôle au niveau applicatif lui permet de filtrer, de mettre en cache ou d’acheminer les requêtes. NAT, quant à lui, réécrit les adresses dans les paquets sans agir comme serveur chargé des requêtes de l’application.

Se demander qui le proxy représente

Un proxy direct peut fournir une sortie Internet contrôlée unique aux utilisateurs d’une organisation. Un proxy inverse peut publier www.example.com à l’adresse 203.0.113.10 tout en transmettant les requêtes à des serveurs internes comme 10.1.1.21 et 10.1.1.22. La différence tient à la partie représentée.

Configurer ou intercepter le trafic des clients

Un proxy explicite est connu du client. Son adresse et son port, par exemple 10.0.0.8 sur 3128 ou 8080, peuvent être saisis manuellement, distribués par un logiciel d’administration ou sélectionnés à l’aide d’un fichier PAC, de configuration automatique du proxy. WPAD facilite la découverte automatique de la configuration du proxy. Ces numéros de port sont des choix courants, et non des exigences universelles pour tous les proxys.

Un proxy transparent reçoit le trafic redirigé par le réseau sans paramètre de proxy sur le client. Il peut tout de même être un proxy direct, car il agit pour les clients. La connaissance du proxy par le client et la partie représentée sont deux critères de comparaison différents.

Comprendre ce qui arrive à HTTPS

Avec un proxy explicite, un client peut envoyer une requête CONNECT. Le proxy établit un tunnel par lequel passe le trafic chiffré. Le proxy peut voir la destination demandée, mais le tunnel seul ne révèle pas le contenu HTTP protégé.

Pour inspecter ce contenu, le proxy doit effectuer une interception TLS. Il crée des connexions protégées distinctes et présente des certificats signés par l’autorité de certification de l’organisation. Les clients doivent faire confiance à cette autorité. Les applications utilisant l’épinglage de certificat peuvent rejeter ce certificat de remplacement ; certaines destinations doivent donc être exemptées d’inspection. L’interception change aussi qui peut lire le trafic : la confidentialité fait donc partie de la décision de conception.

Un proxy de cache ne peut réutiliser les réponses que lorsque les règles de mise en cache HTTP l’autorisent. Les téléchargements répétés de logiciels ou de ressources statiques peuvent économiser de la bande passante sur le réseau étendu. Les données personnelles ou qui changent fréquemment ne peuvent souvent pas être partagées depuis un cache. Les tunnels chiffrés ordinaires ne donnent pas au proxy accès au contenu nécessaire à cette inspection et à cette mise en cache.

Diagnostiquer une panne propre au proxy

Si la navigation échoue alors que les autres applications fonctionnent, examine l’adresse, le port et l’accessibilité du proxy. Si la configuration automatique échoue, teste l’accès au fichier PAC. Si les sites internes ne fonctionnent pas uniquement lorsqu’ils passent par le proxy, vérifie les règles d’exception : un motif comme *.corp.example.com peut maintenir ces requêtes sur le chemin interne.

Pour les services web entrants, un proxy inverse peut envoyer /api à un serveur d’applications et /images à un serveur de contenu statique. S’il répartit les requêtes admissibles entre plusieurs serveurs en arrière-plan, il effectue aussi une répartition de charge. La terminaison centralisée de TLS simplifie la gestion des certificats, tandis que les connexions internes peuvent être chiffrées à nouveau si nécessaire.

Un répartiteur de charge présente une adresse IP virtuelle (VIP) aux clients et envoie le trafic vers un pool de serveurs en arrière-plan. Le client utilise un seul nom de service tandis que le pool fournit la capacité et tolère les pannes de serveurs individuels. Pour la maintenance, le drainage des connexions arrête l’envoi de nouvelles connexions à un serveur et permet au travail en cours de se terminer avant son retrait.

Tester le service avant de lui envoyer du travail

Un contrôle d’état doit correspondre au service dont les clients ont besoin. Un ping teste si un hôte répond, un contrôle TCP teste si un port accepte les connexions et un contrôle HTTP peut vérifier qu’une page comme /health renvoie l’état 200. Un hôte peut répondre au ping même après la panne de son processus web.

Pour shop.example.com, supposons que l’adresse IP virtuelle soit 203.0.113.20 sur le port 443 et que le pool aille de 10.1.2.11 à 10.1.2.13 sur le port 8080. Les contrôles ont lieu toutes les 5 secondes et marquent un serveur comme indisponible après trois échecs consécutifs. La détection prend environ trois intervalles de contrôle, soit environ 15 secondes ; le délai réel dépend de la planification des contrôles et des délais d’attente. Une fois .13 indisponible, les nouvelles connexions vont à .11 et .12. Ces serveurs restants doivent disposer d’assez de capacité libre pour la charge supplémentaire.

Choisir comment répartir le travail

Les poids 3:2:1 répartissent 600 nouvelles connexions en 300, 200 et 100. Avec 12, 7 et 9 connexions actives, l’algorithme du plus petit nombre de connexions choisit le deuxième serveur. Ces algorithmes choisissent parmi les serveurs admissibles et en bon état, pas parmi ceux déjà retirés par les contrôles d’état.

Maintenir les données de session disponibles

La persistance de session renvoie un utilisateur vers le même serveur lorsque celui-ci stocke sa session, par exemple un panier. Un cookie ou une adresse source peut identifier l’utilisateur. La persistance peut rendre la charge moins uniforme ; si ce serveur tombe en panne, la session de l’utilisateur stockée localement peut être perdue. Une base de données ou un cache partagé permet aux autres serveurs de récupérer la session et réduit la dépendance à un seul serveur en arrière-plan.

Un répartiteur de couche 4 utilise les adresses et les ports pour répartir le trafic TCP ou UDP sans lire le contenu applicatif. Un répartiteur de couche 7 lit des informations comme les noms d’hôtes HTTP, les chemins et les cookies. Pour inspecter le contenu HTTPS, il termine TLS, ce qu’on appelle le déchargement TLS, et peut établir une nouvelle connexion chiffrée vers le serveur en arrière-plan.

Protéger aussi le point d’entrée

Un répartiteur de charge unique peut lui-même tomber en panne. Dans une paire actif-passif, un équipement de secours est prêt à reprendre l’adresse IP virtuelle ; une architecture actif-actif permet aux deux de traiter le trafic.

La répartition cyclique DNS simple publie plusieurs enregistrements A pour un nom et fait tourner leur ordre. Elle offre une distribution simple, mais ne comprend ni contrôles d’état intégrés du service ni retrait immédiat des adresses en cache. Les clients peuvent continuer d’utiliser une adresse en panne jusqu’à la modification des enregistrements et à l’expiration des caches. La répartition globale de charge entre serveurs ajoute aux réponses DNS des décisions fondées sur l’état et l’emplacement, mais les durées de vie en cache restent importantes.