IP statique dans Azure P2S VPN : pourquoi l'adresse du client change

Chaque client Azure point-to-site reçoit une adresse du pool lorsqu'il s'authentifie, et ne la conserve que pendant la durée de cette connexion. Il n'y a pas de table de réservation, pas de correspondance par utilisateur, et aucun réglage de passerelle qui signifie « donne toujours 172.16.0.10 à cette personne ». Ce seul mécanisme explique les deux symptômes rencontrés plus tard : une règle NSG qui cesse de correspondre à un utilisateur auquel elle correspondait, et une liste d'autorisations qui admet discrètement une machine que personne n'a ajoutée exprès. Remplacer la règle par une règle IP plus astucieuse ne corrige ni l'un ni l'autre, car ce que la règle nomme est réattribué selon un calendrier que vous ne contrôlez pas.

Le pool est une capacité, pas une identité. Il existe pour que les tunnels simultanés obtiennent des adresses uniques, et il les recycle dès qu'un bail se termine. Une fois cela clair, la question utile cesse d'être « comment j'épingle ce client » et devient « contre quoi puis-je écrire une règle que la passerelle ne recyclera pas ».

Ce que fait réellement la passerelle quand un client se connecte

La passerelle conserve le pool d'adresses de clients configuré et le traite comme une table de bails. À la connexion, elle prend la prochaine adresse libre, en pratique la plus basse disponible, et l'attribue à l'adaptateur de tunnel jusqu'à ce que le client se déconnecte ou que le bail expire. C'est l'ordre qui décide, pas l'identité : celui qui se reconnecte le premier après une période calme obtient l'adresse la plus basse qui se trouve être libre à ce moment-là.

La taille du pool masque le comportement. Un pool de laboratoire d'une ou deux adresses de plus que le nombre de testeurs paraît déterministe, car le même portable a tendance à se reconnecter dans le même ordre chaque matin. Ajoutez une troisième machine, redimensionnez le pool ou laissez une session connectée pendant le déjeuner, et le schéma se casse. L'adresse n'a jamais été stable ; la file l'était.

Toute modification de la configuration point-to-site réinitialise aussi l'espace de baux. Un autre type d'authentification, un pool redimensionné, une nouvelle plage de pool ou une passerelle démolie puis reconstruite renvoient tous les clients dans un pool qui ne correspond plus à leurs anciennes adresses. Rien dans ce changement ne touche votre NSG, et c'est pourquoi la panne paraît spontanée.

Vous pouvez le constater en une minute environ. Connectez-vous, notez l'adresse du tunnel dans les détails de connexion du client, déconnectez-vous, connectez une deuxième machine, puis reconnectez la première. L'adresse que vous récupérez dépend de ce que détient la deuxième machine, et aucun réglage du portail ne rétablira l'ancienne à la demande.

Un NSG fondé sur l'IP du client est en réalité une règle sur l'ordre de connexion

La règle que l'on écrit d'abord est l'évidente : une règle entrante sur la carte réseau de la VM d'administration ou sur son sous-réseau, avec l'adresse interne du client VPN comme source. Elle est courte, elle passe le test le jour où on l'écrit, et elle échoue dès que le pool compte plus d'une adresse libre.

Deux modes de défaillance en découlent, et un seul ressemble à un bug. Un utilisateur légitime est refusé parce que quelqu'un d'autre détient à cet instant l'adresse que la règle nomme, ce qui arrive comme un ticket de support pénible. Ou un utilisateur non prévu est autorisé parce qu'il a hérité d'une adresse à laquelle la règle fait encore confiance, ce qui n'arrive comme rien du tout avant que quelqu'un n'audite les accès.

Comme la règle suit le bail, la politique effective se lit « la première personne à se connecter obtient l'accès d'administration ». C'est une description de l'ordre de connexion déguisée en intention, et aucune hygiène de règles n'en fait une expression d'intention.

Le bail du client et l'adresse de la passerelle sont des objets différents

L'essentiel de la confusion vient d'un mot. La passerelle possède une IP publique relativement stable ; les clients ont des adresses privées issues du pool qui ne le sont pas. Pour une passerelle VPN non redondante inter-zone, l'IP publique est attribuée dynamiquement, mais elle survit à un redimensionnement, à une réinitialisation et à la maintenance de routine — elle change lorsque la passerelle elle-même est supprimée et recréée. Les références de passerelle redondantes inter-zones et zonales utilisent une IP publique de référence Standard, et cette attribution doit être statique.

