Formation — VPN d'entreprise avec authentification multifacteur

OpenVPN, FreeRADIUS et privacyIDEA sur Debian 13 — comprendre l'architecture, pas seulement l'installer

Ce document accompagne le guide d'installation technique : là où celui-ci donne les commandes à exécuter, celui-ci explique POURQUOI chaque brique existe, comment elle fonctionne, et comment elles s'articulent entre elles. L'objectif est de vous rendre autonome pour comprendre, dépanner, et faire évoluer cette infrastructure sans dépendre d'un copier-coller.

Plan de la formation

● Chapitre 1 — Vue d'ensemble : le problème à résoudre et les briques choisies

● Chapitre 2 — PKI et certificats : la confiance numérique

● Chapitre 3 — OpenVPN : le tunnel chiffré

● Chapitre 4 — Réseau et pare-feu : maîtriser les flux

● Chapitre 5 — PAM : le pont vers l'authentification externe

● Chapitre 6 — FreeRADIUS : le relais d'authentification centralisé

● Chapitre 7 — privacyIDEA : le cœur du MFA

● Chapitre 8 — Le flux d'authentification de bout en bout

● Chapitre 9 — Sécurisation avancée

● Chapitre 10 — Exploitation, maintenance et croissance

Chapitre 1

Vue d'ensemble : le problème à résoudre

Objectifs de ce chapitre • Comprendre pourquoi un simple mot de passe ne suffit plus pour un accès distant • Identifier le rôle de chacune des 5 briques de l'architecture • Visualiser comment elles s'articulent

 

Le besoin de départ est simple à énoncer : permettre à des utilisateurs de se connecter à distance au réseau de l'entreprise, de façon sûre. La difficulté est que « sûr » recouvre plusieurs exigences qui ne sont pas satisfaites par une seule technologie : chiffrer le trafic (personne ne doit pouvoir lire les données en transit), vérifier l'identité de la machine qui se connecte (certificat), et vérifier l'identité de la personne (mot de passe + un second facteur qu'elle seule possède).

Aucun outil ne fait tout ça seul. L'architecture mise en place assemble cinq briques, chacune spécialisée dans un rôle précis :

● OpenVPN : établit le tunnel chiffré et vérifie le certificat de la machine cliente

● PAM (Pluggable Authentication Modules) : le mécanisme standard Linux qui permet à OpenVPN de déléguer la vérification de l'identité à un système externe, sans avoir à en connaître les détails

● FreeRADIUS : le protocole et serveur standard de l'industrie pour centraliser des demandes d'authentification, ici utilisé comme relais

● privacyIDEA : le moteur qui gère réellement les utilisateurs, leurs mots de passe et leurs codes TOTP (l'application d'authentification sur le téléphone)

● MariaDB + Apache : la base de données et le serveur web qui font tourner privacyIDEA et son interface d'administration

Le principe directeur de toute cette architecture est la séparation des responsabilités : OpenVPN ne sait rien de la manière dont un mot de passe est vérifié, PAM ne sait rien de RADIUS au-delà du protocole, FreeRADIUS ne sait rien de ce qu'est un TOTP. Chaque brique fait un métier, et communique avec la suivante par un protocole standard. C'est ce qui permet de remplacer n'importe quelle brique plus tard (changer de moteur MFA, par exemple) sans toucher au reste.

À retenir Cette architecture n'est pas un empilement arbitraire de logiciels : chaque brique répond à un besoin précis (chiffrement, délégation, relais, gestion MFA), et communique avec la suivante par un protocole standard plutôt que par une intégration propriétaire. C'est ce qui la rend maintenable et remplaçable pièce par pièce.

Chapitre 2

PKI et certificats : la confiance numérique

Objectifs de ce chapitre • Comprendre ce qu'est une autorité de certification (CA) et pourquoi on en a besoin • Distinguer clé privée et certificat public • Savoir pourquoi le SAN est obligatoire et ce qu'est une révocation

 

