Résumé

  • keama peut convertir des constructions reconnues d’une configuration ISC DHCP en configuration JSON Kea, mais les constructions non prises en charge exigent une revue et des modifications manuelles.
  • Le modèle de service Kea, l’état des baux, la haute disponibilité, DHCP-DDNS, les hooks, le démarrage, la supervision et la reprise ne sont pas établis par la seule production d’un fichier JSON.

Le point décisif d’une migration n’est donc pas de savoir si un outil a produit un fichier, mais si l’équipe peut démontrer que le service se comporte correctement, conserve l’état pertinent et peut être rétabli lorsque l’une de ses dépendances échoue.

Le faux raccourci du fichier JSON

Une migration de serveur DHCP est souvent décrite comme une opération de conversion : prendre une configuration existante, la transformer et démarrer le nouveau logiciel. Cette description est utile pour parler de la première étape, mais elle devient trompeuse lorsqu’elle est utilisée pour décrire le résultat final. Un fichier converti peut représenter une partie des intentions de l’ancienne configuration sans représenter l’ensemble du service qui la faisait fonctionner.

La distinction est importante pour ISC DHCP vers Kea parce que l’outil de conversion se situe à un endroit précis de la chaîne. Il travaille sur des constructions de configuration qu’il reconnaît. La production d’un objet JSON est une preuve de traduction pour ces constructions, pas une preuve de continuité opérationnelle. Elle ne démontre pas à elle seule que les baux déjà attribués sont disponibles, que les deux partenaires d’une architecture redondante sont synchronisés, que les mises à jour DNS sont acceptées ou que les scripts et extensions ont le même effet.

Le risque n’est pas seulement une erreur de syntaxe. Une configuration peut être lisible par Kea tout en produisant un comportement différent de celui attendu par les clients, les relais, les systèmes DNS ou les outils d’exploitation. C’est pourquoi il faut traiter le fichier produit comme une entrée de travail dans une migration, et non comme le certificat que la migration est terminée.

Ce que keama convertit réellement

La documentation officielle de keama décrit un utilitaire en ligne de commande qui convertit une configuration ISC DHCP en configuration JSON Kea, avec des modes distincts pour DHCPv4 et DHCPv6. Cette description fixe une capacité utile et relativement étroite : automatiser la traduction de certaines constructions connues vers le modèle attendu par Kea.

La même documentation indique que la conversion est limitée par les constructions prises en charge. Les éléments non pris en charge ou non convertis doivent faire l’objet d’une revue et d’une modification manuelle du résultat généré. La matrice exacte dépend de la version de Kea installée. Il serait donc imprudent de parler d’une correspondance universelle entre toutes les directives ISC DHCP et leur équivalent Kea sans comparer la configuration réelle, la version du logiciel et les avertissements produits par l’outil.

Cette limite transforme la question de migration. Au lieu de demander seulement si keama fonctionne, l’équipe doit demander quelles parties de la configuration ont été reconnues, lesquelles ont été ignorées ou transformées différemment, et quelles décisions d’exploitation ne sont pas représentées dans le fichier. La réponse peut varier d’une version à l’autre et d’un déploiement à l’autre.

La documentation ne présente pas une conversion comme le déplacement automatique d’un déploiement ISC DHCP en cours d’exécution. Elle ne permet donc pas de conclure que l’état dynamique, les responsabilités de service, la topologie ou les procédures de reprise ont suivi le fichier. Le passage à Kea commence par une traduction, mais il se termine seulement lorsque le service cible est vérifié dans son environnement réel ou dans une reproduction suffisamment fidèle.

Le système cible n’est pas un simple nouveau format

La deuxième source de travail vient du fait que Kea possède son propre modèle de service. Pour DHCPv4, la documentation du serveur Kea DHCPv4 couvre notamment les paramètres globaux, les interfaces, les bases de données de baux, la journalisation, les sous-réseaux, les pools, les réservations, les options, les classes de clients et les hooks. Cette liste n’est pas une simple liste de noms à recopier : chaque élément doit être interprété dans le modèle natif de Kea et confronté au comportement recherché.

