La vérification de flux IP d’Azure indique autorisé, mais le VPN échoue toujours

Tunnel site à site connecté, VM en bonne santé, le client local ne reçoit rien. Vous ouvrez Network Watcher, lancez la vérification de flux IP, et elle indique Access allowed, donc le ticket est fermé comme un problème de VPN. Ce résultat ne signifie pas ce qu’il paraît, car la vérification de flux IP évalue les règles de sécurité du flux que vous avez décrit et ne teste jamais si Azure a une route vers votre préfixe local.

La question du filtrage et celle du routage sont distinctes, et Network Watcher y répond avec des outils différents. Savoir laquelle vous avez posée représente l’essentiel du diagnostic.

Ce que la vérification de flux IP décide réellement

La vérification de flux IP prend une VM, une interface réseau, une direction, les valeurs du quintuplet et un protocole, puis rapporte la décision de la règle NSG et de l’administrateur de sécurité pour ce flux. Elle fonctionne sur TCP et UDP, ce n’est donc pas un testeur de règles ICMP et un ping bloqué ne prouve rien sur votre service. Donnez-lui le flux réel plutôt qu’une supposition. Une connexion entrante depuis le site local vers un port de base de données est une description différente d’une connexion sortante initiée par la VM.

Si la passerelle traduit les adresses, utilisez l’adresse source qui atteint la frontière que vous évaluez, pas celle de la configuration du client. Lisez aussi le résultat pour ce qu’il est. Access allowed signifie que la couche de filtrage autoriserait le paquet s’il arrivait, et rien de plus.

Ce qu’elle ne peut pas vous dire, c’est la route choisie par Azure, si le pare-feu de l’invité autorise le port ou si quelque chose écoute. Cela vit à d’autres couches.

Ce qu’ajoutent le saut suivant et les routes effectives

Le saut suivant répond à une question de transfert : pour cette destination, quel type de saut suivant Azure choisit, à quelle adresse, depuis quelle table de routes. Les routes effectives listent ce que la NIC possède réellement. Exécutez les deux et vous obtenez le chemin côté Azure qu’une vérification de flux IP verte laisse vide.

La vue d’ensemble de la vérification de flux IP de Microsoft indique directement la portée du filtrage, tandis que les pages sur le saut suivant et le diagnostic de routage couvrent le côté transfert. Citez la bonne page lorsque vous rédigez la conclusion.

Les commandes sont assez courtes pour être exécutées depuis un shell. az network nic show-effective-route-table liste les routes appliquées à l’interface. az network watcher show-next-hop avec une source et une destination renvoie le saut sélectionné. Comparez le préfixe qui vous intéresse à cette table, puis confirmez quelle entrée gagne.

Parcourez le chemin de retour depuis la NIC de la VM

Faites-le depuis la NIC de la VM cible, pour le préfixe du client local, pas pour Internet. Le chemin de retour est l’endroit où se cachent les pannes site à site, car une vérification de l’état du tunnel indique seulement que les associations de sécurité sont établies.

Si la route attendue manque, vérifiez les préfixes distants fournis par la configuration de la passerelle, la conception de connectivité du VNet et tout paramètre de propagation de routes. Un objet de passerelle de réseau local décrit le côté local ; son existence ne prouve pas que chaque préfixe requis est présent et préféré sur la NIC. Ce sont des faits différents, et un seul apparaît dans un résumé du portail.

Lisez le type de saut suivant au lieu de copier un exemple

Un chemin via une passerelle VPN gérée affiche normalement VirtualNetworkGateway comme type de saut suivant. VirtualAppliance décrit une autre conception de transfert, généralement un pare-feu ou une appliance réseau virtuelle.

Ne créez pas de route d’appliance vers un point de terminaison VPN deviné parce qu’une ancienne réponse de forum utilisait ce type. Si une route définie par l’utilisateur remplace le chemin prévu, trouvez son propriétaire et son objectif avant de la modifier. Une seconde NIC peut aussi changer l’interface utilisée par l’invité, et la retirer peut casser un autre service au lieu de corriger cette route.

Passez à la frontière qui échoue encore

Lorsque le filtrage et le routage correspondent tous deux à la conception, la panne est ailleurs. Vérifiez la table de routes de l’invité, son pare-feu et si l’écouteur est lié à l’adresse attendue. Vérifiez ensuite les sélecteurs de trafic protégé du VPN et le chemin de réponse local. Chacun d’eux est un test distinct avec un résultat distinct.

Terminez par une requête applicative autorisée et des observations des deux extrémités. Un résultat allow et un saut suivant correct sont deux éléments de preuve, pas la preuve que la connexion a réussi.