Passerelle VPN Windows : trois tâches, trois responsables

Trois fonctions se retrouvent ensemble dès que quelqu’un dit serveur VPN : terminer le tunnel chiffré, déplacer des paquets entre réseaux et, en option, réécrire les adresses. Sous Windows, elles vivent dans des parties différentes de la pile, même quand une seule machine les assure toutes. Chacune a ses propres entrées et son propre mode de défaillance, et chacune peut être confiée à un produit différent. Les séparer sur le papier est le moyen le moins coûteux de garder un petit déploiement compréhensible.

Une conception lisible nomme le responsable de chaque flux au lieu de décrire la machine comme un rôle.

Terminer, transmettre, traduire

RRAS gère le tunnel pour le cas natif de Windows : il authentifie l’utilisateur, attribue une adresse depuis un pool et décide quelles destinations sont autorisées. Un autre produit VPN peut posséder l’écouteur et l’adaptateur virtuel à sa place, laissant Windows transmettre les paquets déchiffrés. La documentation Remote Access de Microsoft sépare les rôles VPN, site à site et routage, et l’installation du rôle de routage ne crée pas une seconde identité VPN. Ajouter une autre application VPN ne confie pas non plus son adaptateur à toutes les fonctions de passerelle existantes.

La traduction est la troisième tâche, et la plus facultative. Elle vient après la transmission et modifie l’adresse source que voit le réseau distant. Son utilité dépend de ce que le réseau de destination acceptera comme source, pas du fait que la machine s’appelle une passerelle VPN.

À qui appartiennent l’adaptateur et le pool

Quand plusieurs produits partagent l’hôte, quatre éléments ont chacun besoin d’un seul responsable : les ports d’écoute, la durée de vie de l’adaptateur, le pool d’adresses clients et les routes. L’adaptateur est le cas embarrassant, car un service VPN peut le créer dynamiquement et le détruire à la déconnexion. Traiter cette interface comme une carte réseau au nom permanent et écrire des règles contre son nom fonctionne jusqu’à la prochaine reconnexion. Utilisez le point d’intégration pris en charge par le produit plutôt que de coder en dur un nom d’interface.

Le pool d’adresses est la seconde collision. Deux produits qui distribuent des plages qui se chevauchent produisent un routage qui paraît correct et ne livre rien. Gardez les pools dans le même document que les routes, afin qu’une modification de l’un soit visible face à l’autre.

Préserver la source ou la réécrire

Préserver l’adresse source du client maintient la visibilité par utilisateur : journaux, quotas et règles de pare-feu peuvent distinguer un utilisateur d’un autre. Le prix est que le LAN de destination a besoin d’une route de retour vers la passerelle, et que quelqu’un doit la maintenir. Réécrire la source avec NAT supprime cette exigence et supprime la visibilité avec elle. Choisissez délibérément et notez quelles informations la réécriture masque.

L’accès au réseau privé, la sortie vers internet et les connexions qui se terminent sur la passerelle elle-même sont trois chemins différents. Ils n’ont pas tous besoin du même traitement.

Décrire le flux en une phrase

Une phrase devrait décrire la conception : quels clients ce service admet, quelles ressources cette politique de transmission accorde et comment le chemin de retour achève le flux. Si la phrase a besoin d’une seconde couche de NAT pour être vraie, c’est généralement le signe que les pièces précédentes n’étaient pas réglées. L’hôte est aussi une frontière partagée de défaillance et de confiance, si bien qu’un changement de routage peut affecter à la fois l’accès des utilisateurs et l’administration. Gardez un chemin de récupération indépendant pour cette dernière.

Tenez un inventaire des rôles à côté de la configuration : quel produit termine, lequel transmet, lequel traduit et qui peut modifier chacun. Cette liste est ce qui rend le prochain changement vérifiable.

Quand la phrase devient floue, ajouter une autre couche de traduction l’éclaircit rarement. En retirer une le fait généralement.