Accès de VPN à VLAN : construisez la matrice avant les règles
Des rôles d'un côté, des services de l'autre. Cinq contrôles transforment un projet flou d'accès de VPN à VLAN en un tableau qu'un responsable du pare-feu peut mettre en œuvre.
Commencez par la matrice, pas par la syntaxe du pare-feu. Un tableau avec les rôles d'un côté et les services de l'autre peut être relu par un responsable applicatif, discuté par un responsable sécurité et mis en œuvre par celui qui tient la passerelle. Cette relecture coûte moins cher que de déboguer des règles sur lesquelles personne ne s'est mis d'accord.
Une heure de rédaction épargne plus tard une semaine d'archéologie des règles. Le projet parle de qui atteint quel service, et c'est la partie qui survit à une renumérotation.
Étape 1 : nommez les rôles avant les réseaux
Partez des personnes, pas du commutateur. Notez chaque groupe qui se connecte à distance et la phrase unique qui décrit ce que fait ce groupe, par exemple du personnel d'entrepôt qui consulte les niveaux de stock ou un prestataire qui maintient une intégration. Si deux groupes recevaient le même accès, ils forment un seul rôle pour cet usage.
Arrêtez-vous ici si un rôle n'existe qu'à cause d'un organigramme. Un rôle sans besoin de service propre devient une ligne de cellules identiques, et les lignes identiques invitent quelqu'un à accorder plus tard un sous-réseau entier par commodité. Découpez selon ce que les gens font, pas selon qui signe leurs dépenses. Six rôles, c'est généralement trop pour un petit bureau, et trois suffisent souvent.
Étape 2 : transformez chaque cellule en énoncé de service
Une cellule qui dit « Applications » n'est pas vérifiable. Une cellule qui dit « HTTPS vers l'hôte ERP sur 443, depuis le pool du personnel » l'est. Remplacez chaque nom de réseau par une destination, un protocole et un port, puis ajoutez la dépendance sans laquelle le service ne fonctionne pas, comme le résolveur interne ou le fournisseur d'identité.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
La colonne de direction attrape les erreurs les plus coûteuses. L'autorisation pour le personnel d'ouvrir une application n'implique pas l'autorisation pour les serveurs d'application d'ouvrir des connexions vers les portables du personnel, et une règle avec état qui autorise la première direction est souvent lue comme autorisant la seconde.
Étape 3 : décidez où l'identité devient politique
Quelqu'un doit transformer une session authentifiée en un rôle que la passerelle peut appliquer. Les options prises en charge incluent une politique de groupe fournie par le backend d'authentification, des attributs de session de confiance ou des pools d'adresses distincts par rôle. Les trois fonctionnent ; une étiquette envoyée par le client non. Choisissez le mécanisme que votre passerelle documente, pas celui que décrit un message de forum.
Attribuer une adresse qui semble seulement appartenir à un VLAN est la même non-réponse sous un autre costume. Le guide Netgate des règles de pare-feu OpenVPN rend la séparation claire : autoriser le tunnel à monter est une décision différente d'autoriser le trafic à le traverser.
Notez quel mécanisme vous avez choisi et où il est configuré. Quand un rôle change, cette note fait la différence entre une modification et une chasse à travers trois interfaces. Elle indique aussi à un auditeur où regarder en premier.
Étape 4 : surveillez l'adresse source que voit la destination
La politique de transfert doit correspondre à la source réelle à la frontière. Si la passerelle traduit les clients VPN vers sa propre adresse, chaque pare-feu en aval voit une seule source et perd la capacité de décider par rôle. Si elle conserve l'adresse du client, le chemin de retour doit exister pour ce pool.
Testez les deux directions avant d'écrire les règles finales, puis notez la source observée à côté de chaque cellule. Exécutez le même contrôle depuis deux rôles différents et comparez le résultat. Si les deux montrent l'adresse de la passerelle, la distinction des rôles est déjà perdue. Une matrice qui suppose des adresses conservées alors que la passerelle fait de la traduction de source échoue au premier ACL en aval.
Étape 5 : testez chaque cellule avant de livrer
Transformez chaque cellule autorisée en une opération représentative et chaque cellule refusée en cas négatif. Exécutez les deux depuis un client dans le rôle réel, pas depuis la console de la passerelle, car la console contourne le chemin que vous testez.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'Un cas négatif qui se connecte est une trouvaille, pas un hasard, et il a sa place dans la matrice comme cellule en échec jusqu'à ce que la règle soit corrigée. Gardez les commandes de test à côté du tableau pour que le prochain relecteur les relance au lieu de reconstruire le raisonnement.
Le tableau terminé survit à la passerelle pour laquelle il a été écrit. Les règles changent avec le firmware et le fournisseur, tandis que la ligne qui dit qu'un prestataire atteint un service de projet reste vraie jusqu'à ce que ce travail change.