Una sottorete VPN eredita il livello di sicurezza dell’interfaccia ASA?

Qualcuno chiede se la sottorete VPN della filiale abbia «livello di sicurezza 0 o 100» sull’ASA, e la domanda contiene già l’errore. Il livello di sicurezza è una proprietà di un’interfaccia locale, assegnato da 0 a 100 nella configurazione dell’interfaccia. Una sottorete remota che arriva attraverso un tunnel non ne acquisisce nessuno, comunque sia scritta la crypto map. Per questo la domanda non ha una risposta numerica.

La domanda pratica successiva è migliore: quale politica ammette la filiale verso il server e quale la tiene lontana dal firewall stesso. Sono due risposte, e la procedura sotto le separa.

I livelli di sicurezza appartengono alle interfacce

Eseguite show running-config interface e vedrete security-level sotto ogni interfaccia fisica o interfaccia VLAN, non sotto il gruppo di tunnel o la crypto map. Il permesso predefinito da alto a basso viene valutato tra queste interfacce, ed è per questo che il numero cambia il comportamento dell’ispezione e dell’ACL implicita sul percorso a cui appartiene.

Per un flusso VPN decifrato, l’ingresso resta l’interfaccia outside dove termina il tunnel, e l’uscita è l’interfaccia inside verso il server. Annotate entrambe prima di toccare qualsiasi cosa. Questo singolo passo elimina gran parte della confusione, perché trasforma una domanda astratta di fiducia in una coppia di interfacce.

Il bypass dell’ACL ha un confine con un nome

sysopt connection permit-vpn è l’impostazione che la gente ricorda a metà quando dice che il traffico VPN ignora le ACL. Salta davvero l’ACL dell’interfaccia per il traffico che si qualifica come traffico VPN, e la guida ai parametri 9.x lo limita per interfaccia e direzione invece di dichiarare un’eccezione globale.

Verificate cosa è configurato prima di ragionare a memoria:

• show running-config all sysopt per vedere il valore effettivo, non solo le righe non predefinite.
• show running-config access-group per vedere quale ACL è applicata a quale interfaccia e direzione.
• show vpn-sessiondb detail l2l per confermare quale gruppo di tunnel e quale filtro usa realmente la sessione.

Disattivare questa impostazione per rafforzare l’accesso VPN è una modifica con un grande impatto. Sottopone di nuovo ogni flusso VPN qualificato all’ACL esterna, il che di solito rompe tunnel funzionanti in modi non legati alla filiale per cui vi è stato chiesto.

Leggete il filtro collegato alla sessione

Il vero controllo per tunnel è il filtro VPN: un’ACL a cui fa riferimento la politica di gruppo o il nome utente, applicata dopo la decifratura e prima della cifratura. Un filtro a livello utente sostituisce il valore a livello di gruppo, quindi due persone nello stesso gruppo di tunnel possono avere un accesso effettivo diverso.

Confermate la precedenza invece di presumerla. show running-config group-policy <name> mostra il valore del gruppo, e show running-config username <name> mostra se esiste un valore per utente. Se esistono entrambi, vince il valore utente. Poi confrontate le voci di quell’ACL con il flusso che vi interessa, nella direzione in cui valuta il filtro.

Un filtro che permette il server applicativo non dice nulla sulla gestione. Sono regole separate su un percorso separato.

Verificate un permesso e un rifiuto

Packet-tracer è il modo più rapido per vedere la decisione senza aspettare che un utente la segnali. Dategli il flusso dal lato decifrato e lasciate che nomini le fasi ACL, NAT e ispezione che attraversa.

1. packet-tracer input outside tcp 10.20.30.10 49152 10.0.5.20 443 detailed
2. Leggete la riga del risultato: nomina l’ACL che ha permesso o scartato il pacchetto.
3. Ripetete con la destinazione amministrativa sull’interfaccia inside e confermate un rifiuto.
4. Ripetete ancora una volta dopo ogni modifica, così che lo stato prima e quello dopo siano entrambi registrati.

Poi verificate con traffico reale: una richiesta applicativa riuscita dalla filiale e un tentativo SSH fallito verso l’ASA. Packet-tracer modella il percorso; un flusso reale dimostra che il modello corrispondeva.

Annullate la modifica che l’ha fatto funzionare

Se la correzione consisteva nel disattivare il bypass dell’ACL o nell’ampliare un filtro, conservate la configurazione precedente. Una cattura show run degli oggetti interessati, salvata prima della modifica, basta a ripristinarli; la configurazione ASA è orientata alle righe, quindi tornare indietro significa reinserire le vecchie righe, non ripristinare un file.

Registrate la coppia di interfacce, il filtro effettivo, il nome dell’ACL da packet-tracer e i comandi esatti che avete modificato. Quel registro trasforma la revisione successiva in un controllo di cinque minuti invece di un altro dibattito sui livelli di fiducia.