Avant même de parler d'authentification utilisateur, OpenVPN doit vérifier qu'il parle à la bonne machine, et que le client parle au bon serveur. C'est le rôle de la PKI (Public Key Infrastructure) : un système de confiance basé sur des certificats numériques, tous signés par une autorité de certification (CA) que tout le monde reconnaît.

Le principe de la signature

Une CA possède une clé privée (ca.key) qu'elle ne partage jamais, et un certificat public (ca.crt) qu'elle distribue à tout le monde. Quand elle signe un certificat (celui du serveur OpenVPN, d'un client, ou d'Apache), elle appose une signature cryptographique que n'importe qui peut vérifier avec ca.crt, mais que seule la CA peut produire, puisqu'elle seule détient ca.key.

Concrètement, dans notre infrastructure : Easy-RSA joue le rôle de CA. Chaque certificat émis (serveur OpenVPN, chaque utilisateur, le certificat web d'Apache) est signé par cette même CA, ce qui permet à toutes les parties de se faire confiance mutuellement sans jamais avoir à échanger de secret directement entre elles.

Le SAN (Subject Alternative Name)

Les navigateurs modernes n'acceptent plus un certificat sur la seule base de son CN (Common Name) : ils exigent un SAN, qui liste explicitement les noms de domaine et/ou adresses IP pour lesquels le certificat est valide. Easy-RSA ne l'ajoute pas automatiquement — il faut le préciser explicitement à la génération, sous peine de voir apparaître l'erreur SSL_ERROR_BAD_CERT_DOMAIN malgré un certificat par ailleurs valide et bien signé.

La révocation : que faire quand un certificat ne doit plus être valide

Un certificat signé reste valide jusqu'à sa date d'expiration, sauf action explicite. La révocation permet de l'invalider avant terme (poste volé, départ d'un collaborateur) : la CA maintient une liste de certificats révoqués (CRL, Certificate Revocation List) que le serveur OpenVPN consulte à chaque tentative de connexion.

À retenir Un certificat, à lui seul, ne prouve rien. Ce qui fait sa valeur, c'est la signature de la CA, vérifiable par tous grâce à ca.crt. Protéger la clé privée de la CA (ca.key) est donc l'enjeu de sécurité le plus fondamental de toute la PKI : quiconque la possède peut émettre des certificats de confiance illimités.

Chapitre 3

OpenVPN : le tunnel chiffré

Objectifs de ce chapitre • Comprendre le rôle du protocole TLS dans l'établissement du tunnel • Savoir lire les directives essentielles d'un server.conf • Comprendre le compromis entre auth-nocache et reneg-sec

 

OpenVPN construit un tunnel chiffré entre le client et le serveur, en s'appuyant sur TLS (le même protocole qui sécurise HTTPS) pour la négociation initiale, puis sur un chiffrement symétrique performant (AES-256-GCM dans notre configuration) pour le trafic une fois le tunnel établi.

Les éléments clés de server.conf

● ca / cert / key / dh : les éléments de la PKI vus au chapitre précédent, qui permettent au serveur de prouver son identité et de vérifier celle du client

● tls-auth ta.key : une clé supplémentaire, partagée à l'avance, qui rejette silencieusement tout paquet mal formé avant même la négociation TLS — une protection contre le scan et certaines attaques de déni de service

● plugin openvpn-plugin-auth-pam.so : le point de bascule qui délègue la vérification de l'identité utilisateur à PAM, sujet du chapitre suivant

● cipher AES-256-GCM : le chiffrement du trafic une fois le tunnel établi — GCM est un mode "authentifié", qui détecte toute altération des données en plus de les chiffrer

Le compromis auth-nocache / reneg-sec

