Por que as peticións TACACS+ da ASA se saltan o túnel VPN da túa sucursal

O túnel da sucursal está activo, os usuarios autentícanse contra o servidor TACACS+ remoto e o inicio de sesión do propio firewall segue esgotando o tempo de espera. A causa non é un fallo do túnel: un túnel LAN-to-LAN transporta o tráfico que coincide cos seus selectores, e o tráfico de xestión que a ASA xera sobre si mesma é un fluxo aparte coa súa propia dirección de orixe. A maioría dos equipos descobren isto durante unha ventá de cambios, cando a única conta de administrador é a que falla. Trate a sesión AAA orixinada pola ASA como un fluxo que hai que deseñar, non como un efecto secundario dunha conectividade que xa funciona.

A ASA é o cliente, e o seu propio tráfico necesita o seu propio camiño

Cando o firewall contacta cun servidor TACACS+, o firewall é un cliente coma calquera outro, agás que ninguén lle configurou unha ruta a propósito. Os seus paquetes orixínanse nunha dirección de interface do dispositivo, xéranse localmente en lugar de reenviarse, e hai que encamiñalos, traducilos e protexelos con políticas igual que o tráfico de usuario. Un túnel de sitio a sitio que protexe unha subrede de usuarios non protexe automaticamente esa orixe de xestión, porque a selección de tráfico baséase en direccións e non en intencións.

Anote a dirección que espera que vexa o servidor. Se non pode dicila nunha soa liña, aínda non ten un deseño.

A interface da liña aaa-server non é decoración

Na ASA, a entrada de host aaa-server toma unha asociación de interface entre parénteses, e a referencia de comandos de host AAA de Cisco descríbea como a interface onde reside o servidor de autenticación. Esa asociación é o que ata a petición a unha interface e á política que esa interface aplica. Escollela pola interface que dea a internet, ou deixar o que houbese da última migración, produce unha dirección de orixe para a que nunca se construíron o servidor remoto nin o túnel.

inside só é a resposta correcta cando a interface nomeada ten a dirección que o seu deseño pretende usar como orixe. Nun dispositivo de sucursal adoita ser así; nun dispositivo con varios segmentos privados pode que non.

Cambiar a asociación significa recrear a entrada

A mesma referencia de comandos documenta unha restrición de edición que atrapa á xente durante as migracións: cambiar a interface dun host existente esixe eliminar e recrear a entrada de host. Unha configuración que parece editada pode non ter surtido efecto, e o seguinte intento de inicio de sesión seguirá saíndo da dirección antiga. Planifíqueo como un borrado e alta cunha copia da entrada orixinal diante, non como un retoque in situ.

Se hai varios servidores definidos, cambie un e próbeo antes de tocar os demais, para que un erro non bloquee todas as rutas administrativas á vez.

Comprobe selectores, tradución e ruta de retorno á vez

Tres cousas teñen que coincidir para que a petición chegue. Os selectores de tráfico do túnel, ou a protección da interface de túnel se usa unha, deben incluír a orixe propia da ASA e a dirección do servidor; unha lista de selectores feita para subredes de usuarios normalmente non o fará. Calquera regra NAT no camiño debe traducir esa orixe de forma coherente, porque o servidor autoriza unha identidade de dispositivo de rede que inclúe a dirección que ve. E a ruta de retorno ten que existir, o que nun túnel baseado en políticas significa que o extremo remoto ten un selector coincidente no sentido contrario.

No lado do servidor, confirme por separado a identidade do dispositivo, o segredo compartido e a política administrativa. TACACS+ mantén a autenticación, a autorización e a contabilidade como operacións distintas, así que unha denegación que chega tras un intercambio completado é unha resposta de política, non un fallo de transporte. Leela como un problema de rede lévao a buscar no sitio equivocado.

Manteña o segredo fóra de capturas, tickets e transcricións mentres depura, e lembre que a dirección de orixe que rexistra o servidor é a que o seu deseño ten que explicar.

Faga o cambio sen quedarse fóra

Use unha consola ou unha ruta de xestión independente mentres cambia a autenticación administrativa remota, e manteña un plan B local aprobado ata que a nova ruta teña cursado un inicio de sesión real. Despois valide de forma estreita: un servidor, un dispositivo, unha autenticación correcta coa dirección de orixe observada nos dous extremos.

Rexiste o fluxo na súa propia páxina: interface e dirección de orixe, servidor remoto, ruta protexida e a persoa propietaria da política de autorización. Así un cambio posterior de interface ou de túnel pode avaliarse sen adiviñar cal dos dous fluxos afecta.