Comment modéliser un flux VPN avec ASA packet-tracer

Packet-tracer sur un ASA répond à une question étroite : ce paquet, qui entre ici avec ce tuple, serait-il autorisé, et où irait-il. Il ne répond pas si l'extrémité distante reçoit quoi que ce soit. L'erreur habituelle est de fournir un tuple IKE externe alors que ce que vous voulez tester est l'application qui circule dans le tunnel. Corrigez d'abord le tuple, lisez les phases, puis obtenez des preuves réelles pour tout ce que le simulateur ne peut pas voir.

La démonstration ci-dessous suppose que l'ACL, la règle NAT et le contexte tunnel-group sont devant vous. Sans eux, la sortie décrit une politique que vous ne pouvez pas vérifier.

Étape 1 : écrivez le flux interne en mots simples

Décrivez l'application avant de taper quoi que ce soit. Un hôte de l'intérieur qui ouvre SSH vers un serveur derrière la passerelle distante est un flux TCP interne avec un port source précis. C'est le flux que l'ACL et le filtre VPN évaluent, donc c'est le flux que vous tapez.

Écrivez-le comme une phrase, puis traduisez-le champ par champ :

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Étape 2 : choisissez l'entrée et la direction

L'entrée est l'interface sur laquelle le paquet arrive, pas celle par laquelle il repart. Pour un hôte LAN qui initie, c'est l'interface inside. Pour le paquet de retour de la même session, c'est l'interface outside, et le tuple s'inverse. Écrire la destination comme la source est la deuxième façon la plus courante d'obtenir un ALLOW convaincant mais hors sujet.

Les ports ont aussi une direction. Le port du service appartient au champ destination pour une requête initiée, et le port éphémère du client appartient au champ source. Un modèle avec destination TCP 500 décrit une application TCP qui écoute sur 500 ; il ne devient pas un test IKE parce que le nombre apparaît dans la commande.

Étape 3 : lisez les phases dans l'ordre

Chaque phase de la sortie est une décision avec un propriétaire : recherche de route, ACL, NAT, puis sélection VPN ou tunnel. Lisez-les dans l'ordre imprimé et arrêtez-vous à la première phase qui contredit la conception.

NAT surprend beaucoup de gens. Si la source traduite tombe en dehors de l'ACL crypto qui sélectionne le trafic pour le tunnel, le flux peut être autorisé et jamais encapsulé. La trace imprime l'adresse traduite, alors comparez-la au trafic intéressant du tunnel plutôt qu'à l'adresse d'origine.

Étape 4 : vérifiez quels contournements vous avez sélectionnés

La forme detailed accepte des options qui sautent des vérifications, et Cisco documente une option bypass-checks couvrant l'ACL, le filtre VPN, uRPF et les vérifications d'usurpation IPsec. Un ALLOW obtenu avec ces contournements dit que la route et le NAT fonctionneraient, non que la politique admettrait un paquet réel. Notez les options à côté du résultat.

Si vous avez besoin de la réponse de politique, exécutez-la sans les contournements. Si vous isolez une question de routage, exécutez-la avec eux et étiquetez le résultat comme réponse de routage.

Étape 5 : comblez l'écart avec l'échange réel

Une autorisation simulée s'arrête à l'ASA. Que la passerelle distante ait déchiffré le paquet, que le serveur ait accepté la connexion et qu'une réponse soit revenue sont des observations distinctes. Utilisez des compteurs de point de terminaison ou une capture étroite sur un chemin approuvé.

Certaines options de trace et de replay transmettent des paquets ou conservent l'état. Suivez le comportement documenté pour votre version et votre procédure de diagnostic approuvée au lieu de traiter chaque variante comme une simple consultation en lecture.

Ce que la trace ne peut toujours pas vous dire

Gardez quatre choses dans une note : le tuple, la règle NAT correspondante, le tunnel ou la politique qui devrait porter le flux, et l'observation propre à la direction. Sans elles, un ingénieur ultérieur ne peut pas distinguer une décision de politique locale d'un plan de contrôle établi et d'un service qui fonctionne. Un premier échec suivi d'un succès ne prouve pas non plus que le tunnel ait dû monter entre-temps ; notez la phase et le changement d'état.

Commencez par le tuple interne, arrêtez-vous à la première phase qui contredit la conception, et seulement ensuite allez chercher des preuves de point de terminaison. La trace est un oracle de politique, pas un accusé de livraison.