SSH verso un’ASA remota tramite la VPN del sito: passo dopo passo

Puntate un client SSH all’indirizzo interno dell’ASA remota e la sessione muore alla connessione. Il firewall risponde dal proprio sito, il tunnel compare, eppure nulla ascolta sulla porta 22. Nella maggior parte di questi casi il pacchetto non raggiunge mai l’ammissione di gestione, perché il percorso testato non è mai stato progettato come percorso di gestione. Seguite il flusso qui sotto in ordine e il guasto smette di spostarsi.

Scegliete l’indirizzo che state davvero amministrando

Tre progetti sembrano simili e si comportano diversamente: raggiungere l’indirizzo pubblico dell’ASA rivolto alla VPN, raggiungere un’interfaccia interna tramite IPsec e raggiungere un’interfaccia di gestione dedicata. Annotate l’indirizzo sorgente dell’amministratore, l’indirizzo esatto di destinazione e TCP 22 prima di toccare un’autorizzazione. Tutto ciò che segue dipende da quella coppia.

Un tunnel che trasporta due VLAN di server può non trasportare affatto l’indirizzo dell’interfaccia del firewall né la sottorete di gestione dell’amministratore. Controllate l’elenco del traffico interessante della politica da sito a sito e confermate che l’indirizzo dell’ASA stessa compaia come destinazione, non solo le sottoreti che lo attraversano.

Poiché la destinazione è il firewall stesso, l’ammissione di gestione è separata dalle regole per il traffico inoltrato. Una ACL che lascia i client raggiungere i server dietro l’ASA non abilita da sola l’amministrazione SSH dell’apparecchio, e correggere la regola di inoltro non sposterà questo guasto.

management-access è specifico dell’interfaccia

Il comando management-access dice all’ASA di accettare connessioni di gestione su un’interfaccia denominata quando arrivano tramite VPN. Non crea una rotta, non aggiunge un’autorizzazione SSH e non si applica a tutte le interfacce insieme. Se l’interfaccia di destinazione non è quella denominata, la connessione viene scartata prima dell’autenticazione.

Qui mordono due esclusioni. Le interfacce solo per la gestione restano fuori da questo meccanismo, e la guida alla gestione di ASA 9.20 osserva che lo stack CiscoSSH predefinito non supporta SSH tra interfacce via VPN, mentre lo stack ASA SSH sì. Confermate lo stack attivo sulla versione distribuita prima di dedicare tempo alle rotte.

Quattro porte prima del prompt di accesso

Tra il client e il prompt del nome utente stanno quattro porte indipendenti: una corrispondenza di rotta e tunnel per la coppia di gestione, una ACL di interfaccia che consente TCP 22 verso l’indirizzo dell’ASA, un’autorizzazione ssh che copre la sorgente dell’amministratore e un’autenticazione AAA per quell’utente. Ciascuna può scartare il pacchetto senza dire al client quale porta si è chiusa.

Usate packet-tracer per vedere quale porta fallisce prima di cambiare qualsiasi cosa: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. La traccia nomina la ACL, la fase NAT e la decisione to-the-box, che di solito basta a separare un problema di routing da un problema di ammissione.

Scrivete l’autorizzazione stretta, non quella ampia

Limitate l’autorizzazione alla sottorete amministrativa approvata e all’interfaccia che riceve il traffico del tunnel: ssh 10.10.5.0 255.255.255.0 inside. Abbinatela a un metodo di autenticazione come aaa authentication ssh console LOCAL e a un account locale denominato, invece di aprire ogni sorgente sull’interfaccia esterna.

Mantenete coerenti la ACL di interfaccia e l’autorizzazione ssh. Un’autorizzazione per una sottorete che la ACL blocca fallisce comunque, e una ACL che consente la sottorete senza una voce ssh corrispondente fallisce alla porta successiva. Entrambe le affermazioni descrivono lo stesso percorso da livelli diversi, quindi esaminatele insieme nella configurazione in esecuzione.

Verificate dall’host denominato, poi restringete di nuovo

Aprite una nuova sessione dall’host di gestione denominato invece che dalla vostra scrivania, e confermate sull’ASA quale indirizzo sorgente e quale interfaccia ha usato la connessione. Controllate le sessioni attive e la sezione SSH della configurazione in esecuzione mentre la sessione è aperta, poi chiudetela e rimuovete qualsiasi autorizzazione temporanea aggiunta per i test. Se la sessione compare ma cade subito dopo l’accesso, il problema rimanente è l’autorizzazione e non la raggiungibilità. Registrate l’interfaccia e la sorgente nel registro delle modifiche perché la persona successiva non ripeta la diagnosi.

Tenete la console o un altro percorso di ripristino approvato in modo indipendente disponibile per tutta la modifica. Quando il percorso privato funziona, confermate che le sorgenti pubbliche e gli utenti VPN non correlati non abbiano ottenuto lo stesso accesso, perché un percorso di gestione che funziona per tutti è un problema diverso da quello con cui avete iniziato.