Le VPN de site à site fonctionne, mais les journaux de l’ASA n’arrivent pas : vérifiez l’adresse source

Les hôtes internes atteignent le collecteur distant et leurs lignes syslog apparaissent. Les propres messages de l’ASA sur ces mêmes sessions n’arrivent jamais. Ni le collecteur ni le tunnel n’ont de problème, et c’est là toute la confusion. Le pare-feu envoie ses journaux depuis une source que le tunnel n’a jamais été conçu pour protéger.

Ce qui arrive et ce qui n’arrive pas

Commencez par séparer deux flux qui semblent identiques sur un tableau de bord. Le trafic transmis traverse l’ASA : un hôte LAN envoie vers le collecteur, l’ASA le compare à la politique du tunnel, le chiffre, et le collecteur voit l’adresse de l’hôte. Le trafic généré démarre sur l’ASA lui-même : l’équipement construit un paquet syslog, choisit une interface de sortie et une source, puis seulement demande si une politique de tunnel correspond. Le premier flux prouve que le tunnel fonctionne, et il ne dit rien du second.

Un événement mis en tampon sur l’équipement n’est pas non plus une preuve de livraison distante, car le journal peut exister localement et n’avoir jamais été transmis. Vérifiez les compteurs de réception du collecteur avant d’accuser le tunnel, car un compteur vide est une constatation différente d’un compteur qui augmente.

Un message généré n’est pas du trafic transmis

Quand l’ASA émet lui-même un paquet, il ne sert pas de proxy à un hôte LAN. La source vient de l’interface de sortie ou d’un réglage de source explicite, et le paquet entre dans la même recherche de route et les mêmes contrôles de politique que tout ce que l’équipement envoie. Cela signifie que le sélecteur du VPN doit inclure l’adresse que l’ASA utilise réellement, souvent son interface extérieure plutôt qu’un sous-réseau interne.

Si la politique protège 10.20.0.0/24 et que l’ASA utilise son adresse extérieure comme source, le paquet de journal soit part en clair vers un collecteur qu’il ne peut pas atteindre, soit est abandonné. Les deux issues sont identiques du côté du collecteur. Le même raisonnement s’applique au trafic de gestion, et c’est pourquoi management-access est une décision de conception distincte.

Quelle source l’ASA met sur le réseau

Trouvez la source empiriquement plutôt que par supposition. Une capture sur l’interface de sortie pendant un message de test montre la source et la destination réelles, et elle coûte moins de temps que la lecture de trois sections de configuration. Comparez cette adresse au sélecteur local du tunnel.

Certaines versions permettent d’épingler la source des journaux à une interface, et la référence de commandes de votre version fait autorité sur l’existence de cette option et sur ce qu’elle change. Une commande source-interface d’une autre plateforme Cisco n’est pas automatiquement valable sur un ASA.

Si vous changez la source, faites-le délibérément et notez-le, car les ACL du collecteur et toute corrélation fondée sur syslog en dépendent.

Alignez le sélecteur sur le flux de journaux

Une fois la source connue, vérifiez trois choses dans l’ordre : l’ACL de chiffrement ou le sélecteur fondé sur une politique qui décide quel trafic est intéressant, la route qui décide où va le paquet, et toute règle NAT susceptible de réécrire la source avant le chiffrement. Un paquet qui correspond à la route mais pas au sélecteur n’est pas tunnellisé, et un paquet réécrit par NAT peut ne correspondre ni à l’un ni à l’autre.

Le côté collecteur a ses propres exigences : une ACL autorisant la source de l’ASA, une route de retour et un service à l’écoute sur le port configuré. Le transport compte ici aussi, car la journalisation TCP et TLS se comporte différemment d’UDP sur un chemin partiellement bloqué. Changez un élément à la fois, sinon la prochaine capture ne vous dira pas quel changement a compté.

Vérifiez au collecteur, puis consignez la source

Confirmez que le message arrive, puis notez l’adresse source utilisée par l’ASA, le sélecteur qui l’a transporté et la gravité avec laquelle vous avez testé.

Cette consignation transforme la prochaine modification d’ACL du collecteur ou la prochaine édition du sélecteur en une vérification de deux minutes plutôt qu’en une redécouverte. Elle documente aussi lequel des deux flux a été validé un jour, et c’est la partie que la plupart des runbooks oublient. Si le message n’arrive toujours pas, abaissez temporairement le seuil de gravité et testez vers une seule destination.

La FAQ de journalisation de l’ASA de Cisco documente un cas à source externe qui exige la définition correspondante du trafic protégé, et son exemple à source interne inclut à la fois un hôte de journalisation à l’intérieur et management-access à l’intérieur. Traitez la combinaison documentée et le contexte logiciel ensemble, au lieu de supposer qu’une ligne copiée convient à toutes les configurations.

Un tunnel qui transporte du trafic LAN n’est pas un tunnel qui transporte la propre voix du pare-feu.