Le trafic de retour d’Azure P2S VPN ne fonctionne que dans un sens

L’icône du tunnel est verte, le NSG semble permissif, les routes effectives semblent correctes, et pourtant la VM ne peut toujours pas ouvrir de connexion vers le client connecté. L’hypothèse habituelle est qu’un tunnel point-to-site fonctionnel est symétrique : si le client atteint la VM, la VM atteint le client. Cette hypothèse est l’erreur de raisonnement, pas de configuration. Un tunnel peut transporter un sens d’un flux non sollicité et abandonner l’autre, et le correctif dépend de la couche qui l’abandonne.

Mythe : un tunnel connecté est un tunnel bidirectionnel

Un tunnel VPN est un chemin de stratégie, pas un câble. Chaque direction est comparée à des sélecteurs, des routes et des filtres, et chacun d’eux peut autoriser un sens tout en bloquant l’autre.

En pratique, l’asymétrie est assez courante pour que la direction fasse partie du premier test, et non du dernier. Le client initie, la passerelle suit le flux, et la réponse suit l’état qui a été créé. Une VM qui démarre un nouveau flux n’a pas cet état, elle dépend donc de l’existence d’un chemin de retour explicitement routable et autorisé. Quand ce chemin manque, la tentative de connexion meurt avant qu’une application ne la voie.

Testez la direction avant de tester l’accessibilité

Choisissez une adresse client, une adresse VM et un protocole. Connectez-vous depuis le client et notez le résultat ; lancez ensuite le même test depuis la VM et notez-le aussi. Si le premier réussit et que le second échoue, le pool de clients, l’association de la passerelle et le chemin du client vers le VNet fonctionnent tous.

L’étape suivante, ce sont des preuves, pas davantage de règles. Vérifiez le NSG du sous-réseau de la VM dans les deux sens, lisez les routes effectives sur la carte réseau de la VM et capturez des paquets sur la VM pendant que le client envoie du trafic. Une requête qui arrive sans réponse est un problème de filtre ou de route de retour ; une requête qui n’arrive jamais est un problème de chemin. Ne prenez pas un ping échoué comme preuve que la VM est injoignable, car une stratégie ICMP peut abandonner la réponse alors que TCP fonctionne.

Le chemin de retour IKEv2 point-to-site est le suspect habituel

Dans le rapport Azure à l’origine de cet article, un client pouvait atteindre des VM via IKEv2, mais l’ICMP entrant de la VM vers le client échouait jusqu’à ce que le type de tunnel de la passerelle soit basculé vers OpenVPN. L’auteur du rapport indique que Microsoft a confirmé une limitation du chemin IKEv2 point-to-site, où le trafic de retour d’une VM vers le client n’est pas routé de façon symétrique sauf si le client a initié la session. IKEv2 repose sur des sélecteurs de trafic, et la passerelle n’a pas respecté la direction de retour dans ce cas.

Cela ne fait pas d’OpenVPN le meilleur type de tunnel en général. Cela fait du type de tunnel une variable de la matrice de tests pour cette charge de travail.

Changer de type de tunnel est un changement de service, pas un interrupteur. Chaque client a besoin d’un profil compatible, et la passerelle peut nécessiter un certificat ou une configuration d’authentification différents. Reproduisez le comportement unidirectionnel avec un client de test et une VM de test, changez le type selon un calendrier approuvé, puis répétez les mêmes tests directionnels. Si le comportement survit au changement, le type de tunnel n’était pas la cause et vous avez circonscrit le problème sans toucher à la production.

Mythe : la découverte par diffusion franchit la limite du VNet

Une seconde hypothèse échoue pour une raison sans rapport. Un réseau virtuel Azure ne transporte pas le trafic de diffusion, une VM ne peut donc pas recevoir de trames de diffusion d’un réseau local via une connexion site-to-site ou point-to-site. Les applications qui trouvent leurs pairs par diffusion, comme l’ancienne navigation de fichiers ou certains protocoles de découverte d’appareils, ne verront jamais le côté distant, quelle que soit la façon dont les routes sont écrites.

Remplacez la découverte par diffusion par des noms DNS, un service d’annuaire ou une liste explicite de pairs. Si l’application n’a pas d’alternative unicast, la conception a besoin d’un autre mécanisme de découverte, pas d’un tunnel plus large.

Quoi changer, et comment le prouver

Si le test directionnel n’échoue que sur IKEv2, notez le type de tunnel de la passerelle, le pool d’adresses clients et le test ICMP ou TCP exact, puis évaluez un profil OpenVPN approuvé pour les clients concernés. S’il échoue sur tous les types de tunnel, travaillez le chemin de retour : l’adresse du client doit être routable depuis le sous-réseau de la VM, toute route définie par l’utilisateur doit pointer vers un prochain saut valide, et le pare-feu du client doit accepter le flux entrant. Joignez les preuves NSG et de routage au ticket.

Vérifiez avec l’application, pas avec ping. Un échange ICMP réussi après un changement ne dit rien sur le port du service, son authentification ou sa résolution de noms. Répétez le test après une reconnexion, car un client qui reçoit une autre adresse du pool peut changer le résultat. Répétez-le ensuite une fois de plus après que le client s’est endormi et réveillé, car c’est dans une session reprise que le comportement unidirectionnel réapparaît souvent.