Une équipe peut ainsi obtenir un fichier qui contient des sous-réseaux et des pools sans avoir établi que le serveur écoute sur les bonnes interfaces, écrit ses baux au bon endroit, journalise les événements nécessaires ou applique les réservations comme prévu. Les options peuvent être présentes mais produire une réponse différente dans un chemin de relais ou pour une classe de clients donnée. La présence d’une clé dans le JSON est donc moins importante que la réponse observée par le client et par les systèmes qui l’entourent.

DHCPv6 ajoute une autre couche de vérification. Le modèle Kea pour DHCPv6 comprend des sous-réseaux IPv6, des pools, la délégation de préfixes, des options, des réservations, le stockage des baux et le fonctionnement avec des relais. Les paramètres qui ne disposent pas d’un équivalent direct nécessitent une nouvelle conception ou une vérification manuelle. Une conversion qui réussit pour les adresses IPv4 ne fournit donc pas une preuve de bon fonctionnement pour l’allocation IPv6, la délégation de préfixes ou le chemin de relais.

Cela suggère une méthode simple, mais exigeante : séparer la comparaison de configuration de la comparaison de comportement. La première vérifie les directives et leurs équivalents. La seconde vérifie des scénarios : découverte et renouvellement d’un bail, réservation d’un client, épuisement d’un pool, attribution IPv6, délégation de préfixe, redémarrage, perte d’une interface et reprise après panne. Ces scénarios ne sont pas des détails de recette ; ils sont la définition pratique de la continuité du service.

L’état opérationnel n’est pas visible dans la conversion

Une configuration décrit des règles souhaitées. Un service DHCP en production possède aussi un état : baux actifs, relations avec des partenaires, files d’événements, informations de journalisation, certificats ou identifiants nécessaires à des services associés, ainsi que les décisions prises par les opérateurs pendant un incident. La conversion d’un fichier ne suffit pas à démontrer que cet état existe dans le nouvel environnement.

Il faut donc traiter séparément la question des baux. Où sont-ils stockés ? Dans quel format ? Quelle est la procédure de reprise si la nouvelle instance démarre avec une base vide ou incomplète ? Quel comportement est attendu lorsqu’un client renouvelle un bail attribué avant la bascule ? Que se passe-t-il si l’ancien et le nouveau serveur répondent simultanément pendant une période de transition ? Les documents consultés établissent les responsabilités de configuration et de stockage du modèle Kea, mais ils ne donnent pas une garantie générale selon laquelle l’état d’un déploiement ISC DHCP serait transféré par la génération du JSON.

Le même raisonnement vaut pour le démarrage et la supervision. Les interfaces d’écoute, le stockage, la journalisation, le lancement du service, les permissions, la collecte de métriques et les alertes peuvent être indispensables au fonctionnement réel sans constituer une simple directive à convertir. Une migration qui valide le fichier mais pas le service de démarrage peut échouer au prochain redémarrage. Une migration qui valide le démarrage mais pas les alertes peut laisser une panne silencieuse se prolonger.

Il faut aussi documenter ce qui ne sera pas transféré. Une absence de correspondance n’est pas nécessairement un défaut du convertisseur : elle peut signaler qu’un élément relevait d’une autre couche du système, d’un script local ou d’une convention d’exploitation. La décision correcte consiste alors à identifier le remplacement, à le tester et à inscrire son propriétaire dans le runbook. L’inconnu non attribué est le risque le plus facile à oublier au moment où la bascule paraît réussie.

La haute disponibilité doit être reconstruite

La redondance est un test particulièrement net de la différence entre conversion et migration. La documentation Kea sur la haute disponibilité décrit une architecture fondée sur un hook High Availability et sur sa propre configuration, plutôt que sur la réutilisation directe de déclarations failover-peer d’ISC DHCP.

