Portable nomade : nom stable ou adresse de bureau fixe ?

Vous ouvrez la console d’administration depuis chez vous, recherchez le portable par son nom et obtenez une adresse devenue invalide dès qu’il a quitté le bureau. Le réflexe est de reporter l’adresse du bureau sur l’adaptateur VPN pour que tout continue de fonctionner. Ce correctif casse généralement autre chose, car trouver un appareil, autoriser son trafic et maintenir une session en vie sont trois problèmes différents. Séparez-les avant de choisir une conception d’adresses.

Séparez les trois exigences

Notez laquelle des trois échoue réellement. Une personne ou un outil ne trouve pas le service ; un serveur refuse des requêtes parce que l’adresse source n’est pas sur une liste ; ou une application tombe quand l’interface change. Sur un tableur, elles se ressemblent et demandent des correctifs différents.

La plupart des plaintes d’itinérance atterrissent dans le premier panier et se règlent dans le DNS. Nommer une identité stable est bon marché et couvre le premier cas. Préserver l’adresse est coûteux et n’aide le second que si la politique est de toute façon réécrite.

Faites du nom la chose stable

Donnez au portable un nom qui se résout vers toute adresse joignable par l’appelant. Dans cet exemple, l’adresse du bureau est 192.168.50.42, le bassin d’accès distant distribue 10.90.0.42, et laptop17.corp.example suit le rattachement. Rien n’exige que le dernier octet corresponde, et concevoir autour de cette correspondance crée du travail sans bénéfice. L’enregistrement doit pointer vers l’adresse que l’appelant peut réellement utiliser, pas vers chaque interface qu’a eue le portable.

dig +short laptop17.corp.example

Les résolveurs mettent les réponses en cache, le changement n’est donc pas instantané pour tout le monde. Des TTL courts aident, et la logique de reconnexion de l’application aide davantage.

Quand une liste d’origines autorisées est la vraie contrainte

Une liste d’origines autorisées voit l’adresse que reçoit le service protégé, après toute traduction. C’est souvent une adresse de passerelle ou de NAT plutôt que celle du portable, et c’est pourquoi modifier les enregistrements DNS ne répare jamais une requête rejetée. Mettez la politique à jour pour l’adresse qui arrive réellement, ou remplacez la liste par une identité authentifiée.

Capturez une requête acceptée sur le serveur et lisez le champ source, puis répétez depuis le chemin distant. Si les deux adresses diffèrent, la politique a besoin de deux entrées ou d’un autre mécanisme. Notez les deux adresses avec l’entrée de politique pour que la personne suivante voie pourquoi il y en a deux. Réutiliser une adresse déjà active sur le même lien est un problème de conflit distinct, avec ses propres règles de détection.

Ce que la continuité exige vraiment

La continuité de connexion est l’exigence la plus difficile et la plus souvent mal lue. Une connexion TCP est identifiée par les deux adresses et les deux ports, donc une nouvelle adresse locale est une autre connexion, quoi que dise le DNS. Les applications qui comptent doivent se reconnecter, ce qui suppose une couche de session ou un client qui réessaie, pas une astuce réseau. Observez une session pendant le déplacement et la coupure est immédiate, pas progressive.

ss -tnp state established '( dport = :443 )'

Cloner une adresse MAC ne résout pas cela non plus. L’identité de bail DHCP peut utiliser un identifiant de client explicite, et deux interfaces partageant une identité ont toujours besoin de routes coordonnées. Traitez la mobilité comme une conception d’application et d’allocation, et gardez l’identité de l’appareil stable pendant que son adresse suit le réseau.