Perché le richieste TACACS+ dell'ASA aggirano il tunnel VPN della tua filiale

Il tunnel della filiale è attivo, gli utenti si autenticano sul server TACACS+ remoto, e l'accesso del firewall stesso va ancora in timeout. La causa non è un difetto del tunnel: un tunnel LAN-to-LAN trasporta il traffico che corrisponde ai suoi selettori, e il traffico di gestione che l'ASA genera su se stessa è un flusso separato con il proprio indirizzo sorgente. La maggior parte dei team lo scopre durante una finestra di cambiamento, quando l'unico account amministratore è quello che fallisce. Trattate la sessione AAA avviata dall'ASA come un flusso da progettare, non come un effetto collaterale di una connettività che già funziona.

L'ASA è il client, e il suo traffico ha bisogno del proprio percorso

Quando il firewall contatta un server TACACS+, il firewall è un client come qualsiasi altro, tranne per il fatto che nessuno gli ha configurato deliberatamente una rotta. I suoi pacchetti partono da un indirizzo di interfaccia del dispositivo, vengono generati localmente anziché inoltrati, e devono essere instradati, tradotti e protetti da policy esattamente come il traffico utente. Un tunnel site-to-site che protegge una sottorete utenti non protegge automaticamente quella sorgente di gestione, perché la selezione del traffico si basa su indirizzi e non su intenzioni.

Scrivete l'indirizzo che vi aspettate che il server veda. Se non riuscite a dichiararlo in una riga, non avete ancora un progetto.

L'interfaccia nella riga aaa-server non è decorazione

Sull'ASA, la voce host aaa-server accetta un'associazione di interfaccia tra parentesi, e la referenza dei comandi host AAA di Cisco la descrive come l'interfaccia in cui risiede il server di autenticazione. È quell'associazione che lega la richiesta a un'interfaccia e alla policy che quell'interfaccia applica. Sceglierla in base all'interfaccia rivolta verso internet, o lasciare quello che c'era dall'ultima migrazione, produce un indirizzo sorgente per il quale il server remoto e il tunnel non sono mai stati costruiti.

inside è la risposta corretta solo quando l'interfaccia indicata possiede l'indirizzo che il vostro progetto intende usare come sorgente. Su un dispositivo di filiale spesso lo è; su un dispositivo con più segmenti privati forse no.

Cambiare l'associazione significa ricreare la voce

La stessa referenza dei comandi documenta un vincolo di modifica che coglie le persone durante i passaggi: cambiare l'interfaccia su un host esistente richiede di rimuovere e ricreare la voce host. Una configurazione che sembra modificata potrebbe non essere entrata in vigore, e il tentativo di accesso successivo partirà ancora dal vecchio indirizzo. Pianificatelo come una cancellazione e aggiunta con una copia della voce originale davanti a voi, non come una modifica sul posto.

Se sono definiti più server, cambiatene uno e provatelo prima di toccare gli altri, così un errore non blocca tutti i percorsi amministrativi insieme.

Controllate selettori, traduzione e percorso di ritorno insieme

Tre cose devono coincidere perché la richiesta arrivi. I selettori di traffico del tunnel, o la protezione dell'interfaccia tunnel se ne usate una, devono includere la sorgente propria dell'ASA e l'indirizzo del server; un elenco di selettori costruito per sottoreti utenti di solito non lo farà. Qualsiasi regola NAT sul percorso deve tradurre quella sorgente in modo coerente, perché il server autorizza un'identità di dispositivo di rete che include l'indirizzo che vede. E il percorso di ritorno deve esistere, il che su un tunnel basato su policy significa che l'estremità remota ha un selettore corrispondente nella direzione opposta.

Sul lato server, confermate separatamente l'identità del dispositivo, il segreto condiviso e la policy amministrativa. TACACS+ mantiene autenticazione, autorizzazione e accounting come operazioni distinte, quindi un rifiuto che arriva dopo uno scambio completato è una risposta di policy, non un guasto di trasporto. Leggerlo come problema di rete vi manda a cercare nel posto sbagliato.

Tenete il segreto fuori da catture, ticket e trascrizioni durante il debug, e ricordate che l'indirizzo sorgente che il server registra è quello che il vostro progetto deve spiegare.

Fate il cambiamento senza chiudervi fuori

Usate una console o un percorso di gestione indipendente mentre cambiate l'autenticazione amministrativa remota, e tenete un fallback locale approvato finché il nuovo percorso non avrà portato un accesso reale. Poi validate in modo stretto: un server, un dispositivo, un'autenticazione riuscita con l'indirizzo sorgente osservato a entrambe le estremità.

Registrate il flusso su una pagina propria: interfaccia e indirizzo di origine, server remoto, percorso protetto e la persona che possiede la policy di autorizzazione. Un successivo cambio di interfaccia o di tunnel potrà così essere valutato senza indovinare quale dei due flussi riguarda.