Pourquoi l’ajout d’un préfixe Azure VPN coupe la connexion

Un préfixe ajouté au mauvais objet Azure produit une connexion qui signale Connected et ne transmet rien, et c’est le type d’erreur le plus coûteux de cette pile. Trois ressources sont en jeu et une seule d’entre elles possède l’espace d’adressage distant : la passerelle de réseau virtuel, la passerelle de réseau local qui décrit le côté distant et la connexion qui les relie. Le préfixe appartient à la passerelle de réseau local, la connexion doit être reconstruite pour que le changement prenne effet, et la passerelle elle-même est généralement laissée intacte. L’ordre n’est pas négociable, et le portail n’en montre qu’une partie.

Trois objets, dont un seul détient le préfixe

L’espace d’adressage du réseau virtuel répond à une autre question : ce qui vit à l’intérieur d’Azure. Y ajouter un préfixe distant n’y achemine pas le trafic, cela élargit seulement l’espace que la plateforme croit posséder, ce qui peut entrer en collision avec la plage distante réelle. La passerelle de réseau local est l’objet qui détient les préfixes distants, et la connexion référence les deux passerelles plus une clé partagée au préalable.

Il y a une troisième réservation à garder en tête. GatewaySubnet héberge les instances gérées de la passerelle, doit porter exactement ce nom, et pour les SKU non Basic, il est attendu qu’il soit au moins un /27.

Rien d’autre n’appartient à ce sous-réseau, et un changement de préfixe n’a aucune raison de le toucher. Un préfixe absent de la passerelle de réseau local est injoignable quoi que dise l’état de la connexion, car la passerelle ne propose que les préfixes dont elle a été informée lorsqu’elle négocie le tunnel. C’est pourquoi le symptôme est asymétrique : le tunnel est monté, l’association de sécurité est correcte, et un sous-réseau n’apparaît jamais dans les sélecteurs de trafic. Si une seule plage distante manque alors que ses voisines fonctionnent, cessez de regarder le tunnel et lisez la passerelle de réseau local.

Pourquoi c’est la connexion qui est supprimée

L’objet de connexion fige la configuration négociée pour toute sa durée de vie. C’est pourquoi la procédure documentée supprime d’abord la connexion, met à jour la passerelle de réseau local, puis recrée la connexion avec la même clé partagée. Les instances de passerelle ne sont pas reconstruites pour un changement de préfixe seul, ce qui limite la panne au démontage de la connexion plutôt qu’à un redéploiement de la passerelle.

Cette suppression est la panne, alors traitez-la comme un changement planifié avec un début et une fin attendue plutôt que comme une modification rapide. Dans PowerShell, la séquence est courte : Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, puis Set-AzLocalNetworkGateway avec le nouveau -AddressPrefix tableau, puis New-AzVirtualNetworkGatewayConnection avec la même -SharedKey et les mêmes passerelles. Réutiliser la clé compte, car le côté distant n’est pas reconfiguré et une nouvelle clé signifie se coordonner avec celui qui possède l’équipement distant. Si une autre équipe exploite cet équipement, convenez de la fenêtre avec elle avant de supprimer quoi que ce soit.

Quand la passerelle elle-même doit être reconstruite

Une deuxième réponse qui circule autour de ce problème dit que la passerelle doit être recréée et la clé rééchangée. C’est exact pour un autre ensemble d’opérations : changer le type de passerelle ou la SKU, passer entre point à site et site à site, ou réparer une passerelle dont la configuration propre est erronée. Ces changements modifient bien la ressource de passerelle, une reconstruction est donc réellement nécessaire.

Une passerelle créée pour point à site ne peut pas simplement recevoir une connexion site à site. La configuration point à site doit être supprimée et la passerelle recréée, ce qui produit aussi une nouvelle clé partagée et un nouveau paquet client.

Le paquet point à site mérite sa propre note car il expire. Le portail génère un fichier à durée de vie courte, l’approche pratique consiste donc à le télécharger une fois et à le distribuer avec le certificat client au lieu d’envoyer aux utilisateurs un lien de portail qui sera mort au moment où ils cliqueront. Pour la question du préfixe, rien de tout cela ne s’applique. Garder les deux procédures séparées est toute la discipline : les préfixes sont un changement au niveau de la connexion, et les propriétés de passerelle sont un changement au niveau de la passerelle.

Lisez l’état, pas le badge du portail

Lisez l’état depuis la ressource plutôt que depuis le badge du portail. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 renvoie ConnectionStatus avec les compteurs d’octets entrants et sortants, et ce sont les compteurs qui distinguent un tunnel connecté qui ne transporte rien d’un tunnel qui ne s’est jamais établi.

Les compteurs qui cessent d’augmenter au milieu d’un transfert pointent vers le chemin plutôt que vers l’authentification. Les compteurs qui ne bougent pas du tout pointent vers le jeu de préfixes ou la clé partagée.

Les minuteries expliquent une classe de déconnexions attribuées à tort au VPN. L’équilibreur de charge d’Azure ferme les flux inactifs après son délai configuré, quatre minutes par défaut au moment de ces notes et configurable à la hausse, si bien qu’un serveur OpenVPN sur une VM sans keepalive peut tomber toutes les quelques minutes alors que tout le reste semble sain. Une passerelle que la plateforme redémarre cycliquement peut aussi interrompre une connexion VNet vers une Web App, et cette panne se situe côté plateforme et non dans une configuration client. L’indice est de savoir si la déconnexion suit un intervalle fixe ou un changement que vous avez effectué.

Conservez les trois objets et leurs valeurs dans un seul enregistrement : l’espace d’adressage du réseau virtuel, la liste de préfixes de la passerelle de réseau local et la référence à la clé partagée de la connexion. article PowerShell site à site documente les commandes de la passerelle de réseau local et l’ordre auquel elles appartiennent. Comparer un changement de préfixe à sa mémoire est la façon dont un tunnel qui fonctionne est reconstruit deux fois.

Vérifiez ensuite dans l’ordre où vous avez modifié : la passerelle de réseau local affiche la nouvelle liste de préfixes, la connexion est revenue à Connected, et les compteurs bougent lorsque vous envoyez du trafic vers un hôte de la nouvelle plage. Si la troisième étape échoue alors que les deux premières passent, le côté distant n’a pas accepté le nouveau sélecteur de trafic et l’équipement distant a besoin de l’entrée de phase 2 correspondante. C’est une conversation avec l’autre extrémité du tunnel, pas un autre changement dans Azure.