Route de l’appliance OpenVPN : propriétaire de la configuration ou script de démarrage ?
Une route de succursale qui survit à un redémarrage peut encore disparaître après un enregistrement dans l’interface ou une mise à jour du firmware. Comparez le propriétaire de configuration pris en charge à un script de correctifs.
Vous ajoutez une route de succursale, elle fonctionne, puis une mise à jour du firmware ou un enregistrement depuis l’interface web la supprime. Deux corrections semblent également raisonnables à ce moment-là : placer la route dans la source de configuration prise en charge de l’appliance, ou l’ajouter au fichier généré depuis un script de démarrage. Elles se comportent de la même façon pendant une semaine et divergent à la deuxième mise à niveau. Cet article compare ce que chacune possède réellement.
Les deux candidats possèdent des choses différentes
La source de configuration prise en charge est tout ce que l’appliance traite comme entrée : un champ de l’interface, un profil importé, un répertoire documenté par client, une base de données de réglages que lit le paquet de gestion. Le server.conf généré est une sortie. Modifier la sortie fonctionne jusqu’à ce que le générateur s’exécute à nouveau, ce qui arrive à l’enregistrement, au redémarrage et lors d’une mise à niveau.
L’approche par script corrige cette sortie après la fin du générateur. C’est une technique légitime pour un laboratoire, et c’est le mauvais choix par défaut pour un bureau de succursale, parce qu’elle rend la route dépendante d’une correspondance de texte plutôt que d’un champ documenté.
| Question | Supported config source | Post-generation script |
|---|---|---|
| Survives a GUI save | Yes | Only if the save does not regenerate the file |
| Survives a package upgrade | Usually, when the field is documented | No guarantee; the wrapper can be replaced |
| Supportable by the vendor | Yes | No |
| Obvious to the next admin | Yes, it is in the UI | No, it lives in a wrapper |
Ce que l’appliance régénère, et quand
Les paquets de gestion conservent généralement les réglages dans une base de données ou un jeu de modèles et génèrent la configuration du démon au démarrage. Un enregistrement depuis l’interface web réécrit souvent tout le fichier au lieu de corriger une ligne. Si votre modification vivait dans ce fichier, elle a maintenant disparu, et rien ne consigne d’avertissement, car du point de vue de l’appliance rien n’a été perdu.
Les enveloppes de démarrage ont un second mode de défaillance. Un grep portant sur une directive avec un espacement particulier cesse de correspondre après un changement de modèle, et le script ne fait silencieusement rien. Pire, une mise à jour du firmware peut remplacer l’enveloppe par une nouvelle version, emportant le correctif avec elle. Vous avez alors une route qui a existé un an et qui a disparu lors d’une maintenance que personne n’a reliée au routage.
Ce que le propriétaire pris en charge doit exprimer
Un préfixe de succursale exige trois énoncés, pas un. Le client doit apprendre la route, le serveur doit savoir quel client authentifié possède le préfixe, et le côté succursale doit renvoyer le trafic vers l’adresse de tunnel qui lui a été donnée. En termes OpenVPN, cela signifie un route poussé, un iroute correspondant lié au client, et un chemin de retour de l’autre côté.
C’est ici que les interfaces des appliances induisent en erreur. Une case à cocher intitulée « autoriser les clients à accéder au LAN du serveur » décrit le trafic vers le réseau propre du serveur. Votre succursale est la direction opposée : un réseau derrière un client, joignable depuis le côté serveur. La même étiquette n’implique pas la prise en charge de cela, et une directive valide dans un fichier n’est pas la promesse que le paquet la préservera.
Quand aucun contrôle pris en charge n’existe
Parfois, la version installée ne peut véritablement pas exprimer une route propre à un pair. Les options honnêtes sont alors une autre passerelle que vous contrôlez, ou un mode site à site pris en charge aux deux extrémités. Les deux extrémités doivent le parler. Une page produit qui dit site à site ne rend pas un profil OpenVPN quelconque interchangeable avec le tunnel d’un autre protocole, et forcer cet appariement produit généralement un tunnel à moitié connecté qui a l’air correct sur une page d’état.
Choisissez l’option que vous pouvez décrire en une phrase à celui qui héritera du réseau. Si la réponse exige de mentionner un chemin de script et un motif de texte, la conception est déjà fragile.
Rendez l’intention auditable
Consignez le contrat en dehors de l’appliance : identité effective du client, préfixe, passerelle de retour et champ pris en charge qui fournit chacun d’eux. Exportez la configuration par le mécanisme pris en charge pour qu’une reconstruction dispose d’une référence, et vérifiez le service après une reconnexion, un redémarrage et une mise à niveau plutôt qu’après le seul changement.
Comparez le résultat généré à cet enregistrement lorsqu’une chose casse, au lieu de restaurer une ligne inexpliquée en espérant.référence OpenVPN 2.6 est l’endroit où confirmer comment route et iroute interagissent avant de discuter avec une interface.
Liste de contrôle pour la prochaine modification : nommer le propriétaire, énoncer le contrat en trois parties, exporter l’intention, et retester après les propres événements de cycle de vie de l’appliance plutôt qu’après votre édition.