VPN site à site Azure avec un pair derrière NAT : liste de vérification

Effectuez ces vérifications dans l’ordre et arrêtez-vous à la première qui échoue. La plupart des signalements selon lesquels Azure ne prend pas en charge un appareil derrière NAT se révèlent être une adresse de pair que Azure ne peut pas joindre, ou un tunnel qui ne s’initie jamais du bon côté. Le transport externe et le routage interne sont deux problèmes différents, et les mélanger fait perdre un après-midi. Chaque étape ci-dessous produit une observation que vous pouvez transmettre à quelqu’un d’autre.

Étape 1 : confirmez que le pair est bien derrière NAT

Comparez l’adresse de l’interface WAN de l’appareil à l’adresse que Azure voit pour lui. Si elles diffèrent, quelque chose traduit, et ce traducteur fait désormais partie de votre conception VPN. Demandez au fournisseur si la correspondance est statique ou partagée, car une correspondance partagée change ce sur quoi vous pouvez compter. Un appareil doté d’une adresse WAN privée et sans redirection est un cas différent de celui qui se trouve derrière un NAT d’opérateur avec une correspondance publique stable.

Si les deux adresses correspondent, arrêtez-vous ici : NAT n’est pas votre problème et le reste de cette liste n’aidera pas.

Notez les deux adresses et le modèle du traducteur dans le ticket. Cette seule ligne évite la prochaine série de questions sur la raison pour laquelle le pair configuré ne répond pas.

Étape 2 : accordez-vous sur qui initie

La FAQ Azure VPN Gateway indique la prise en charge de NAT-T et ajoute que l’appareil local doit initier le tunnel IPsec lorsqu’il se trouve derrière NAT. Cela correspond au fonctionnement de la traduction avec état, puisque le traducteur conserve une correspondance parce que l’appareil interne a envoyé le premier paquet. Si Azure est censé initier et que rien n’arrive pour créer cette correspondance, le tunnel ne démarre jamais.

Configurez le pair de sorte qu’une erreur de type répondant uniquement soit évidente, et vérifiez si l’appareil réessaie de lui-même ou a besoin d’un déclencheur. Certains appareils ne montent un tunnel que lorsque du trafic intéressant apparaît, ce qui est acceptable jusqu’à ce que le trafic intéressant soit une sonde de santé qui n’arrive jamais.

Observez l’échange IKE sur l’appareil lors d’une initiation manuelle ; le silence à cet endroit est une réponse de routage ou de pare-feu, pas une réponse d’Azure.

Étape 3 : obtenez la bonne adresse de pair

Azure a besoin d’une adresse publique joignable pour le pair dans son objet de passerelle de réseau local, normalement l’adresse publique du traducteur plutôt que l’adresse interne de l’appareil. L’identité avec laquelle l’appareil s’authentifie est un champ distinct et peut légitimement différer de l’adresse que Azure appelle. Gardez les deux séparées, car les inverser produit un échec d’authentification qui ressemble exactement à un problème de NAT.

Si l’adresse publique change, cet objet doit changer avec elle. Un nom qui résout vers une adresse obsolète est pire qu’une adresse statique que vous devez mettre à jour manuellement.

Notez les trois valeurs : adresse locale de l’appareil, adresse publique traduite, identité de pair configurée.

Étape 4 : n’ouvrez que les ports dont NAT-T a besoin

NAT-T transporte ESP dans UDP, et le RFC 3948 décrit cette encapsulation avec le port 4500 utilisé après la négociation initiale sur le port 500. Votre pare-feu et le traducteur doivent tous deux autoriser l’échange et son trafic de retour. Autoriser un port TCP sans rapport ne prouve rien sur ce chemin, et une règle qui autorise la sortie mais pas la réponse échouera quand même.

Une redirection statique de port entrant n’est pas automatiquement nécessaire lorsque le pair initie et que le traducteur conserve l’état. Elle le devient lorsque la correspondance est instable ou lorsque quelque chose sur le chemin expire l’état agressivement.

Capturez une fois des deux côtés du traducteur ; la différence d’encapsulation est immédiatement visible.

Étape 5 : séparez le transport externe du routage interne

Un tunnel qui s’établit et ne transporte rien est un problème de routage, pas un problème NAT-T. Les sites ont toujours besoin de sélecteurs de trafic compatibles, d’espaces d’adresses correspondants, de règles d’accès et d’un chemin de retour pour les réseaux d’applications. Rien de tout cela n’est fourni par un échange IKE réussi.

Si les deux sites utilisent des plages privées qui se chevauchent, la traduction à l’intérieur du tunnel est une conception distincte avec ses propres règles. Ne renumérotez pas un sous-réseau simplement parce que la passerelle externe se trouve derrière un routeur domestique.

Classez la défaillance par étape avant de changer quoi que ce soit, et conservez cette classification dans le ticket afin que la personne suivante commence là où vous vous êtes arrêté.