VPN IP privé Azure sur ExpressRoute sans NVA

Le mythe veut que le chiffrement du trafic sur le peering privé ExpressRoute exige une appliance réseau virtuelle. Ce n'est pas le cas. Azure prend en charge une Site-to-Site VPN Gateway dont le point de terminaison du tunnel est une adresse RFC1918 privée transportée par le circuit, et l'appliance est facultative plutôt que structurelle. Ce que le mythe de l'appliance cache, c'est la partie qui fait vraiment mal : activer le point de terminaison privé sur un objet au lieu de deux, et laisser une route de peering directe gagner silencieusement sur le chemin chiffré.

D'où vient le mythe

L'affirmation a une origine respectable. Pendant des années, la recette pratique pour IPsec sur le peering privé était une NVA, car la passerelle gérée n'exposait que des points de terminaison publics. Cela a changé, et les réponses écrites avant ce changement sont encore citées dans des fils où personne ne vérifie la date. La correction est étroite : une passerelle VPN à adresse privée existe, et elle change le point de terminaison, pas la logique de routage autour de lui.

Rien de tout cela ne met la NVA à la retraite. Cela met à la retraite l'hypothèse selon laquelle une appliance est le seul chemin vers l'exigence.

Activez le point de terminaison privé aux deux niveaux

Partez d'une connexion de peering privé ExpressRoute fonctionnelle, liée au VNet qui héberge la passerelle VPN. Le côté sur site doit déjà joindre les adresses privées concernées via ce circuit, car le tunnel utilisera ces adresses comme transport. Puis le prérequis de la passerelle : la procédure Microsoft pour le VPN à IP privée exige une passerelle construite sur une ressource IP publique Standard. L'adressage privé du tunnel ne supprime pas cette exigence, ce qui surprend ceux qui supposent que « privé » signifie « aucune IP publique nulle part ».

Activez maintenant l'indicateur aux deux endroits. La configuration de la passerelle a son propre commutateur pour les IP privées, et la connexion Site-to-Site individuelle en a un second qui fait utiliser l'adresse privée à cette connexion. Régler l'un sans l'autre est la configuration incomplète la plus courante ; le tunnel soit ne s'établit pas, soit s'établit vers le mauvais point de terminaison.

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

Vérifiez les noms de propriétés par rapport à la version de CLI installée, car les libellés du portail et les propriétés de la CLI n'ont pas toujours la même formulation. Une passerelle active-active expose deux adresses de tunnel privées, et l'équipement local doit avoir les deux pairs configurés si vous voulez que cette redondance ait un sens. BGP n'est pas requis simplement pour monter ce tunnel à adresse privée, même s'il fait généralement partie de la façon dont vous distribuez les préfixes.

Le deuxième mythe : un tunnel établi chiffre votre trafic

Deux chemins atteignent désormais le réseau applicatif : le chemin direct du peering privé et le chemin via le VPN. Les deux fonctionnent. Un seul applique cette couche IPsec. Microsoft documente que, lorsque des préfixes identiques sont annoncés via ExpressRoute et via le VPN, Azure préfère le chemin direct ExpressRoute ; un tunnel sain avec des compteurs sains ne prouve donc rien sur l'endroit où sont allés les paquets applicatifs.

Les méthodes de pilotage documentées sont une plage couvrante sur ExpressRoute avec une plage protégée plus spécifique sur le VPN, ou des préfixes disjoints sur les deux chemins. Par exemple, le peering privé pourrait porter 10.40.0.0/16 tandis que le VPN annonce 10.40.12.0/24. Le préfixe plus spécifique l'emporte et le reste de la plage reste direct.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

Faites la même vérification dans la direction sur site, car la préférence de votre routeur décide par où sort le trafic sortant. Et gardez le transport du tunnel lui-même sur le chemin ExpressRoute ; une route qui attire le point de terminaison privé de la passerelle dans le tunnel rend le tunnel dépendant de lui-même.

Décidez de ce qui se passe lorsque le tunnel tombe

Une route VPN plus spécifique disparaît lorsque le tunnel tombe, tandis que la route directe plus large subsiste. Le trafic circule alors en clair et tout semble sain, ce qui est le pire mode de défaillance pour une exigence qui existe pour garantir le chiffrement. Si l'exigence interdit ce repli, le routage et la stratégie d'accès doivent le dire explicitement plutôt que de compter sur la disponibilité du tunnel.

Notez quels préfixes peuvent rester joignables directement et lesquels doivent s'arrêter lorsque le chemin chiffré est absent. Testez ensuite le cas autorisé avec du vrai trafic et comparez les compteurs de connexion, car la table de routage seule ne vous dira pas si l'exigence de chiffrement tient toujours.

Ce cadre vous permet aussi d'évaluer une NVA sur ses fonctions réelles, comme plusieurs tunnels, le débit ou l'inspection du fournisseur, au lieu d'en acheter une parce que le point de terminaison est privé.