Par défaut, OpenVPN renégocie la session toutes les heures (reneg-sec, 3600 secondes par défaut), ce qui redemande normalement les identifiants. Avec auth-nocache actif (volontaire, pour ne jamais garder un code TOTP à usage unique en mémoire), le client ne peut plus répondre automatiquement à cette demande : la connexion se coupe purement et simplement, au lieu de se rafraîchir silencieusement.

La solution retenue est d'espacer cette renégociation à 8 heures (reneg-sec 28800) plutôt que de la désactiver complètement : un compromis entre confort d'usage (pas de coupure en pleine journée de travail) et hygiène de sécurité (une session ne vit jamais indéfiniment sans un minimum de rafraîchissement).

À retenir OpenVPN ne sait absolument rien de RADIUS, de privacyIDEA ou du TOTP : sa seule responsabilité est le tunnel chiffré et le passage de témoin à PAM via son plugin. C'est cette étroitesse du rôle qui rend la brique fiable et simple à raisonner.

Chapitre 4

Réseau et pare-feu : maîtriser les flux

Objectifs de ce chapitre • Comprendre le fonctionnement d'un pare-feu à états avec nftables • Distinguer tunnel complet et split-tunneling • Comprendre le rôle du NAT dans cette architecture

 

nftables : un pare-feu à états

nftables filtre le trafic selon trois chaînes principales : input (trafic à destination du serveur lui-même — SSH, HTTPS, OpenVPN), forward (trafic qui traverse le serveur, entre le tunnel VPN et les réseaux internes), et output (trafic sortant du serveur, généralement peu restreint). La politique par défaut adoptée est drop : tout est refusé sauf ce qui est explicitement autorisé — plus sûr qu'une liste de blocages, qui oublie toujours un cas.

Un point technique important : les règles qui référencent l'interface tunnel (tun0) utilisent iifname (filtrage par nom) plutôt que iif (filtrage par index), car tun0 n'existe pas encore au moment où nftables charge ses règles au démarrage du système — OpenVPN ne la crée qu'après.

Tunnel complet vs split-tunneling

Un tunnel complet (redirect-gateway) fait passer tout le trafic du client par le VPN, y compris sa navigation Internet ordinaire — maximise la sécurité et la visibilité, mais charge le serveur VPN de tout ce trafic. Le split-tunneling, retenu dans notre configuration, ne route que le trafic à destination de réseaux internes précis (ici trois sous-réseaux /24) : le reste du trafic Internet du client continue de sortir par sa connexion locale habituelle.

Le rôle du NAT

Le NAT (masquerade) fait apparaître tout le trafic client comme provenant de l'adresse du serveur VPN lui-même, vis-à-vis des réseaux internes. C'est nécessaire tant que le serveur VPN est l'unique point d'entrée reconnu par ces réseaux (pas de route de retour connue vers le sous-réseau VPN) — sans le NAT, les réponses des serveurs internes ne sauraient pas comment revenir vers le client.

À retenir Le split-tunneling n'est pas juste une optimisation de bande passante : c'est aussi une réduction de surface d'exposition — le serveur VPN ne devient pas un point de passage pour la navigation Internet générale des utilisateurs, seulement pour ce qui a réellement besoin de passer par lui.

Chapitre 5

PAM : le pont vers l'authentification externe

Objectifs de ce chapitre • Comprendre le rôle de PAM dans l'écosystème Linux • Distinguer les phases auth et account • Comprendre pourquoi un compte Linux n'est plus nécessaire pour les utilisateurs VPN

 

PAM (Pluggable Authentication Modules) est le mécanisme standard par lequel les applications Linux délèguent la vérification d'identité, sans avoir à implémenter elles-mêmes la logique d'authentification. Un fichier de configuration par service (ici /etc/pam.d/openvpn) définit une pile de modules à exécuter, chacun pouvant valider ou rejeter la tentative.

auth vs account : deux phases distinctes

