VPN S2S Azure connecté mais sans trafic : lisez le journal IKE

Le portail affiche Connected, le tunnel possède un compteur de disponibilité, et un trace depuis votre machine virtuelle meurt au deuxième saut. L’état de connexion décrit la négociation IKE et IPsec, pas si un seul paquet survit à la couche de stratégies d’un côté ou de l’autre. Deux défauts expliquent la plupart de ces tickets, et aucun des deux ne se répare en changeant une route Azure. Les deux sont déjà écrits dans le journal produit par la passerelle, et c’est pourquoi je commence là plutôt que dans la table de routage.

Ce que Connected certifie réellement

Une connexion site à site connectée signifie que les phases 1 et 2 sont terminées et que les associations de sécurité sont actives. C’est une affirmation sur la négociation : les deux pairs se sont accordés sur une proposition, ont échangé des clés et ont installé la paire de SA. Elle ne dit rien sur la correspondance entre les sélecteurs de trafic et les sous-réseaux que vous croyez protégés, ni sur le fait que le côté distant routera le paquet quelque part après l’avoir déchiffré. Un tunnel peut rester actif des semaines en abandonnant chaque flux intéressant, et c’est exactement le schéma qui pousse à reconstruire une passerelle saine.

Les deux défauts à vérifier en premier sont un pair qui propose AH au lieu d’ESP, et un réseau virtuel numéroté dans un espace que la passerelle ne traitera pas comme interne.

Ouvrez le journal exporté avant de toucher aux routes

Dans le portail, ouvrez la passerelle de réseau virtuel et lancez l’opération VPN troubleshoot sur la connexion, puis téléchargez le paquet qu’elle produit et décompressez-le. À l’intérieur se trouve un journal IKE avec les échanges de phase 1 et de phase 2, horodaté et lisible en texte brut. Cherchez-y la ligne transform plutôt que de lire de haut en bas, car l’entrée intéressante se trouve généralement quelques centaines de lignes plus loin. Si vous n’avez pas accès au portail, les mêmes diagnostics apparaissent dans la destination de journal de la passerelle lorsque les paramètres de diagnostic sont activés.

Deux entrées portent l’essentiel de la valeur. La première se lit à peu près expected ESP with combined authentication and cipher, received AH. La seconde est une erreur de payload invalide pendant l’échange IKE, ce qui signifie généralement un champ de proposition mal formé ou non pris en charge.

Les deux décrivent ce que l’équipement local a proposé, donc les deux sont des réglages côté pair. Régénérer le côté Azure de la connexion ne change pas la proposition envoyée par votre pare-feu, et le faire quand même est l’heure la plus souvent perdue dans ce flux de travail. Sur le pair, réglez la phase 2 sur ESP avec authentification et chiffrement combinés et laissez-la négocier l’algorithme, puis vérifiez si une case du fournisseur nommée quelque chose comme combined mode sélectionne silencieusement une proposition AH en dessous.

Confirmez l’espace d’adressage du réseau virtuel

La passerelle s’attend à ce que le réseau virtuel se trouve dans des plages privées. Un réseau numéroté dans un bloc public, par exemple commençant par 111.x, peut monter le tunnel alors qu’Azure refuse de traiter cet espace comme interne, si bien que la connexion semble saine et qu’aucun flux n’est accepté. Confirmez l’espace d’adressage avant de passer une après-midi sur les sélecteurs. Si la numérotation est une exigence ferme issue d’une ancienne allocation, le correctif est un changement de plan d’adressage et non une autre passerelle.

Notez le chevauchement avec les plages locales pendant que vous êtes dans le panneau d’espace d’adressage, car des préfixes qui se chevauchent produisent une panne différente qui paraît similaire depuis le client.

Vérifiez les préfixes dans les deux sens

La ressource de passerelle de réseau local contient les préfixes locaux, et ils doivent correspondre aux sous-réseaux que l’équipement distant protège réellement. Un résumé qui inclut des adresses que l’équipement abandonne laissera passer certains flux et échouera sur d’autres, ce qui se lit comme une panne de routage intermittente plutôt qu’un écart de configuration. Vérifiez aussi le côté distant : une extrémité qui liste un /16 alors que l’autre liste trois /24 à l’intérieur est l’échec partiel classique. Aucune des deux listes n’est autoritative à elle seule, alors comparez-les côte à côte au lieu de faire confiance à celle que vous voyez.

Un changement de préfixe n’est pas toujours pris en compte tout seul, alors prévoyez de réenregistrer ou de recréer l’objet de connexion, puis confirmez que les nouveaux préfixes apparaissent des deux côtés.

Testez un chemin, pas un ping

Le trace qui distingue un tunnel qui fonctionne d’une route qui fonctionne ressemble à ceci : le premier saut est la passerelle locale, puis quelques sauts qui ne répondent pas, puis l’hôte distant répond. Si le trace n’atteint jamais l’hôte, testez le port TCP que l’application utilise réellement, car ICMP est filtré assez souvent pour qu’un ping échoué prouve très peu. Lancez le même trace depuis un hôte distant vers une machine virtuelle dans Azure. L’asymétrie entre les deux résultats est le moyen le plus rapide de trouver une route de retour manquante ou une règle qui n’autorise qu’un seul sens.

Écrivez la proposition du pair, les deux espaces d’adressage et l’heure de création de la connexion dans le ticket, afin que l’ingénieur suivant sache quelles valeurs ont été reconstruites et lesquelles n’ont jamais été touchées.

Si le journal revient vide, la passerelle ne termine peut-être pas du tout votre connexion. Confirmez que l’adresse du pair sur la passerelle de réseau local correspond à l’équipement depuis lequel vous lisez le journal, car deux passerelles dans un même abonnement se confondent facilement lors d’une reconstruction. Cette erreur coûte une journée et ne laisse aucune trace dans aucun journal.