Déplacer une machine du VPN vers l’atelier sans la perdre

Une machine quitte un site client, arrive dans un atelier et conserve la même identité d’actif alors que son emplacement réseau change complètement. Trois conditions décident de la planification que ce déplacement exige. Que le client réutilise ou non des adresses que vous utilisez aussi en interne, que le segment de l’atelier soit isolé des réseaux du personnel, et que l’ancien chemin puisse être supprimé plutôt que simplement surpassé. Trompez-vous sur la première et vous débaguerez une machine qui va bien.

L’identité n’est pas une adresse

L’inventaire et le nommage doivent porter l’actif, le client et le travail. L’adresse porte où la machine est rattachée en ce moment, un fait qui change lorsqu’elle se déplace. Confondre les deux produit l’erreur classique de lire un sens dans les chiffres.

Un numéro de série encodé dans le dernier octet semble propre et ne prouve rien à un routeur. Les longueurs de préfixe décident de ce qu’un hôte considère comme local, et aucune numérotation mémorable ne change cette arithmétique.

Si vous voulez que l’adresse suggère le client, c’est une convention, et les conventions vont bien tant que personne ne construit de politique dessus. Cherchez l’actif dans l’inventaire, pas l’adresse, et le déplacement vers l’atelier cesse d’être une chasse au trésor. Il survit aussi à la renumérotation qui finit par arriver sur chaque site.

Un numéro de série n’est pas une longueur de préfixe

Les appareils qui utilisent un masque large comme 10.0.0.0/8 traitent toutes les adresses de cette plage comme directement liées, si bien que le trafic vers la machine d’un client située deux réseaux plus loin n’atteint jamais un routeur. La machine diffuse simplement pour chercher un voisin qui ne peut pas répondre.

RFC 4632 définit les préfixes par la longueur et non par ce que suggèrent les chiffres pointés. Votre plan a besoin de longueurs explicites pour chaque groupe de rattachement : un segment de service, un contexte client, un établi d’atelier. Nommer d’abord ces groupes rend les longueurs évidentes.

La règle pratique est de concevoir le plus petit préfixe qui couvre un groupe de rattachement et de l’utiliser partout dans ce groupe. Le texte de l’adresse est pour les humains ; le masque est ce sur quoi agit le noyau.

Quand deux clients réutilisent les mêmes adresses

Le client A et le client B peuvent tous deux exploiter 192.168.10.0/24, et tous deux auront raison dans leurs propres bâtiments. Ce n’est pas un problème à résoudre en renumérotant l’installation de quelqu’un d’autre.

Gardez les contextes séparés, ou fournissez des alias délibérés via une conception qui documente quelle adresse appartient à quel client à quel moment. Un inventaire global est le bon outil pour distinguer les machines ; ce n’est pas la preuve que les adresses sont uniques à l’échelle mondiale. Le chemin d’alias a besoin d’une règle d’expiration écrite, sinon il survit au travail qui l’a créé.

Ce qu’il faut éviter, c’est d’avoir les deux contextes accessibles en même temps sans aucun marqueur. Deux adresses identiques sur deux chemins actifs, c’est le mode de défaillance qui envoie une mise à jour de firmware à la mauvaise machine. Le symptôme ressemble rarement à une erreur ; il ressemble à un appareil que quelqu’un d’autre a reconfiguré. D’abord le marqueur, ensuite l’accessibilité.

Donnez à l’atelier sa propre frontière

L’équipement client qui arrive pour maintenance appartient à un segment de service avec un accès autorisé explicitement, et non branché sur un réseau du personnel parce qu’un port de l’établi était libre.

Traitez un appareil industriel inconnu comme un autre domaine de confiance. Notez quel hôte d’ingénierie peut l’atteindre, quels services cet hôte nécessite et quels identifiants appartiennent au travail. Conservez les fichiers du client avec le travail du client plutôt que sur un disque partagé que tout le monde peut lire.

L’isolement doit aussi survivre au milieu ennuyeux du travail : pendant la mise à jour, pendant la nuit et pendant l’attente d’un coursier.

Transférez la route comme une étape de travail

Normalement, le routeur central atteint la machine par le tunnel du client. Quand la machine est sur l’établi, le chemin de l’atelier devient propriétaire de ce préfixe, ou d’une destination plus étroite si vous n’avez besoin que d’un service.

Notez trois choses avant le déplacement : l’ancien chemin, le nouveau chemin et comment le changement est annulé. Un transfert qui n’existe que dans la mémoire de quelqu’un n’est pas un transfert.

Attention aux métriques. Une métrique plus basse ne compte que parmi les routes que le processus de sélection compare réellement, et un préfixe plus spécifique ou une règle de politique peuvent décider du résultat avant même que les métriques soient consultées.

Incluez les sessions obsolètes dans le plan. Une connexion établie sur l’ancien chemin peut continuer à livrer des commandes après le changement de route, et c’est exactement la situation où deux copies d’une adresse font de vrais dégâts. Fermez l’ancien chemin explicitement au lieu d’attendre son expiration.

Bouclez la boucle quand la machine est expédiée

Rétablissez la route distante prévue, retirez les autorisations temporaires et confirmez l’actif au point de terminaison que vous croyez sélectionné. Vérifiez ensuite du côté du client et pas seulement depuis l’atelier.

La résolution de noms et l’inventaire font ici le travail orienté opérateur : un nom stable et un enregistrement d’actif interrogeable rendent la tâche prévisible tandis que le plan réseau reste honnête sur l’endroit où se trouve la machine aujourd’hui.

Le test d’un bon transfert est qu’un collègue qui n’a jamais vu le travail puisse lire vos notes et répondre à une question : si cette machine répond maintenant, par quel chemin la réponse est-elle arrivée ? Si les notes ne peuvent pas y répondre, le transfert est documenté mais pas terminé.