Faire passer OpenVPN de TAP à TUN : un ordre de migration qui fonctionne

Remplacer dev tap par dev tun change ce que le tunnel transporte, pas seulement son nom. Une interface TAP remet des trames Ethernet à un pont, si bien que les clients se comportent comme s'ils étaient branchés sur le commutateur du bureau. Une interface TUN transporte des paquets IP, si bien que les clients ont besoin de routes et que l'autre côté a besoin d'un chemin de retour. Les clients, le plan d'adressage et la route de retour du réseau local doivent tous suivre ce changement.

La migration est une refonte du réseau avec un tunnel attaché, et l'ordre ci-dessous la garde réversible.

Inventoriez ce qui dépend réellement d'Ethernet

Listez les applications, pas les hôtes. Déterminez si chacune utilise des services TCP ou UDP routés, la découverte par diffusion, le DHCP du réseau local du bureau, un protocole Ethernet non IP, ou la supposition que les deux extrémités sont dans le même sous-réseau. L'accès IP ordinaire survit à une conception routée. Un protocole qui a besoin de trames Ethernet brutes non, et aucun routage ne le fera fonctionner. Les applications dépendantes de la découverte ont besoin d'un mécanisme de remplacement décidé avant le basculement, pas pendant.

Cet inventaire est aussi la liste d'acceptation. Chaque entrée que vous ne pouvez pas migrer devient une exception documentée ou une raison de garder un petit segment TAP vivant pour cette charge seule.

Construisez le plan d'adressage et de routes de retour

Choisissez un préfixe client qui ne chevauche pas le réseau local, l'ancienne plage du pont ni aucun réseau qu'un client atteint déjà.dev tun, topology subnet et server 10.78.0.0 255.255.255.0, mais c'est un fragment, pas un profil qui fonctionne. Gardez autour la politique approuvée de TLS, d'identité, de transport et d'accès, et utilisez un préfixe que vous avez vérifié comme libre.

Notez ensuite les destinations que les clients doivent atteindre et qui fournit le chemin de retour. Le serveur a besoin du transfert activé et d'un chemin autorisé vers l'avant. Les routeurs du réseau local ont besoin d'une route vers le nouveau préfixe, ou la conception a besoin d'une traduction de source avec le coût de visibilité que cela implique. Une route poussée vers la configuration du client configure le client, pas le chemin de réponse du réseau local.

Pilotez sur un écouteur séparé

Montez le nouveau service à côté de l'ancien, sur son propre port et sa propre plage d'adresses, plutôt que de remplacer le seul point d'entrée qui fonctionne. Émettez les profils pilotes via le processus d'inscription existant pour que personne ne reconstruise l'autorité de certification pour une migration. Connectez un client représentatif avec seulement le chemin pilote actif, puis comparez les adresses attribuées, le DNS privé, les applications de l'inventaire et les chemins qui doivent rester bloqués.

Incluez un test de reconnexion et de trafic de retour. Une poignée de main qui aboutit ne dit rien sur la capacité de l'autre côté à répondre.

Déplacez les clients par groupes avec un retour arrière

Migrez par groupes assez petits pour qu'une panne soit une tâche de support et non une interruption. Gardez l'ancien service en marche et documenté jusqu'à ce que les flux de travail réels de chaque groupe passent, et écrivez le retour arrière comme un retour au profil précédent, pas comme une reconstruction. Mettez à jour les règles de pare-feu basées sur les adresses, la supervision et tout accès initié par le serveur pour le nouveau préfixe à mesure que chaque groupe se déplace.

Les groupes vous donnent aussi un endroit pour découvrir l'application que personne n'a mentionnée, tandis que l'ancien chemin existe encore pour comparer.

Ne retirez le pont qu'après l'acceptation

Retirer l'équipement TAP est la dernière étape, pas la première. Vérifiez si le pont porte encore l'adresse de gestion du serveur, un chemin de supervision ou une charge sans rapport avant de supprimer quoi que ce soit. Retirez les dépendances de démarrage, l'appartenance au pont et les réservations DHCP par leurs propriétaires, dans cet ordre, avec une note de ce qui a été enlevé.

La migration est terminée quand le modèle d'accès routé fonctionne pour l'inventaire, pas quand une interface TAP disparaît de la sortie de ip link.