La phase auth vérifie l'identité proprement dite (mot de passe, ici relayé vers RADIUS via pam_radius_auth). La phase account vérifie des conditions annexes sur le compte (expiration, restrictions horaires...) — et c'est là qu'un piège attend : si aucune règle account n'est définie explicitement, PAM retombe sur le comportement par défaut de /etc/pam.d/other, qui inclut généralement pam_unix.so — lequel exige un compte Linux existant. Sur une architecture où les utilisateurs n'ont plus de compte système (gérés entièrement dans privacyIDEA), ce fallback silencieux fait échouer toutes les connexions.

# Configuration minimale et correcte pour ce cas d'usage : auth required pam_radius_auth.so account required pam_permit.so

 

pam_permit.so accepte systématiquement la phase account sans aucune vérification — cohérent ici puisque l'authentification réelle est déjà entièrement déléguée à RADIUS en amont, dans la phase auth.

À retenir PAM est un pont, pas une destination : il ne fait aucune vérification lui-même dans notre cas, il transmet simplement la demande à pam_radius_auth. Comprendre la distinction auth/account évite un piège classique lors de toute migration d'une authentification système vers une authentification externe.

Chapitre 6

FreeRADIUS : le relais d'authentification centralisé

Objectifs de ce chapitre • Comprendre le protocole RADIUS et son vocabulaire (client, secret partagé, Access-Request) • Savoir pourquoi FreeRADIUS n'est ici qu'un relais, pas un système d'authentification en soi • Connaître le piège du paquet openvpn-auth-radius sur Debian 13

 

RADIUS (Remote Authentication Dial-In User Service) est un protocole ancien (années 1990) mais toujours omniprésent en entreprise pour centraliser des demandes d'authentification — Wi-Fi d'entreprise, VPN, accès réseau filaire 802.1X. Son vocabulaire est simple : un client RADIUS (ici, indirectement, OpenVPN via pam_radius_auth) envoie une Access-Request au serveur, authentifiée par un secret partagé à l'avance ; le serveur répond par un Access-Accept ou un Access-Reject.

FreeRADIUS comme pur relais dans notre architecture

Dans une configuration RADIUS classique, FreeRADIUS vérifie lui-même les mots de passe (fichier local, LDAP, base SQL...). Ici, ce n'est pas le cas : un module Perl (privacyidea_radius.pm) redirige chaque requête vers l'API HTTPS de privacyIDEA, qui est seul à savoir valider un code TOTP. FreeRADIUS ne fait que transporter et traduire entre le protocole RADIUS (utilisé par PAM) et le protocole HTTP (utilisé par privacyIDEA) — c'est un pur relais protocolaire.

Le piège du paquet Debian openvpn-auth-radius

Une approche plus directe aurait consisté à utiliser le paquet openvpn-auth-radius, qui permet à OpenVPN de parler RADIUS sans passer par PAM. Sur Debian 13 stable, ce paquet contient un bug connu lié à la mitigation de la vulnérabilité BlastRADIUS, qui empêche purement et simplement toute authentification de fonctionner. C'est pour cette raison que l'architecture retenue passe par PAM plutôt que par ce module dédié — un choix dicté par un bug de packaging, pas par une préférence architecturale a priori.

À retenir FreeRADIUS ici n'authentifie personne : il relaie. C'est privacyIDEA qui détient la vérité sur qui peut se connecter. Cette distinction est importante pour savoir où chercher en cas de problème : un rejet vient presque toujours de privacyIDEA, pas de FreeRADIUS lui-même.

Chapitre 7

privacyIDEA : le cœur du MFA

Objectifs de ce chapitre • Comprendre le fonctionnement du TOTP • Distinguer resolver et realm • Connaître les policies clés : otppin, default_tokentype, login_mode, auth_max_fail

 

Le principe du TOTP

TOTP (Time-based One-Time Password) génère un code à 6 chiffres qui change toutes les 30 secondes, calculé à partir d'un secret partagé (échangé une seule fois, au moment du scan du QR code) et de l'heure actuelle. Le serveur et le téléphone n'ont jamais besoin de communiquer directement : ils arrivent au même code indépendamment, parce qu'ils partagent le même secret et une horloge synchronisée — c'est pourquoi la synchronisation NTP du serveur est critique.