Le résultat pratique est que la présence de deux serveurs dans l’ancienne architecture ne prouve pas que la nouvelle architecture est redondante. Il faut définir la communication entre partenaires, les rôles ou les modes, le comportement de synchronisation et les réactions aux défaillances. Il faut ensuite vérifier ces comportements, notamment lorsque le lien entre partenaires disparaît, lorsqu’un serveur redémarre, lorsqu’un partenaire revient avec un état ancien ou lorsqu’une intervention doit restaurer le service.

Cette étape ne peut pas être remplacée par un contrôle de présence du hook dans le JSON. Un hook activé mais mal configuré est une extension installée, pas une preuve de haute disponibilité. La preuve utile est comportementale : chaque partenaire prend-il les décisions attendues ? La synchronisation converge-t-elle ? Les opérateurs savent-ils quel nœud peut être remis en service et dans quel ordre ? Les clients continuent-ils à obtenir des réponses pendant la défaillance testée ?

Le point est également organisationnel. Une architecture HA introduit des choix qui doivent avoir un propriétaire : version du protocole, rôles, seuils d’intervention, procédure de séparation et de réunification, conservation des journaux et critères de retour à la normale. Si ces choix sont laissés à l’interprétation pendant l’incident, la conversion a déplacé le logiciel sans déplacer la capacité de décision.

DNS-DDNS est un service séparé

Les mises à jour DNS constituent une autre frontière. La documentation Kea sur DHCP-DDNS et le service D2 décrit D2 comme un service séparé, doté de sa propre configuration et de son propre point de communication. Les règles de mise à jour DNS, les identifiants, les zones, la connectivité et la vérification des mises à jour directes et inverses doivent donc être configurés et testés séparément.

Une ancienne configuration peut contenir des paramètres qui expriment une intention de mise à jour DNS sans produire automatiquement une instance D2 prête à fonctionner. Il faut savoir quel composant reçoit les événements de bail, comment il les transmet, quelles zones il est autorisé à modifier et comment les erreurs sont signalées. Il faut également vérifier le résultat visible dans les zones concernées, pas seulement l’absence d’erreur dans le journal du serveur DHCP.

La vérification doit couvrir au minimum la création, le renouvellement et la libération d’un bail, ainsi que la cohérence des enregistrements directs et inverses. Elle doit aussi prévoir le cas où D2 est indisponible puis revient, afin de déterminer si les mises à jour sont perdues, retardées ou rejouées. Ces questions relèvent de la continuité du service DNS associé ; elles ne sont pas résolues par le fait que le serveur DHCP accepte sa configuration.

Les extensions déplacent le risque vers le code local

Les déploiements anciens contiennent souvent des comportements qui ne sont pas exprimés uniquement par des directives : scripts d’événements, contrôles d’accès, notifications, intégrations avec l’inventaire ou automatisations déclenchées par l’attribution d’un bail. La documentation Kea sur les bibliothèques de hooks présente les hooks comme un mécanisme d’extension de Kea. Un gestionnaire d’événement ou un script ISC DHCP qui n’a pas de correspondance directe dans keama peut demander une réimplémentation par un hook approprié ou par une intégration externe.

La migration doit alors inclure quatre vérifications distinctes : le code ou l’intégration existe-t-il encore, le mécanisme d’appel est-il le même, les permissions et paramètres sont-ils disponibles, et le résultat est-il identique dans les scénarios importants ? Activer une bibliothèque ne répond qu’à la deuxième partie de la question. Il faut aussi configurer ses paramètres et observer son comportement lorsqu’une opération réussit, échoue ou est répétée.

Cette frontière explique pourquoi le nombre de lignes converties est un mauvais indicateur de préparation. Une configuration courte peut dépendre d’un script critique. Une configuration volumineuse peut contenir surtout des règles mécaniques. Sans inventaire des extensions et de leurs propriétaires, l’équipe ne sait pas ce qui a réellement été migré.

