Cisco ASA vers Azure VPN : paires de préfixes des sélecteurs de trafic

Le tunnel monte, IKE semble sain, et rien ne le traverse. C'est la forme habituelle d'un problème de sélecteurs ASA vers Azure, et c'est pourquoi j'écris le contrat avant de toucher à l'une des deux consoles. Le contrat tient en quatre choses : les objets qui identifient chaque pair, le modèle de connexion, les paires de préfixes exactes et la vérification qui prouve chaque paire. Trompez-vous et chaque commande suivante débogue une configuration que vous n'auriez pas dû construire. Ce runbook est l'ordre que j'utilise, avec les commandes qui montrent quel objet est réellement faux.

Notez les quatre objets avant de configurer

Commencez par la version et la plateforme ASA, le point de terminaison public, le type et le SKU de la passerelle Azure VPN, et la passerelle de réseau local qui représente votre côté. Ces quatre noms sont le vocabulaire de tout ce qui suit, et chacun a un propriétaire différent quand quelque chose casse.

Si deux d'entre eux sont encore des suppositions, arrêtez-vous. Une mauvaise liste de préfixes sur la passerelle de réseau local n'est pas un problème de réglage.

Choisissez un seul modèle de connexion et cessez de mélanger les modèles de configuration

Une conception crypto map et une conception tunnel interface sont des configurations différentes, et un modèle pour l'une ne devient pas valide pour l'autre en modifiant l'adresse du pair. Notez laquelle vous construisez avant de coller quoi que ce soit, car l'écart apparaît plus tard comme un problème de sélecteurs et non comme une erreur de configuration. Le guide d'interopérabilité ASA de Microsoft couvre les deux schémas et indique quel modèle de passerelle Azure chacun suppose. Si vos notes ne nomment pas le modèle, vous n'avez pas encore de conception.

Une passerelle Azure basée sur les routes avec des sélecteurs de trafic basés sur des stratégies est une option documentée précise, pas la valeur par défaut. Si votre conception en dépend, la conception doit le dire, car le modèle de sélecteurs par défaut basé sur les routes se comporte différemment côté Azure.

Les limites de version font aussi partie du contrat. Un ancien rapport de terrain sur un plafond des domaines de chiffrement est une donnée sur des versions précises, pas une propriété permanente de chaque ASA.

Énumérez les paires de préfixes, pas les agrégats

Écrivez la matrice. A et B locaux vers X et Y Azure font quatre paires, et chacune a besoin soit d'une couverture, soit d'une exclusion explicite. Regrouper A et B dans un seul agrégat inclut aussi tout ce qui se trouve entre eux, et c'est ainsi qu'une conception se dote discrètement d'un trou.

Vérifiez ce que les pairs ont négocié, pas ce que vous avez enregistré. La liste des réseaux locaux et distants sur l'ASA est l'intention ; les CHILD SA sont le résultat.

Quand une paire manque, le correctif est généralement une ligne access-list ou une entrée de sélecteur, pas un nouveau tunnel.

Vérifiez avec des commandes qui nomment l'objet

Sur l'ASA, confirmez la session IKE, puis les SA IPsec, puis les paires de sélecteurs. Chaque commande répond à une question différente, et n'exécuter que la première est la façon dont l'affirmation selon laquelle le tunnel est monté devient une conclusion fausse. Lisez la sortie du pair que vous avez réellement configuré, pas de la SA qui se trouve être la première de la liste. Le côté Azure répond aux mêmes trois questions de son propre point de vue.

show crypto ikev2 sa detailed
show crypto ipsec sa peer 203.0.113.10
show run access-list AZURE-SELECTORS
packet-tracer input inside icmp 10.1.10.10 8 0 10.2.20.20 detailed

Demandez ensuite à Azure l'état de la connexion avec az network vpn-connection show --name <connection> --query connectionStatus. Connected avec zéro octet dans le chemin de données est un problème de sélecteurs, pas un problème de routage.

Testez un flux autorisé par paire, inspectez l'adresse source vue de l'autre côté et essayez une ressource qui devrait être refusée. Ce dernier test est le seul qui prouve que la frontière existe encore.

Gardez la portée du chiffrement distincte de l'autorisation d'accès

Un sélecteur large n'est pas une autorisation. Si la disposition prise en charge est plus large que la stratégie applicative, gardez les services étroits dans les règles du pare-feu et laissez la portée du chiffrement là où elle doit être.

Les routes des charges de travail Azure et les routes de retour locales sont revues séparément. Les annonces BGP, la portée réseau statique et les routes définies par l'utilisateur doivent toutes décrire le même chemin, et aucune ne peut capturer récursivement le transport du pair.

Retour arrière et la preuve qu'il a fonctionné

Conservez la configuration en cours précédente avant de changer les sélecteurs, et sachez l'unique commande qui la remet. Sur l'ASA, cela signifie une copie enregistrée et le chemin de restauration correspondant, pas un souvenir de ce que vous avez modifié. Écrivez la commande de restauration dans le ticket de changement tant que le changement est encore hypothétique. Puis relancez les mêmes trois contrôles : état IKE, paires de SA IPsec, un flux autorisé par paire.

Si une paire échoue encore après la restauration, le changement n'était pas la cause, et vous venez de vous épargner une seconde panne.