Resolver et realm : où vivent les utilisateurs

Un resolver définit une SOURCE d'utilisateurs (un fichier /etc/passwd, un annuaire LDAP, ou — le choix retenu ici — une table SQL interne gérée entièrement par privacyIDEA). Un realm regroupe un ou plusieurs resolvers sous un même nom, utilisé pour l'authentification. Utiliser un resolver interne plutôt que /etc/passwd évite d'exposer tous les comptes système du serveur comme candidats à l'authentification VPN, et permet de gérer les utilisateurs entièrement depuis l'interface web, sans jamais toucher au système Linux sous-jacent.

Les policies qui façonnent le comportement

● otppin=userstore : exige la concaténation mot de passe + code TOTP plutôt que le code seul — transforme deux facteurs de possession (certificat + téléphone) en un vrai double facteur incluant la connaissance

● default_tokentype=totp : évite d'avoir à changer manuellement le type de token (HOTP par défaut) à chaque enrôlement

● login_mode=privacyIDEA : force la vérification du token même pour la connexion à l'interface d'administration elle-même

● auth_max_fail : limite le nombre d'échecs d'authentification par utilisateur sur une fenêtre de temps glissante, indépendamment du compteur d'échecs propre à chaque token

À retenir privacyIDEA est la seule brique de toute l'architecture qui sait réellement qui a le droit de se connecter et avec quel second facteur. Toutes les autres briques (OpenVPN, PAM, FreeRADIUS) ne font que transporter une question jusqu'à elle, et transmettre sa réponse.

Chapitre 8

Le flux d'authentification de bout en bout

Objectifs de ce chapitre • Visualiser le trajet complet d'une tentative de connexion • Comprendre ce qui se passe une fois le tunnel établi

Assembler mentalement les six chapitres précédents en un seul flux permet de comprendre où chercher en cas de problème, et pourquoi.

Flux d'authentification : Client -> OpenVPN -> FreeRADIUS -> privacyIDEA -> MariaDB

Le client envoie son certificat (vérifié directement par OpenVPN grâce à la PKI), puis son nom d'utilisateur et mot de passe+TOTP concaténés. OpenVPN transmet cette seconde partie à PAM, qui la relaie à FreeRADIUS via le protocole RADIUS, qui la relaie à son tour à privacyIDEA via son API HTTPS. privacyIDEA vérifie le mot de passe (contre son resolver interne) et le code TOTP (contre le secret du token), puis répond Accept ou Reject — réponse qui redescend exactement le même chemin en sens inverse.

Une fois le tunnel établi, un second flux prend le relais : celui du trafic réseau proprement dit.

Flux réseau post-authentification : split-tunneling vers les réseaux et DNS internes

Seul le trafic à destination des réseaux internes définis passe par le tunnel ; le reste du trafic (navigation Internet ordinaire du client) continue de sortir par sa connexion locale habituelle — c'est le split-tunneling vu au chapitre 4.

À retenir Face à un problème d'authentification, remonter mentalement ce schéma dans l'ordre (logs OpenVPN, puis FreeRADIUS en mode debug, puis logs privacyIDEA) permet de localiser en quelques minutes à quel maillon la chaîne casse, plutôt que de chercher au hasard.

Chapitre 9

Sécurisation avancée

Objectifs de ce chapitre • Comprendre les mécanismes de protection ajoutés au-delà de la base fonctionnelle • Savoir pourquoi chacun répond à une menace précise

 

Anti-brute-force à deux niveaux

Un compteur d'échecs par token (avec déverrouillage automatique après un délai) protège contre un attaquant qui tenterait de deviner un code sur un token précis. Une policy auth_max_fail, indépendante et calculée dynamiquement depuis le journal d'audit, protège au niveau de l'utilisateur tout entier, quel que soit le token utilisé — les deux mécanismes ne se substituent pas l'un à l'autre, et un déverrouillage de l'un ne débloque pas l'autre.

