Un compte VPN sur deux serveurs : trois registres d’état

Un compte qui peut se connecter à l’un ou l’autre de deux nœuds VPN soulève une question de conception bien avant de soulever une question logicielle. La vue du compte, le réseau que possède chaque nœud et la session qu’un client connecté détient sont trois types d’état différents, et ils échouent de manières différentes quand on les copie d’un endroit à l’autre. Copier les trois dans un seul système est une façon courante d’en perdre un.

Parcourez les trois registres ci-dessous dans l’ordre. Chacun demande ce qui fait autorité, ce qui est local et ce qui se passe quand l’autre nœud est absent, et les réponses ne découlent pas les unes des autres.

Qui peut se connecter : une autorité, plusieurs nœuds

Commencez par le registre d’admission : quelle source d’identité fait autorité, quels émetteurs de certificats sont approuvés, quels comptes sont éligibles, quel second facteur s’applique et à quoi chaque compte peut accéder. Notez ensuite comment chaque nœud apprend les changements, et à quelle vitesse.

Une base de données partagée est une composante possible de cette réponse. Ce n’est pas la preuve que toute politique pertinente y réside, ni que chaque nœud applique un changement au même instant. Un compte désactivé sur le nœud A mais toujours accepté sur le nœud B signifie que le processus de sortie n’est pas terminé.

Décidez ce que fait un nœud quand l’autorité est injoignable. Accepter des identifiants en cache pendant une panne est un choix de politique avec un coût de sécurité, et les refuser est un choix de politique avec un coût de disponibilité. Les deux se défendent ; le laisser non documenté, non.

Gardez l’autorité de l’émetteur séparée des données du compte. Plusieurs passerelles peuvent faire confiance à la même AC sans détenir sa clé de signature, et chaque nœud a toujours besoin de son propre certificat serveur et de sa propre relation de confiance côté client.

Ce que possède un nœud : adresses et routes

Le deuxième registre est local à chaque nœud : adresse d’écoute, identité du serveur, pool d’adresses, routes vers les ressources privées, politique du résolveur et la manière dont le trafic sort vers internet. Le même compte peut être servi par l’un ou l’autre nœud tandis que ces objets restent distincts.

Le chemin de retour est la partie qu’on oublie. Si les deux nœuds distribuent des adresses du même pool, le réseau privé ne peut pas dire à quel nœud appartient un client donné, et la réponse peut partir au mauvais endroit. Des pools différents demandent aussi des routes et des permissions, donc une plage de numéros distincte n’est pas une conception complète.

Dirigez les clients vers un nœud délibérément. La sélection DNS, les listes de points de terminaison des clients et un service de frontal sont des mécanismes différents avec des comportements de santé et de basculement différents. En choisir un est très bien ; traiter l’« équilibrage de charge » comme la conception laisse le chemin de retour et le comportement en cas de panne indéfinis.

Un exemple de produit documenté aide ici. La documentation de réplication de Pritunl traite le réseau VPN comme un objet par réplica, et les clients de réplicas différents ont besoin de routes et de connectivité supplémentaires pour se joindre. C’est un agencement propre au produit, pas une recette pour Community OpenVPN, mais il montre pourquoi ajouter un réplica change le réseau et pas seulement le magasin de comptes.

Ce qu’est une session : un état vivant, pas une ligne

Le troisième registre est la session active. Un client connecté a un état de protocole et une affectation réseau sur le nœud qui l’a accepté. Le fait que le compte soit connu sur l’autre nœud ne donne pas à ce nœud la session, les clés ni la capacité de poursuivre les paquets.

Soyez explicite sur ce qui se passe quand un nœud tombe. Le résultat pris en charge peut être une reconnexion à l’autre nœud avec une authentification fraîche et une nouvelle adresse, après quoi l’application se rétablit à sa manière. Si un transfert sans interruption est exigé, cette exigence demande un support explicite dans l’implémentation, pas une déduction issue de la réplication de la base de données. Écrivez la réponse là où l’ingénieur d’astreinte peut la trouver.

Les règles de capacité demandent le même traitement. Une limite de deux sessions simultanées par compte ne peut être appliquée entre nœuds que si une autorité dispose d’une vue coordonnée des places occupées. Des listes locales à chaque nœud et un historique de compte ne forment pas cette vue.

Éprouver les trois registres

Exercez chacun séparément. Connectez-vous via le nœud A, puis via le nœud B, et confirmez que les deux réussissent avec les plages d’adresses attendues. Retirez une identité et vérifiez les deux nœuds, pas seulement celui que vous avez testé par hasard. Puis arrêtez un nœud et observez ce que font réellement le client et l’application privée.

Incluez le chemin de retour dans le test d’acceptation. Un client qui se connecte à B mais ne peut pas recevoir de réponses d’une ressource derrière A a réussi le contrôle d’admission et échoué à celui du réseau, et cette distinction devrait apparaître dans le rapport.

La conception d’un compte multi-nœuds n’est complète que lorsque les trois registres ont un propriétaire explicite, un chemin de changement et un comportement en cas de panne. Copier un fichier de configuration entre nœuds ne répond à aucune de ces questions.