Peering Azure ou VPN de VNet à VNet ? Décidez avant de router

Azure vous offre au moins deux façons de connecter deux réseaux virtuels, et ce ne sont pas des réglages interchangeables sur le même objet. Le peering relie les VNet sur le backbone de Microsoft sans passerelle ; un VPN de VNet à VNet place une relation IPsec entre deux passerelles que vous déployez, dimensionnez et surveillez. La décision se ramène à trois conditions, et si vous ne pouvez pas répondre aux trois avant d'ajouter une route, vous êtes sur le point de construire un contournement pour un modèle que vous n'avez jamais choisi.

Trois conditions qui décident du modèle

La première est de savoir si quelque chose dans l'exigence a besoin d'une frontière IPsec qui vous appartient et que vous pouvez désigner. La deuxième est de savoir si les espaces d'adressage sont propres et si les deux VNet n'ont besoin que de se parler. La troisième est de savoir qui possède tout chemin transitif et la facture de la passerelle. Répondez dans cet ordre, car la première peut éliminer le peering, aussi attrayante que paraisse la deuxième.

Ce que les deux modèles partagent est une règle d'adressage stricte : les espaces d'adressage des VNet ne doivent pas se chevaucher. Ni le peering ni un VPN de VNet à VNet ne sont un moyen pris en charge de rendre deux plages identiques non ambiguës, et un chevauchement exige une conception de mappage ou une refonte, pas un autre type de connexion.

Condition 1 : avez-vous besoin d'une frontière IPsec qui vous appartient ?

Le peering transporte le trafic sur le backbone privé d'Azure et n'exige pas de passerelle VPN pour la connexion appairée elle-même. C'est une affirmation sur le transport, pas une affirmation sur le chiffrement que vous pouvez remettre à un auditeur sous la forme « nous exploitons IPsec ». Si l'exigence nomme un tunnel configuré par le client, une politique IKE précise ou une frontière qui se termine sur un équipement que vous contrôlez, le peering ne la satisfait pas, aussi privé le backbone soit-il.

Un VPN de VNet à VNet fournit bien cette frontière : deux passerelles, une relation IPsec/IKE, des clés partagées et toute la surface opérationnelle qui va avec. Vous héritez de l'état du tunnel, de la capacité de la passerelle, des limites de SKU et de la supervision qui prouve que le tunnel est actif. C'est la bonne réponse lorsque l'exigence porte précisément sur cette frontière, décrite dans la présentation du peering comme un type de connexion distinct du peering.

Soyez tout aussi prudent dans l'autre sens. « Nous avons besoin de chiffrement entre les VNet » est souvent satisfait par le TLS de la charge de travail elle-même, et une passerelle devient alors un coût sans exigence derrière. Écrivez la phrase que l'auditeur lira avant de choisir le mécanisme.

Condition 2 : la topologie est-elle directe, ou quelque chose doit-il transiter ?

Le peering n'est pas transitif. Deux VNet appairés à un hub ne sont pas pour autant connectés l'un à l'autre, et une route qui semble fonctionner dans un sens est généralement un peering qui n'a atteint Connected que d'un côté. Les deux côtés doivent exister et tous deux doivent afficher Connected, et c'est la première chose à vérifier quand le trafic disparaît silencieusement.

Si l'exigence est d'atteindre le réseau local via un hub, le transit de passerelle est une conception distincte avec des rôles précis : le hub possède la passerelle, le peering du spoke autorise le transit de passerelle et le spoke doit autoriser le trafic transféré. Ce sont des propriétés du peering, pas des conséquences automatiques de la connexion des VNet :

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

La table de routage effective est la réponse honnête à « le chemin existe-t-il ? ». Elle montre le type de saut suivant que la plateforme utilisera réellement, de sorte qu'un peering qui semble configuré mais n'est pas connecté apparaît comme une route manquante ou erronée plutôt que comme un mystère.

Condition 3 : qui possède le chemin transitif et la facture ?

Chaque saut supplémentaire a un propriétaire. Avec le peering, un nouveau VNet signifie une nouvelle paire de peerings des deux côtés et, pour le transit, un hub qui continue de transférer le trafic et une table de routage qui continue de pointer vers lui. Avec un VPN, un nouveau VNet signifie une autre passerelle ou une autre connexion sur une passerelle existante, avec son propre plafond de capacité à surveiller.

Le coût suit la même forme mais pas les mêmes lignes : les frais de peering sont la connexion et le transfert de données, tandis qu'un VPN ajoute des heures de passerelle et ses propres frais de transfert. Comparez le total pour la topologie que vous ferez réellement tourner pendant un an, y compris le second tunnel et la supervision, pas le prix d'une connexion aujourd'hui. Incluez le travail que personne ne facture : quelqu'un doit faire tourner les clés, surveiller l'état du tunnel et répondre à l'alerte à trois heures du matin quand une passerelle redémarre. Cette ligne est souvent ce qui tranche le débat, car c'est la seule qui n'apparaît jamais dans un devis.

Quel que soit votre choix, testez trois flux : celui prévu, un refusé qui doit le rester, et le cas de reprise où la passerelle du hub ou un peering est en panne. Un modèle qui n'explique que le chemin heureux n'a pas été vérifié, il a été démontré.

Vérifiez le choix contre sa propre affirmation

Écrivez une phrase qui nomme le modèle, la frontière et le propriétaire, puis vérifiez que l'état déployé y correspond. Pour le peering, cela signifie les deux états de peering à Connected, la route effective montrant le saut suivant de peering pour le préfixe de destination et aucune passerelle sur le chemin. Pour un VPN de VNet à VNet, cela signifie les deux connexions à Connected, des clés et des politiques concordantes sur les deux passerelles et une route dont le saut suivant est la passerelle de réseau virtuel.

Si les vérifications contredisent la phrase, corrigez d'abord la phrase. L'essentiel de la confusion dans ces conceptions vient d'un hybride que personne n'a décrit : un peering pour le sous-réseau de la charge de travail, un VPN pour un service hérité et une table de routage qui en préfère un en silence.