Protection de la clé privée de la CA

Chiffrer ca.key par une passphrase transforme un accès root au serveur (qui suffirait sinon à émettre des certificats valides sans aucune friction) en un accès qui nécessite en plus la connaissance d'un secret distinct. Cette protection n'affecte jamais les certificats déjà émis, puisque leur vérification ne dépend que du certificat public de la CA (ca.crt), jamais de sa clé privée.

MFA pour les comptes administrateurs

Une limitation de conception de privacyIDEA veut que les comptes admin "internes" (créés via pi-manage admin add) ne puissent jamais recevoir de second facteur. La solution consiste à créer un realm administratif dédié : un compte devient alors un utilisateur privacyIDEA ordinaire, qui hérite des droits d'administration via le paramètre SUPERUSER_REALM, et qui peut donc recevoir un token comme n'importe quel autre utilisateur.

Rate-limiting réseau

Limiter le débit de nouvelles connexions (pas des connexions déjà établies) sur les ports exposés freine un scan ou une tentative de saturation, sans affecter un usage normal, même avec plusieurs utilisateurs se connectant simultanément.

À retenir Aucune de ces protections n'est individuellement suffisante : c'est leur superposition (defense in depth) qui rend l'ensemble robuste. Chacune répond à une menace précise et reste utile même si une autre venait à échouer.

Chapitre 10

Exploitation, maintenance et croissance

Objectifs de ce chapitre • Savoir quoi sauvegarder et pourquoi • Connaître la procédure de révocation d'un certificat • Anticiper la croissance du nombre d'utilisateurs

 

Sauvegardes : quoi et pourquoi

Sans sauvegarde de la base de données privacyIDEA et de ses clés de chiffrement, une simple panne disque rend tous les tokens TOTP existants définitivement inutilisables, même en réinstallant le reste de l'infrastructure à l'identique — les secrets TOTP ne peuvent pas être régénérés, ils doivent être réenrôlés utilisateur par utilisateur. Sur une infrastructure déjà sauvegardée au niveau de la VM (Proxmox Backup Server, chiffré, avec cohérence applicative via qemu-guest-agent), un script de sauvegarde applicatif reste utile pour une restauration rapide et ciblée, sans dépendre de la redondance déjà assurée à un autre niveau.

Révocation d'un certificat

La révocation (perte, vol, départ d'un utilisateur) doit toujours s'accompagner de deux actions : révoquer le certificat côté PKI (et régénérer la CRL, qui ne s'applique pas rétroactivement à ce qui a déjà été généré avant la révocation), et désactiver le compte côté privacyIDEA — un seul des deux facteurs bloqué ne suffit pas si l'autre reste valide.

Anticiper la croissance

Le nombre d'utilisateurs enregistrés n'est pas ce qui dimensionne réellement le serveur : c'est le nombre de connexions simultanées, généralement une fraction du total. Le poste de disque le plus sous-estimé est la table d'audit de privacyIDEA, qui grossit indéfiniment sans purge périodique — un point à surveiller bien avant qu'il ne devienne un problème de production.

À retenir Une infrastructure de sécurité n'est jamais "terminée" au sens d'un projet ponctuel : elle demande une attention continue (sauvegardes vérifiées, dimensionnement réévalué, procédures de révocation exercées) pour rester fiable dans la durée, pas seulement au moment de sa mise en service.

 

Pour aller plus loin

Ce document couvre les concepts. Pour la mise en œuvre pratique, deux documents complémentaires existent : le guide d'installation propre (procédure directe, sans détour), et le journal détaillé (chaque problème rencontré et sa résolution, utile en cas de situation similaire) ainsi qu'un aide-mémoire de commandes de diagnostic pour le dépannage au quotidien.