Résumé

  • Le sous-option 11 permet au relais DHCP de fournir l’adresse IPv4 que le serveur place dans l’option 54. Cette valeur organise le trajet du prochain renouvellement ; elle n’authentifie pas le serveur réel.
  • La continuité du bail dépend alors de deux segments observables, client-vers-relais et relais-vers-serveur. Un identifiant cohérent ne prouve ni la réception, ni la décision de bail, ni l’application de la configuration.

Le premier renouvellement échoue après une panne du relais. Le client possède encore un bail valable et envoie son DHCPREQUEST à l’adresse conservée dans l’option 54. Cette adresse répondait hier ; aujourd’hui, elle ne mène plus au serveur. Le défaut n’est pas une contradiction du protocole. Le relais faisait volontairement partie du chemin de renouvellement.

Dans le DHCPv4 ordinaire, un relais enrichit facilement le DHCPDISCOVER avec l’option Relay Agent Information. Le serveur peut alors connaître le Circuit-ID, le Remote-ID ou une classe d’équipement. Une fois le bail accordé, le client en état RENEWING envoie normalement son DHCPREQUEST directement à l’adresse indiquée par Server Identifier. Le relais peut disparaître de la conversation et le serveur perd le contexte d’accès fourni au départ.

Le RFC 5107 crée une indirection. Le relais insère le sous-option Server Identifier Override, code 11, longueur quatre, contenant une adresse IPv4. Un serveur compatible doit reprendre cette adresse dans l’option 54 de sa réponse. Le prochain renouvellement revient ainsi vers le relais, qui peut ajouter des informations actuelles avant d’acheminer la requête au serveur effectif.

Le mot « serveur » devient donc trompeur si l’on retire la provenance. L’adresse vue par le client peut appartenir au chemin du relais et ne correspondre à aucune interface du serveur qui tient le bail. Elle est une destination de retour. L’autorité qui décide du bail, l’intermédiaire qui transporte la demande et l’adresse que le client contacte sont trois objets distincts.

Le serveur doit mémoriser l’adresse de remplacement pour les messages suivants du même client, jusqu’à ce qu’un nouveau message arrive du relais. Ce souvenir forme un état auxiliaire. Il faut lui associer une génération, le relais émetteur, le client ou le bail concerné, l’heure d’apprentissage et la raison de son remplacement. Une valeur courante sans histoire ne suffit pas.

Un serveur qui ne comprend pas le sous-option l’ignore et met sa propre adresse d’interface dans l’option 54. L’attribution initiale peut tout de même réussir. La divergence apparaît plus tard : le renouvellement contourne le relais, les informations d’attachement manquent et une politique qui les attend peut réagir autrement. Le succès du DHCPACK initial ne prouve donc pas que le chemin de renouvellement prévu existe.

Dans un parc mixte, deux serveurs peuvent se comporter différemment face au même relais. Une moyenne de disponibilité masque cette différence. L’observabilité doit conserver, par instance, le sous-option reçu, la valeur effectivement renvoyée et le trajet observé lors du RENEW. Sans cela, l’incident sera classé comme instabilité du client au lieu d’incompatibilité fonctionnelle.

Le traitement du DHCPREQUEST montre précisément la portée de l’égalité. D’ordinaire, le serveur vérifie que l’option 54 correspond à l’une de ses interfaces. En présence du remplacement, il compare l’option 54 avec le sous-option 11. Si elles sont égales, il devrait traiter la demande même si l’adresse n’est pas locale.

Cette comparaison valide une cohérence transactionnelle, pas une identité. Elle ne dit pas qui a créé les champs, si le relais est autorisé, si le client a reçu une réponse authentique ni si l’adresse appartient au serveur. Un tableau de bord qui transforme option54 = override en « serveur vérifié » fabrique une preuve que le protocole ne fournit pas.

Le champ giaddr continue d’être renseigné normalement. Le remplacement ne remplace ni le contexte d’allocation lié au relais ni les sous-options décrivant l’accès. Circuit-ID, Remote-ID, drapeau broadcast/unicast et adresse de retour répondent à des questions différentes. Leur fusion dans une chaîne « relay metadata » rend toute enquête ambiguë.

Lorsque le relais envoie vers plusieurs serveurs, il devrait transmettre tous les messages, renouvellements compris, à chacun d’eux. L’objectif est de ne pas faire du relais une base de baux cachée. Il transporte la preuve actuelle ; les serveurs confrontent cette preuve à leur état.

La chaîne de reçus doit donc conserver le fan-out. Un événement indique la réception du client par le relais. D’autres indiquent chaque envoi vers un serveur et chaque réception confirmée. Une décision de renouvellement identifie ensuite l’autorité qui a répondu. L’absence de réponse d’un serveur non propriétaire n’est pas une perte de paquet, et la réponse d’un serveur ne prouve pas que tous ont reçu la demande.

Le RFC 5010 permet de transporter le fait que le message original était diffusé ou unicast. Le RFC 5107 recommande ce sous-option de drapeaux avec le remplacement. Le serveur ne peut pas déduire fidèlement le mode d’origine à partir de la connexion relayée qu’il observe après transformation.

L’indirection transforme la disponibilité du relais en condition de continuité. Si le client ne peut plus joindre l’adresse de remplacement, le renouvellement n’atteint jamais le relais. Si le relais ne peut plus joindre le serveur, la première moitié réussit et la seconde échoue. Dans les deux cas, l’option 54 peut rester parfaitement formée pendant que le bail expire.

Une mesure exploitable suit dix étapes : message client reçu, adresse de remplacement choisie, sous-options ajoutés, message reçu par le serveur, valeur mémorisée, réponse reçue par le client, renouvellement reçu par le relais, fan-out effectué, décision de bail reçue, configuration appliquée. Le premier trafic utile constitue encore un reçu séparé.

Les redémarrages doivent être testés comme changements de génération. Le serveur peut conserver le bail mais perdre l’adresse auxiliaire. Le client conserve alors une option 54 que le serveur ne reconnaît plus dans ce contexte. Le bon diagnostic est override_state_lost, pas « faux serveur » ni « client invalide ».

De même, une migration de relais peut conserver la même autorité de bail tout en changeant l’adresse de retour. Une adresse anycast peut rester stable alors que l’ensemble de serveurs évolue. L’identité de l’instance, la destination du client et l’autorité de décision doivent être versionnées séparément.

La sécurité dépend de la confiance entre relais et serveur. Un relais malveillant peut fournir sa propre adresse, attirer les renouvellements, les bloquer ensuite, modifier les options d’un DHCPACK ou présenter une durée différente. Le RFC 5107 ne transforme pas le sous-option en contrôle de sécurité ; il recommande l’authentification DHCP et l’authentification de Relay Agent Information lorsque cela est possible.

La preuve doit préciser le principal et les champs protégés. Authentifier le relais auprès du serveur n’équivaut pas à authentifier le serveur auprès du client. Protéger le message DHCP ne prouve pas que le client a appliqué la configuration. Une case « DHCP authentifié » gomme ces frontières.

Après le DHCPACK, il reste encore l’installation de l’adresse, du masque, de la route et des autres options. Une configuration installée ne prouve pas un paquet protégé, une résolution DNS ou un service utilisable. La métrique de direction doit montrer la conversion entre les étapes, pas seulement le nombre de baux renouvelés.

Le RFC 5107 est bref, mais il oblige l’opérateur à abandonner un raccourci sémantique. Une adresse appelée Server Identifier peut volontairement désigner la porte d’entrée d’un relais. La clarté consiste à conserver l’indirection, plutôt qu’à rebaptiser ce pointeur comme identité du serveur.

Sources