Une migration doit être prouvée par des comportements

Une démarche robuste peut organiser le travail en plusieurs étapes.

D’abord, figer la version de Kea et établir la liste des constructions rencontrées dans la configuration source. La matrice de prise en charge doit être liée à cette version ; les éléments inconnus, ignorés ou signalés doivent être conservés dans une liste de travail, et non supprimés du récit de migration.

Ensuite, produire le JSON et le comparer au modèle natif de Kea. Pour DHCPv4, cela comprend les interfaces, les bases de baux, les sous-réseaux, les pools, les réservations, les options, les classes de clients, la journalisation et les hooks. Pour DHCPv6, cela comprend les sous-réseaux, les pools, les préfixes délégués, les réservations, le stockage et les relais. La comparaison doit expliquer chaque différence au lieu de considérer toute différence comme une erreur ou toute ressemblance comme une équivalence.

Troisièmement, reconstruire les services associés. La haute disponibilité doit être configurée et testée comme une architecture propre à Kea. D2 doit être déployé et vérifié comme un service distinct. Les extensions doivent être remplacées ou raccordées avec des paramètres et des permissions explicites. Les interfaces de démarrage, la supervision, la journalisation et les procédures d’escalade doivent être écrites dans le même plan.

Quatrièmement, tester les parcours normaux et les parcours de panne. Les parcours normaux incluent l’allocation, le renouvellement, la réservation et, lorsque c’est pertinent, la délégation de préfixes. Les parcours de panne incluent la perte d’un partenaire HA, la perte de D2, l’indisponibilité de la base de baux, le redémarrage du service, la perte d’une interface et le retour d’un composant après interruption. Chaque test doit avoir un résultat attendu, une trace observable et un responsable.

Enfin, définir la décision de bascule et la décision de retour arrière. Un fichier JSON qui se charge est un prérequis. Il ne peut pas être le seul critère de passage en production. La bascule doit dépendre d’un niveau de confiance établi par les tests et par la capacité à restaurer un état connu. Le retour arrière doit lui aussi préciser qui agit, avec quelles données de baux, quelles routes de trafic et quelles règles de mise à jour DNS.

Ce que cette frontière change pour l’adoption

L’intérêt de keama est réel : réduire les tâches répétitives peut accélérer l’évaluation d’une migration et libérer du temps pour les vérifications qui demandent une connaissance du réseau. Mais l’automatisation ne supprime pas le travail ; elle en déplace le centre de gravité. La traduction mécanique devient moins coûteuse, tandis que la validation sémantique, la reconstruction des services et la préparation à la panne deviennent plus visibles.

Ce déplacement est facile à sous-estimer dans une organisation qui mesure la progression par le nombre de fichiers générés ou par la réussite d’un démarrage initial. Ces mesures répondent à la question de l’installation, pas à celle de la continuité. La métrique utile est plutôt la couverture des comportements et des dépendances : combien de directives ont été classées, combien de scénarios ont été testés, combien de services associés ont un propriétaire et combien de chemins de reprise ont été exécutés.

Il faut également maintenir une frontière claire entre le rôle documenté d’ISC et les choix de chaque opérateur. Les documents publics décrivent l’outil et le modèle de Kea ; ils ne démontrent pas la réussite ou l’échec d’une migration particulière, ne donnent pas un taux universel de panne et ne fixent pas un calendrier identique pour tous les réseaux. La topologie locale, la version, les extensions et les procédures d’exploitation restent déterminantes.

La conclusion la plus solide est donc limitée mais utile. keama peut réduire l’effort de traduction de constructions reconnues. Il ne transforme pas automatiquement une configuration ISC DHCP en service Kea équivalent et récupérable. La migration est terminée lorsque l’équipe a reconstruit les éléments qui ne sont pas dans la conversion et qu’elle peut démontrer leur comportement, y compris lorsque le système est partiellement défaillant.