Pourquoi le point à site exige une passerelle Azure VPN basée sur les routes

Une passerelle basée sur des stratégies construit un tunnel IPsec sélectionné par les sélecteurs de trafic et n’a aucune interface à laquelle remettre les routes des clients. La connexion de point à site est une fonction de routage : la passerelle possède un pool d’adresses client et installe des routes vers ces clients dans le réseau virtuel. C’est ce décalage qui explique que le portail n’affiche aucune option pour l’ajouter. Rien sur la passerelle existante ne peut être basculé pour produire l’interface, le changement est donc un remplacement et non une modification de configuration.

L’ordre compte plus que les étapes individuelles. Si la séquence est fausse, la coupure de site à site dépasse la fenêtre de maintenance.

Ce que fait réellement une passerelle basée sur des stratégies

Une passerelle basée sur des stratégies met les paquets en correspondance avec les sélecteurs de trafic configurés sur la connexion et envoie les correspondances dans un seul tunnel. Il n’y a pas d’interface de tunnel avec une adresse, et aucune route par client n’apparaît nulle part dans le réseau virtuel. La table de routage reçoit simplement les préfixes locaux pointant vers la passerelle. Ce modèle suffit à une connexion de site à site entre deux espaces d’adressage fixes.

Une passerelle basée sur les routes fonctionne à l’inverse : elle présente une interface de tunnel, et les routes décident de ce qui y entre. Le point à site, et toute conception dont l’ensemble des pairs change, dépendent de l’existence de cette interface.

Pourquoi le pool de clients a besoin de cette interface

Lorsqu’un ordinateur portable se connecte, la passerelle lui attribue une adresse du pool point à site. Le réseau virtuel a alors besoin d’une route indiquant que cette adresse est joignable via la passerelle. Sans interface de tunnel, il n’y a rien à quoi rattacher cette route.

Le pool provient d’une plage que vous désignez, et la passerelle y puise ses attributions. Si cette plage chevauche le réseau local ou un réseau virtuel appairé, le conflit n’apparaît qu’après la connexion d’un client, ce qui est un mauvais moment pour le découvrir. Réservez le pool avant le début de la migration.

Le type n’est pas non plus un réglage par connexion. Une passerelle a un seul type, et chaque connexion qu’elle porte se comporte en conséquence, un design mixte a donc besoin d’une seconde passerelle et non d’une seconde connexion.

Le type est fixé à la création

Microsoft indique qu’une passerelle de réseau virtuel ne peut pas être changée entre basée sur des stratégies et basée sur les routes après le déploiement. Il n’existe ni commande de conversion ni bascule dans le portail. Créer une seconde passerelle dans le même sous-réseau n’est pas non plus une solution de contournement, car Azure autorise une passerelle par réseau virtuel. La migration consiste donc à supprimer, reconstruire et reconnecter.

Cela intègre aussi la décision de SKU à la même construction. Passer à un SKU plus grand plus tard est un autre remplacement de passerelle avec une autre coupure.

Une passerelle, un GatewaySubnet

La passerelle réside dans un sous-réseau nommé GatewaySubnet, et une seule passerelle l’occupe. Le dimensionnement de ce sous-réseau fait partie de la préparation, car un SKU plus grand demande plus d’adresses et un sous-réseau ne peut pas être réduit ensuite. Notez les paramètres actuels de site à site, la clé partagée, la passerelle de réseau local et les routes effectives avant de toucher à quoi que ce soit. Traitez ensuite la fenêtre comme une panne, car le tunnel de site à site reste hors service jusqu’à la configuration de la nouvelle connexion.

Un ordre de reconstruction qui borne la coupure : créez la passerelle basée sur les routes, recréez la connexion de site à site vers la même passerelle de réseau local, confirmez le tunnel et une requête d’hôte à hôte, puis seulement ajoutez le point à site et générez un nouveau paquet client.

Ce que le remplacement ne corrige pas

Une seconde limite appartient au pair et non à Azure. Un équipement local basé sur des stratégies ne peut atteindre que le réseau virtuel auquel il se connecte et ne peut pas transiter vers d’autres réseaux locaux ou d’autres réseaux virtuels via la même passerelle. Remplacer le côté Azure ne change pas ce que le pair peut sélectionner.

Si l’exigence est réellement un transit entre sites, la réponse est un équipement pair basé sur les routes ou une topologie où chaque destination se termine séparément. Tranchez cela avant de promettre une date, car le remplacement de la passerelle seul ne le fournira pas.

Ordre des opérations et des vérifications

Vérifiez chaque capacité séparément. D’abord l’état du tunnel de site à site et une requête d’hôte à hôte, puis une connexion point à site et une ressource privée, puis tout chemin de transit revendiqué par la conception. Un état vert de la passerelle prouve seulement que l’association de sécurité est montée, rien de plus. Gardez les vérifications dans cet ordre pour qu’un échec désigne l’étape qui l’a introduit.

Régénérez les paquets clients après tout changement de topologie et gardez le pool à l’écart de chaque plage locale et appairée. Les contraintes et les différences de SKU sont rassemblées dans la référence des paramètres Azure VPN Gateway.