La VPN tra sedi funziona, ma i log dell’ASA non arrivano: controllate l’indirizzo di origine

Gli host interni raggiungono il collettore remoto e le loro righe syslog compaiono. I messaggi dell’ASA stesso su quelle stesse sessioni non arrivano mai. Non c’è nulla di sbagliato né nel collettore né nel tunnel, ed è questa la parte confusa. Il firewall invia i suoi log da un’origine per la quale il tunnel non è mai stato costruito.

Cosa arriva e cosa no

Iniziate separando due flussi che su una dashboard sembrano identici. Il traffico inoltrato attraversa l’ASA: un host LAN invia al collettore, l’ASA lo confronta con la politica del tunnel, lo cifra e il collettore vede l’indirizzo dell’host. Il traffico generato nasce sull’ASA stesso: l’apparecchio costruisce un pacchetto syslog, sceglie un’interfaccia di uscita e un’origine e solo dopo chiede se corrisponde una politica del tunnel. Il primo flusso dimostra che il tunnel funziona e non dice nulla sul secondo.

Un evento memorizzato nel buffer sul dispositivo non è nemmeno prova di consegna remota, perché il log può esistere localmente e non essere mai stato trasmesso. Controllate i contatori di ricezione del collettore prima di accusare il tunnel, perché un contatore vuoto è una constatazione diversa da uno che cresce.

Un messaggio generato non è traffico inoltrato

Quando l’ASA origina un pacchetto, non fa da proxy per un host LAN. L’origine viene dall’interfaccia di uscita o da un’impostazione di origine esplicita, e il pacchetto entra nella stessa ricerca di rotta e negli stessi controlli di politica di qualunque altra cosa invii il dispositivo. Ciò significa che il selettore della VPN deve includere l’indirizzo che l’ASA usa davvero, spesso la sua interfaccia esterna anziché una sottorete interna.

Se la politica protegge 10.20.0.0/24 e l’ASA usa il suo indirizzo esterno come origine, il pacchetto di log o esce in chiaro verso un collettore che non può raggiungere, oppure viene scartato. Entrambi gli esiti sono identici dal lato del collettore. Lo stesso ragionamento vale per il traffico di gestione, per questo management-access è una decisione di progetto separata.

Quale origine l’ASA mette sulla rete

Trovate l’origine empiricamente, non per supposizione. Una cattura sull’interfaccia di uscita durante un messaggio di prova mostra l’origine e la destinazione reali, e costa meno tempo che leggere tre sezioni di configurazione. Confrontate quell’indirizzo con il selettore locale del tunnel.

Alcune versioni permettono di fissare l’origine dei log a un’interfaccia, e il riferimento dei comandi della vostra versione è l’autorità su se questa opzione esiste e cosa cambia. Un comando source-interface di un’altra piattaforma Cisco non è automaticamente valido su un ASA.

Se cambiate l’origine, fatelo deliberatamente e annotatelo, perché le ACL del collettore e qualsiasi correlazione basata su syslog dipendono da essa.

Allineate il selettore al flusso dei log

Una volta nota l’origine, controllate tre cose in ordine: l’ACL di cifratura o il selettore basato su politica che decide quale traffico è interessante, la rotta che decide dove va il pacchetto e qualsiasi regola NAT che possa riscrivere l’origine prima della cifratura. Un pacchetto che corrisponde alla rotta ma non al selettore non passa nel tunnel, e un pacchetto riscritto da NAT può non corrispondere a nessuno dei due.

Il lato del collettore ha requisiti propri: un’ACL che consenta l’origine dell’ASA, una rotta di ritorno e un servizio in ascolto sulla porta configurata. Anche il trasporto conta, perché la registrazione TCP e TLS si comporta diversamente dall’UDP su un percorso parzialmente bloccato. Cambiate un elemento alla volta, altrimenti la prossima cattura non vi dirà quale modifica è stata importante.

Verificate al collettore, poi annotate l’origine

Confermate che il messaggio arriva, poi annotate l’indirizzo di origine usato dall’ASA, il selettore che lo ha trasportato e la gravità con cui avete provato.

Quell’annotazione trasforma la prossima modifica dell’ACL del collettore o la modifica del selettore in un controllo di due minuti invece di una nuova scoperta. Documenta anche quale dei due flussi è mai stato validato, ed è la parte che quasi tutti i runbook omettono. Se il messaggio ancora non arriva, abbassate temporaneamente la soglia di gravità e provate contro una sola destinazione.

Le domande frequenti sulla registrazione dell’ASA di Cisco documentano un caso con origine esterna che richiede la corrispondente definizione di traffico protetto, e il loro esempio con origine interna comprende sia un host di registrazione all’interno sia management-access all’interno. Trattate la combinazione documentata e il contesto del software insieme, invece di supporre che una riga copiata vada bene per ogni configurazione.

Un tunnel che trasporta traffico LAN non è un tunnel che trasporta la voce propria del firewall.