Perché un utente remoto ASA raggiunge la sottorete ma non l’applicazione
Le rotte provano che il tunnel funziona, non che l’utente possa aprire l’applicazione. Leggi il filtro ricevuto dalla sessione, poi prova una connessione consentita e una negata.
Il tuo utente si connette, ottiene un indirizzo, esegue il ping di un server nella sottorete dell’applicazione e comunque non riesce ad aprire il servizio su di esso. Questa combinazione è normale su un ASA, perché un tunnel riuscito e un’autorizzazione utilizzabile sono decisi da impostazioni diverse. L’elenco del tunnel diviso ha scelto quali destinazioni sono entrate nel tunnel; un filtro VPN e le regole di accesso della destinazione stessa decidono cosa può raggiungere la richiesta decifrata. Affronta le tre decisioni in ordine invece di allargare l’elenco delle rotte finché qualcosa cambia.
Tre decisioni facili da confondere
L’ammissione risponde se l’utente può stabilire il tunnel: credenziali, certificato e qualsiasi secondo fattore. La selezione della rotta risponde quali destinazioni il client invia in quel tunnel. L’autorizzazione risponde se la richiesta decifrata può raggiungere il servizio. Solo la terza produce l’errore che l’utente segnala.
Un modo rapido per distinguerle è chiedersi cosa romperebbe una modifica. Rimuovere una rotta dall’elenco diviso ferma il traffico verso quella sottorete senza concedere nulla; aggiungere un ACE al filtro VPN concede una destinazione senza cambiare ciò che il client incapsula nel tunnel.
| Setting | What it decides | Symptom when it is wrong |
|---|---|---|
| Connection profile and authentication | Whether the tunnel is built | Login fails, no address assigned |
| Split-tunnel network list | Which destinations the client routes into the tunnel | Subnet unreachable from the client, everything else fine |
| VPN filter (ACL) | Which decrypted flows are permitted | Tunnel up, ping may work, TCP service refused or dropped |
Leggi il filtro che la sessione ha realmente ricevuto
Parti dalla sessione attiva e non dalla configurazione che ritieni valida. show vpn-sessiondb detail anyconnect stampa la politica di gruppo assegnata e il nome del filtro collegato a quella sessione. Se il campo è vuoto, nessun filtro impone nulla e il blocco arriva da altrove.
Poi leggi la politica che possiede il valore, compresi i valori predefiniti, perché un filtro può essere ereditato invece che scritto dove stai guardando:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Confronta il nome del filtro sulla sessione con l’ACL che hai appena modificato. Un’ACL con nome simile che l’utente non ha mai ricevuto non può cambiare la politica delle risorse di quella sessione, e questa è la ragione più comune per cui una modifica che sembra corretta non ha effetto.
La precedenza spiega il resto. Per l’impostazione del filtro, un record DAP ha la precedenza sugli attributi del nome utente, e questi hanno la precedenza sulla politica di gruppo. Quando una sessione mostra un filtro che non ti aspettavi, cerca una politica DAP corrispondente a quell’utente prima di toccare il gruppo.
L’elenco diviso e il filtro sono campi separati
Su ASA 9.x la politica di gruppo contiene split-tunnel-network-list e vpn-filter come impostazioni diverse, e la guida alle politiche di gruppo 9.22 li documenta separatamente proprio per questo. L’elenco delle reti è un’indicazione di routing per il client; il filtro è un elenco di controllo degli accessi applicato al traffico decifrato.
Questa distinzione conta quando un utente ha bisogno di un solo servizio HTTPS in una sottorete. Metti la sottorete nell’elenco diviso perché i pacchetti entrino nel tunnel, poi consenti solo quel servizio nel filtro. Allargare l’elenco delle rotte non autorizza nulla, e ridurlo non è un meccanismo di applicazione.
Verifica se un’ACL di interfaccia è persino sul percorso
Il traffico decifrato di accesso remoto non attraversa sempre l’ACL dell’interfaccia esterna come si suppone. Dove sysopt connection permit-vpn è abilitato, l’ASA applica la sua deviazione VPN documentata per quel traffico, mentre i filtri VPN applicabili valgono ancora dopo. Verifica l’impostazione con show run all sysopt invece di ragionare sul diagramma della topologia.
In ogni caso, il firewall dell’host di destinazione e l’autorizzazione dell’applicazione restano sul percorso. Una regola ASA che consente TCP 443 non fa accettare l’utente all’applicazione.
Accetta la modifica anche con una connessione negata
Un test consentito da solo prova molto poco, perché un tunnel funzionante produce lo stesso primo pacchetto che un filtro ci sia o no. Apri il servizio previsto dal client, poi tenta una destinazione che deve restare chiusa e conferma che fallisce per il motivo giusto.
Annota quattro fatti quando chiudi il ticket: l’identità ammessa, la politica e il filtro che la sessione ha realmente ricevuto, le destinazioni nell’elenco diviso e la risorsa che all’utente era consentito raggiungere. Quei quattro spiegano dove viene controllato il traffico senza trasformare un elenco di rotte in un firewall.
Se il servizio rifiuta ancora dopo che il filtro lo consente, passa all’host: indirizzo di ascolto, firewall dell’host e mappatura utenti propria dell’applicazione. A quel punto il tunnel ha fatto il suo lavoro, e altre modifiche sull’ASA aggiungono solo rischio.