Pourquoi le VPN point à site Azure ne change pas votre IP publique

Je connecte le client Azure VPN sur un portable Windows, j'ouvre une page d'écho d'adresse et je vois la même adresse publique que celle attribuée par mon routeur domestique. Pendant ce temps, la machine de saut à 10.20.0.4 répond et un nom de point de terminaison privé se résout, donc le tunnel n'est pas cassé. Une passerelle point à site fait exactement ce que dit sa configuration par défaut : elle transporte les préfixes privés et laisse tout le reste sur le lien local. Obtenir une adresse de sortie détenue par Azure est un changement de conception du routage, pas une réparation.

Ce que la passerelle annonce par défaut

La passerelle pousse des routes pour l'espace d'adressage du réseau virtuel, plus les réseaux appairés où le transit de passerelle est autorisé et les préfixes locaux appris via une connexion site à site ou BGP. Il n'y a pas de 0.0.0.0/0 dans cet ensemble. Votre système d'exploitation conserve sa route par défaut sur le Wi-Fi ou l'Ethernet, donc un paquet vers une API publique n'entre jamais dans le tunnel.

L'adresse qu'un client reçoit à l'intérieur du tunnel est un bail privé issu du pool point à site. Elle identifie le client auprès des ressources du VNet ; ce n'est pas une adresse que l'internet peut voir, et elle n'apparaîtra jamais comme source d'une requête sortante vers une API SaaS. Une entrée de liste d'autorisation construite autour de ce bail ne peut pas fonctionner, quelle que soit la durée pendant laquelle vous attendez qu'elle apparaisse dans les journaux du fournisseur.

Tunnel divisé et tunnel forcé côte à côte

Seule la deuxième ligne change l'adresse que voit un service distant. Tout le reste de ce tableau est un coût et une surface d'exploitation que vous acceptez lorsque la sortie doit être inspectée ou traduite à l'intérieur d'Azure. Si quelqu'un vous demande de faire changer l'IP publique, il demande toute la colonne de droite, pas un ajustement du client.

Il existe une option intermédiaire qu'il vaut la peine de nommer avant de reconstruire quoi que ce soit. Une VM de proxy ou de passerelle dans le VNet vous donne une adresse source contrôlée pour les applications que l'on peut pointer vers elle, sans déplacer la route par défaut du client. Cela garde la navigation normale en local et satisfait tout de même un partenaire qui n'a besoin que d'un seul appel d'API provenant d'Azure. Elle échoue lorsque l'exigence porte réellement sur tout le trafic, car tout ce qui ignore le réglage du proxy sort quand même localement.

Faites porter la route par défaut au tunnel

Sur une passerelle de réseau virtuel, la manière prise en charge de diriger tout le trafic internet du client vers le tunnel est d'ajouter des routes personnalisées à la configuration point à site. Deux moitiés couvrent tout l'espace IPv4, et chacune est plus spécifique que la route par défaut locale, donc le client les préfère sans rien supprimer :

Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1

Cette ligne est illustrative plutôt que complète à copier-coller : récupérez d'abord l'objet passerelle avec Get-AzVirtualNetworkGateway et substituez-le à GWOBJ, et confirmez que la référence et le modèle de déploiement acceptent les routes personnalisées avant de l'exécuter. Les mêmes préfixes apparaissent dans le portail sur la page de configuration point à site, qui est l'endroit le plus sûr pour les définir si vous ne scriptez pas déjà la passerelle.

Changer ces préfixes invalide le package client. Téléchargez à nouveau le package client VPN et réinstallez-le, car les routes voyagent à l'intérieur du profil. Un client qui se reconnecte avec son ancien profil conserve l'ancien jeu de routes, et vous pouvez perdre une heure à déboguer un changement qui ne lui est jamais parvenu.

Dans un hub Virtual WAN sécurisé, l'équivalent est une route par défaut dans la table de routes du hub associée à la passerelle point à site, le trafic étant pris par Azure Firewall dans le hub. Le pare-feu traduit les connexions vers internet vers ses propres adresses IP publiques, et c'est de cette traduction que vient la nouvelle adresse de sortie. Lorsqu'un pare-feu possède plusieurs IP publiques, n'importe laquelle d'entre elles peut apparaître comme source, donc une liste d'autorisation doit les contenir toutes.

Les deux conceptions ci-dessus sont IPv4. Les deux préfixes /1 ne font rien pour IPv6, et la prise en charge IPv6 point à site est assez étroite pour que vous deviez tester la combinaison avant de promettre la parité.

Vérifiez la route, puis la sortie

Après avoir réinstallé le package et vous être reconnecté, confirmez que le client a réellement installé les moitiés. Sous Windows, Get-NetRoute -DestinationPrefix 0.0.0.0/1 et la même requête pour 128.0.0.0/1 devraient nommer l'interface du tunnel, et route print affiche les deux à côté de votre route par défaut d'origine. Sous Linux, ip route show doit lister les deux préfixes ; sinon, le profil ne les a jamais transportés.

Vérifiez ensuite à nouveau l'adresse publique depuis le client et lisez le journal du pare-feu pour la même connexion. La source devrait être l'IP publique du pare-feu avec un port traduit. Un client qui sort encore localement alors que les deux routes existent signifie que les paquets ont atteint Azure et sont partis par un autre chemin : une route définie par l'utilisateur sur le sous-réseau de la passerelle, un pare-feu lui-même forcé en tunnel vers le réseau local, ou une stratégie qui abandonne le flux avant la traduction.

Retestez une destination privée dans la même session. Un hôte de saut qui cesse de répondre après le changement est le signe habituel que les nouveaux préfixes ont déplacé quelque chose, soit une route locale plus étroite qui était annoncée auparavant, soit la résolution de noms qui va maintenant vers un résolveur sans redirecteur pour vos zones privées.

Quand laisser le tunnel divisé tranquille

Si l'objectif est seulement d'atteindre une API privée, un point de terminaison privé ou une page d'administration interne, le comportement par défaut est moins coûteux et plus discret. Le tunnel forcé ajoute des heures de pare-feu et des frais de traitement des données, un chemin plus long et un endroit de plus où chaque flux client peut échouer. Il capture aussi bien plus de trafic que la seule destination qui vous intéressait.

Recourez-y lorsque l'exigence est formulée en termes de sortie : un partenaire doit voir une adresse Azure fixe, la sécurité veut que les connexions soient journalisées et inspectées, ou les données doivent sortir par un point contrôlé. Même alors, la conception donne à chaque utilisateur une sortie partagée, donc la responsabilité par utilisateur doit venir de l'identité dans l'application plutôt que de l'adresse source.

Avant de clore le changement, confirmez quatre choses : le package client installé est le nouveau, les deux routes /1 se trouvent sur l'interface du tunnel, une destination privée répond encore, et le journal du service distant montre l'adresse du pare-feu.