Cette stabilité est ce dont un pair local a besoin dans sa configuration, et elle ne dit rien sur l'identification d'un client individuel. Quand un partenaire demande quelle adresse il verra, la réponse est l'IP publique de la passerelle en site-to-site, ou une plage NAT partagée — jamais le bail de tunnel d'un portable.

Les pools de groupe vous donnent une plage contre laquelle il vaut la peine d'écrire des règles

Virtual WAN point-to-site prend en charge les groupes d'utilisateurs, et chaque groupe peut recevoir son propre pool d'adresses de clients. L'appartenance est décidée par l'identité, donc la plage dans laquelle un client atterrit devient prévisible : les opérations dans une plage, les prestataires dans une autre, et la plage est quelque chose qu'une règle de pare-feu ou de NSG peut nommer sans deviner.

L'ensemble de règles obtenu a une forme que vous pouvez relire :

• un pool par public, dimensionné pour les pics de sessions simultanées plutôt que pour l'effectif ;
• l'appartenance aux groupes gérée par l'identité, et non en modifiant les règles à chaque arrivée ;
• des règles NSG ou Azure Firewall écrites contre des plages de pool, jamais contre des baux individuels ;
• un hub ou une passerelle distincts pour les publics qui ne doivent jamais partager une plage.

Mettre tout un pool dans la liste d'autorisations est honnête mais grossier : chaque client connecté dans cette plage obtient le même accès. C'est une décision de politique qu'il vaut mieux énoncer à voix haute que découvrir lors d'une revue. Tout ce qui exige encore une réponse par personne relève de la ressource, via des attributions de rôles, et non du filtre de paquets.

Quand le déploiement ne peut pas passer à Virtual WAN

Beaucoup de passerelles restent de simples passerelles VPN, et passer à Virtual WAN n'est pas un changement anodin. La réponse pratique consiste à déplacer la décision par utilisateur du filtre de paquets vers quelque chose qui sait déjà qui est l'utilisateur.

L'identité au niveau de la ressource est la version la moins chère. Storage, SQL et Key Vault prennent tous en charge l'authentification Entra ID avec des attributions de rôles par utilisateur ou par groupe, si bien que le VPN n'a qu'à prouver l'accessibilité réseau. Un hôte de rebond avec des comptes nommés fait le même travail pour l'administration, car l'hôte enregistre la personne et le tunnel ne transporte que des paquets. Enregistrer les clients dans le DNS et autoriser le nom plutôt que le numéro fait monter la règle d'un cran. L'identité au niveau applicatif — un sujet de certificat, une revendication de jeton, une appartenance à un groupe — fonctionne quand c'est l'application, et non le réseau, qui est chargée de décider.

Pour un partenaire qui exige une adresse source fixe, la réponse est le site-to-site ou ExpressRoute avec un préfixe de pair défini. Il autorise le préfixe de pair, l'adresse qui apparaît de son côté appartient à la passerelle, et elle ne change pas quand quelqu'un redémarre un portable.

Vérifiez le pool avant de modifier une autre liste d'autorisations

Deux propriétés du pool causent l'essentiel du comportement que l'on reproche au client. Un pool trop petit recycle les baux rapidement, si bien que les adresses semblent bouger sans cesse et que toute règle fondée sur une adresse paraît instable par construction. Un pool qui chevauche les plages locales ou l'espace d'adressage du réseau virtuel crée une ambiguïté de routage qu'aucune règle de pare-feu ne répare.

Réunissez trois choses sur une page avant de toucher à une règle : le pool point-to-site, l'espace d'adressage du réseau virtuel et les plages locales. Ils ne doivent pas se chevaucher, et le pool doit avoir de la place pour chaque client simultané plus une marge pour les reconnexions.

Fermez ensuite la boucle dans cet ordre :

• Connectez-vous depuis deux machines dans les deux ordres et comparez les adresses ; si elles peuvent s'échanger, aucune règle fondée sur une adresse n'est sûre.
• Vérifiez si la passerelle est de type Virtual WAN ; si oui, utilisez des pools de groupe au lieu de règles par adresse.
• Demandez ce qui se passe quand une règle vise la mauvaise personne ; si la réponse est un incident d'accès, déplacez le contrôle vers l'identité.
• Consignez quelle plage appartient à quel groupe dans le même dépôt que les définitions de NSG.
• Retestez après toute modification de pool, d'authentification ou de passerelle, car ces changements réécrivent la correspondance sans l'annoncer.