Access Server a perdu son association après le renommage d’une interface réseau : corrigez les clés

Vous avez renommé une interface réseau, ou restauré une machine dont l’adaptateur est revenu sous un autre nom, et désormais le démon OpenVPN Access Server ne démarre plus. L’interface web répond peut-être encore, ou pas, selon le composant lié à l’ancien nom. Le service n’est pas corrompu et la configuration n’est pas perdue ; un réglage pointe encore vers une interface que l’hôte ne possède plus.

Le réflexe est de réinstaller, de réinitialiser ou de modifier la base de données jusqu’à ce que l’erreur disparaisse. Chacune est un changement plus lourd que la panne, et la dernière peut effacer les utilisateurs, permissions et dépendances qui rendaient le serveur digne d’être récupéré. C’est un problème d’association, et il a une correction nommée.

Ce que le symptôme dit vraiment

Un démon qui ne peut pas s’associer l’indique en général dans son journal : l’adresse n’est pas disponible ou l’interface n’existe pas. Le message est précis : il nomme l’adresse essayée ; comparez-la à ip -br addr sur l’hôte pour savoir si l’interface a été renommée, supprimée ou relevée sans son ancienne adresse.

Gardez une console de récupération autorisée ouverte en permanence. Si l’association que vous allez changer porte votre unique session d’administration, vous avez coupé votre retour. Une console locale, une seconde adresse de gestion ou un chemin hors bande documenté rendent le changement réversible.

Interrogez la configuration avant de la modifier

Access Server expose sa configuration via sa propre CLI. La vue documentée est :

sacli ConfigQuery

Exécutez-la dans l’environnement administratif documenté pour votre version, pas depuis un shell étranger sur un autre hôte. Conservez les valeurs actuelles dans un endroit protégé avant toute modification et ne collez pas la sortie complète dans un fil d’assistance public.

Cette sortie est une vue de la configuration du serveur, pas une sauvegarde complète. Les propriétés des utilisateurs et des groupes sont interrogées séparément : une association propre ne restaure pas les identités, et une identité restaurée ne répare pas un écouteur. Enregistrez les deux comme deux artefacts distincts.

Déterminez quel écouteur est cassé

Access Server exécute plusieurs écouteurs. Les démons OpenVPN portent le trafic du tunnel, le service web porte le portail d’administration et client, et d’autres composants peuvent avoir leurs propres ports. Une requête de navigateur en échec ne dit pas lequel a échoué, pas plus que le numéro de port du message d’erreur.

Les clés d’association du démon sont documentées par démon, et dans le tutoriel officiel la valeur est l’identifiant de l’interface, même si les noms de clés finissent par ip_address. Lisez cette phrase deux fois. Le tutoriel attend aussi que les démons UDP et TCP partagent une interface : corriger une seule clé est donc une réparation partielle.

Changez le réglage nommé, pas les lignes correspondantes

Le tutoriel documente ConfigPut sur des clés précises, comme vpn.daemon.0.server.ip_address et vpn.daemon.0.listen.ip_address. Utilisez la méthode propre au produit avec le nom de la clé et la nouvelle valeur, dans la syntaxe documentée pour votre version, et ne changez que les clés de l’écouteur diagnostiqué.

Ce qu’il ne faut pas faire, c’est chercher dans la base toutes les lignes dont la valeur est l’ancien nom d’interface et les remplacer toutes. Cela suppose que l’ancien nom n’apparaissait que dans les réglages d’écouteur, ce que le schéma ne promet pas. Cela rend aussi le changement impossible à relire.

Deux autres tentations sont à refuser. Restaurer un défaut qui écoute sur toutes les interfaces est une décision d’exposition, pas une correction orthographique ; l’association locale prévue, le chemin publié et le filtrage en amont doivent s’accorder avec ce choix. Réinitialiser la configuration renomme le problème au lieu de le résoudre, car une installation neuve écarte précisément les utilisateurs et permissions qui fonctionnaient avant le renommage.

Appliquez, puis prouvez que le chemin fonctionne

Une fois la valeur corrigée, appliquez-la via le cycle de vie documenté du produit ( cycle de vie ). Le tutoriel utilise sacli start après avoir défini les clés ; ce n’est ni un redémarrage complet de l’hôte ni une remise à zéro de la base.

ss -lntup | grep -E '1194|443'
sacli ConfigQuery | grep -i ip_address

Vérifiez l’écouteur, établissez une connexion VPN autorisée, atteignez une ressource privée et chargez la page d’administration par son chemin attendu. Conservez les permissions et révocations existantes ; une récupération qui les réinitialise a corrigé l’association et perdu le déploiement. Le travail est terminé quand le même service fonctionne sur son interface prévue.