Per què les peticions TACACS+ de l'ASA no passen pel túnel VPN de la sucursal
Un túnel de sucursal només transporta el que coincideix amb els seus selectors. Les peticions TACACS+ pròpies de l'ASA necessiten una associació d'interfície explícita, una adreça d'origen i un camí de retorn.
El túnel de la sucursal està actiu, els usuaris s'autentiquen contra el servidor TACACS+ remot, i l'inici de sessió del propi tallafoc encara expira. El motiu no és un error del túnel: un túnel LAN-to-LAN transporta el trànsit que coincideix amb els seus selectors, i el trànsit de gestió que l'ASA genera sobre si mateix és un flux separat amb la seva pròpia adreça d'origen. La majoria d'equips ho descobreixen durant una finestra de canvis, quan l'únic compte d'administrador és el que falla. Tracteu la sessió AAA originada per l'ASA com un flux que heu de dissenyar, no com un efecte secundari d'una connectivitat que ja funciona.
L'ASA és el client, i el seu propi trànsit necessita el seu propi camí
Quan el tallafoc contacta amb un servidor TACACS+, el tallafoc és un client com qualsevol altre, tret que ningú li ha configurat una ruta deliberadament. Els seus paquets s'originen en una adreça d'interfície del dispositiu, es generen localment en lloc de reenviar-se, i s'han d'encaminar, traduir i protegir amb polítiques igual que el trànsit d'usuari. Un túnel de lloc a lloc que protegeix una subxarxa d'usuaris no protegeix automàticament aquest origen de gestió, perquè la selecció de trànsit es basa en adreces i no en intencions.
Anoteu l'adreça que espereu que vegi el servidor. Si no la podeu enunciar en una línia, encara no teniu un disseny.
La interfície de la línia aaa-server no és decoració
A l'ASA, l'entrada d'amfitrió aaa-server pren una associació d'interfície entre parèntesis, i la referència de comandes d'amfitrió AAA de Cisco la descriu com la interfície on resideix el servidor d'autenticació. Aquesta associació és el que lliga la petició a una interfície i a la política que aquesta interfície aplica. Triar-la per la interfície que dona a internet, o deixar-hi el que hi havia de l'última migració, produeix una adreça d'origen per a la qual el servidor remot i el túnel no es van construir mai.
inside només és la resposta correcta quan la interfície esmentada té l'adreça que el vostre disseny pretén utilitzar com a origen. En un dispositiu de sucursal sovint ho és; en un dispositiu amb diversos segments privats potser no.
Canviar l'associació vol dir recrear l'entrada
La mateixa referència de comandes documenta una restricció d'edició que atrapa la gent durant les migracions: canviar la interfície d'un amfitrió existent requereix eliminar i recrear l'entrada d'amfitrió. Una configuració que sembla editada pot no haver pres efecte, i el següent intent d'inici de sessió encara sortirà de l'adreça antiga. Planifiqueu-ho com una eliminació i addició amb una còpia de l'entrada original al davant, no com un retoc in situ.
Si hi ha diversos servidors definits, canvieu-ne un i proveu-lo abans de tocar els altres, perquè un error no bloquegi tots els camins administratius alhora.
Comproveu els selectors, la traducció i el camí de retorn alhora
Tres coses han de coincidir perquè la petició arribi. Els selectors de trànsit del túnel, o la protecció de la interfície de túnel si en feu servir una, han d'incloure l'origen propi de l'ASA i l'adreça del servidor; una llista de selectors feta per a subxarxes d'usuaris normalment no ho farà. Qualsevol regla NAT del camí ha de traduir aquest origen de manera consistent, perquè el servidor autoritza una identitat de dispositiu de xarxa que inclou l'adreça que veu. I el camí de retorn ha d'existir, cosa que en un túnel basat en polítiques significa que l'extrem remot té un selector coincident en l'altre sentit.
Al costat del servidor, confirmeu per separat la identitat del dispositiu, el secret compartit i la política administrativa. TACACS+ manté l'autenticació, l'autorització i la comptabilitat com a operacions diferents, així que una denegació que arriba després d'un intercanvi complet és una resposta de política, no un error de transport. Llegir-la com un problema de xarxa us fa buscar al lloc equivocat.
Manteniu el secret fora de les captures, els tiquets i les transcripcions mentre depureu, i recordeu que l'adreça d'origen que el servidor registra és la que el vostre disseny ha d'explicar.
Feu el canvi sense quedar-vos fora
Feu servir una consola o un camí de gestió independent mentre canvieu l'autenticació administrativa remota, i manteniu un pla B local aprovat fins que el camí nou hagi portat un inici de sessió real. Després valideu de manera estreta: un servidor, un dispositiu, una autenticació correcta amb l'adreça d'origen observada als dos extrems.
Registreu el flux en una pàgina pròpia: interfície i adreça d'origen, servidor remot, camí protegit i la persona que posseeix la política d'autorització. Així un canvi posterior d'interfície o de túnel es pot avaluar sense endevinar quin dels dos fluxos afecta.