Pourquoi les requêtes TACACS+ de l'ASA contournent le tunnel VPN de votre agence

Le tunnel de l'agence est opérationnel, les utilisateurs s'authentifient auprès du serveur TACACS+ distant, et la connexion du pare-feu lui-même expire encore. La cause n'est pas un défaut du tunnel : un tunnel LAN-to-LAN transporte le trafic qui correspond à ses sélecteurs, et le trafic de gestion que l'ASA génère sur elle-même est un flux distinct avec sa propre adresse source. La plupart des équipes le découvrent pendant une fenêtre de changement, quand le seul compte administrateur est celui qui échoue. Traitez la session AAA initiée par l'ASA comme un flux à concevoir, pas comme un effet secondaire d'une connectivité qui fonctionne déjà.

L'ASA est le client, et son propre trafic a besoin de son propre chemin

Lorsque le pare-feu contacte un serveur TACACS+, il est un client comme un autre, sauf que personne ne lui a délibérément configuré de route. Ses paquets partent d'une adresse d'interface de l'équipement, ils sont générés localement plutôt que transmis, et ils doivent être routés, traduits et protégés par stratégie exactement comme le trafic des utilisateurs. Un tunnel site à site qui protège un sous-réseau d'utilisateurs ne protège pas automatiquement cette source de gestion, car la sélection du trafic repose sur des adresses et non sur une intention.

Notez l'adresse que vous attendez que le serveur voie. Si vous ne pouvez pas l'énoncer en une ligne, vous n'avez pas encore de conception.

L'interface de la ligne aaa-server n'est pas un ornement

Sur l'ASA, l'entrée d'hôte aaa-server prend une association d'interface entre parenthèses, et la référence des commandes d'hôte AAA de Cisco la décrit comme l'interface où réside le serveur d'authentification. C'est cette association qui lie la requête à une interface et à la stratégie que cette interface applique. La choisir selon l'interface qui regarde vers internet, ou laisser ce qui restait de la dernière migration, produit une adresse source pour laquelle le serveur distant et le tunnel n'ont jamais été conçus.

inside n'est la bonne réponse que lorsque l'interface nommée porte l'adresse que votre conception compte utiliser comme source. Sur un équipement d'agence, c'est souvent le cas ; sur un équipement comportant plusieurs segments privés, peut-être pas.

Changer l'association signifie recréer l'entrée

La même référence de commandes documente une contrainte de modification qui piège les gens lors des bascules : changer l'interface d'un hôte existant impose de supprimer puis de recréer l'entrée d'hôte. Une configuration qui semble modifiée peut ne pas avoir pris effet, et la tentative de connexion suivante partira encore de l'ancienne adresse. Planifiez cela comme une suppression suivie d'un ajout, avec une copie de l'entrée d'origine sous les yeux, et non comme un ajustement sur place.

Si plusieurs serveurs sont définis, modifiez-en un et testez-le avant de toucher aux autres, afin qu'une erreur ne verrouille pas toutes les voies d'administration d'un coup.

Vérifiez sélecteurs, traduction et chemin de retour ensemble

Trois choses doivent concorder pour que la requête arrive. Les sélecteurs de trafic du tunnel, ou la protection de l'interface de tunnel si vous en utilisez une, doivent inclure la source propre de l'ASA et l'adresse du serveur ; une liste de sélecteurs construite pour des sous-réseaux d'utilisateurs ne le fera généralement pas. Toute règle NAT sur le chemin doit traduire cette source de façon cohérente, car le serveur autorise une identité d'équipement réseau qui inclut l'adresse qu'il voit. Et le chemin de retour doit exister, ce qui, sur un tunnel basé sur des stratégies, signifie que l'extrémité distante possède un sélecteur correspondant dans l'autre sens.

Côté serveur, confirmez séparément l'identité de l'équipement, le secret partagé et la stratégie d'administration. TACACS+ conserve l'authentification, l'autorisation et la comptabilité comme des opérations distinctes, si bien qu'un refus qui arrive après un échange terminé est une réponse de stratégie, pas une panne de transport. Le lire comme un problème réseau vous fait chercher au mauvais endroit.

Gardez le secret hors des captures, des tickets et des transcriptions pendant le débogage, et rappelez-vous que l'adresse source que le serveur journalise est celle que votre conception doit expliquer.

Faites le changement sans vous enfermer dehors

Utilisez une console ou un chemin de gestion indépendant pendant que vous modifiez l'authentification administrative distante, et conservez une solution de repli locale approuvée jusqu'à ce que le nouveau chemin ait porté une véritable connexion. Validez ensuite de façon étroite : un serveur, un équipement, une authentification réussie avec l'adresse source observée aux deux extrémités.

Consignez le flux sur sa propre page : interface et adresse d'origine, serveur distant, chemin protégé et la personne propriétaire de la stratégie d'autorisation. Un changement ultérieur d'interface ou de tunnel pourra alors être évalué sans deviner lequel des deux flux il affecte.