Restreindre les connexions OpenVPN à un seul groupe avec une stratégie PAM

Laissez chaque compte se connecter normalement, mais n’autorisez qu’un seul groupe à utiliser le VPN. PAM peut exprimer cette différence sans second magasin de mots de passe, et le plugin OpenVPN peut être pointé vers un service qui ne contient que les contrôles voulus. L’astuce consiste à construire ce service sans hériter accidentellement d’une pile à l’échelle du système.

La visite commence par le nom de service du plugin, construit une stratégie, puis teste les trois issues qui comptent : un membre, un externe avec un mot de passe valide et un identifiant incorrect.

Pourquoi un service PAM séparé

Le plugin auth-pam prend un nom de service comme argument. Ce nom sélectionne un fichier sous /etc/pam.d, et la pile de ce fichier est ce qui s’exécute lors d’une connexion VPN. Si vous passez le même nom qu’une connexion à l’échelle du système, vous héritez de chaque décision de cette pile, y compris celles ajoutées plus tard pour des raisons sans rapport.

Créez plutôt un service dédié. Partez d’une pile fonctionnelle qui authentifie déjà auprès du backend prévu, comme un fichier de mots de passe local, SSSD ou un service d’annuaire, puis ajoutez la règle d’éligibilité. Copier deux lignes dans un fichier vide est l’erreur courante : l’expiration du mot de passe, le verrouillage du compte et d’autres contrôles peuvent vivre dans la pile que vous n’avez pas copiée.

Séparer le service limite aussi les dégâts. Une règle réservée au VPN dans une pile partagée peut refuser l’accès SSH ou console à tout le monde, ce qui transforme un changement d’accès en panne.

Écrire la règle de groupe

Le contrôle d’éligibilité relève de la phase de compte, après vérification de l’identifiant. Une règle telle que account required pam_succeed_if.so user ingroup vpnusers ne laisse le traitement se poursuivre que si l’utilisateur authentifié est membre de ce groupe.

Cette ligne est un fragment, pas un service complet. Intégrez-la là où chaque chemin accepté la rencontre, et vérifiez les indicateurs de contrôle autour d’elle. Un contrôle sufficient ou un saut plus haut dans la pile peut terminer le traitement avant que votre règle ne s’exécute, ce qui transforme la restriction en suggestion.

N’ajoutez pas use_uid par habitude. Sans lui, le module évalue l’utilisateur en cours d’authentification ; avec lui, le module évalue le compte sous lequel le processus OpenVPN s’exécute, qui est normalement root ou un compte de service et donc pas la personne qui se connecte.

L’appartenance au groupe vient de la résolution d’identité du système, pas d’un nom que vous reconnaissez. Pour les utilisateurs d’annuaire, confirmez que le même backend répond aux requêtes de groupe pour cet utilisateur, car un groupe local au nom familier est un objet différent du groupe d’annuaire du même nom.

Pièges d’ordre et d’identité

Placez la règle de groupe après la pile d’authentification et après tout contrôle qui doit encore s’appliquer, mais avant ou à côté des contrôles de compte que vous conservez. PAM évalue les modules dans l’ordre du fichier, et la valeur de contrôle de chaque ligne décide si un échec est définitif.

Attention aux piles dupliquées. Un schéma courant est une inclusion qui contient déjà une règle de compte, suivie de votre propre règle de groupe, ce qui produit deux décisions là où vous en attendiez une. Lisez le fichier inclus, pas seulement celui que vous avez modifié. Un moyen rapide de voir l’ordre effectif est de lire le fichier de haut en bas et de noter chaque valeur de contrôle.

Gardez intactes les autres conditions d’admission. Un mot de passe correct ne remplace pas les contrôles de certificat, un second facteur ni l’autorisation après connexion, et cette stratégie ne se substitue à aucune d’elles. Elle décide seulement si le compte est éligible à être examiné pour l’accès VPN.

Tester les membres, les externes et les mots de passe erronés

Testez trois cas avant de considérer la stratégie terminée. Un membre se connecte correctement. Un compte valide hors du groupe authentifie son mot de passe mais se voit refuser l’accès VPN. Un mot de passe erroné pour l’un ou l’autre compte est rejeté à l’étape d’authentification, pas par la règle de groupe.

Regardez l’erreur visible côté client et le journal du serveur ensemble, car les deux échecs peuvent sembler identiques à la personne qui se connecte. La distinction compte pour le support : un externe avec le bon mot de passe a besoin d’un changement de groupe, tandis qu’un mot de passe erroné nécessite une réinitialisation de l’identifiant.

Gardez une seconde session ouverte pendant que vous modifiez PAM, et vérifiez aussi la connexion SSH ordinaire après le changement. L’intérêt du service dédié est que la connexion système doit rester intacte, et la seule façon de le savoir est de le tester.

Si quelque chose casse, restaurez le fichier de service précédent à partir d’une copie. La règle voulue est simple à énoncer : l’appartenance rend un compte éligible à l’accès VPN, et tout autre contrôle requis s’applique toujours.