Quale regola dell'ASA vede il traffico dopo che il VPN lo decifra

La prima ipotesi da abbandonare è che l'ACL crittografica sia una policy di accesso. Non lo è. Su un Cisco ASA quell'elenco risponde a una domanda ristretta: quali pacchetti meritano protezione, e quella risposta non dice nulla sulla possibilità che il pacchetto decifrato raggiunga il server dietro il firewall. L'accesso si decide più tardi, con una policy dell'interfaccia, con un filtro della group policy o con entrambi, a seconda di come è stato costruito il tunnel.

L'ACL crittografica risponde a un'altra domanda

Un'ACL crittografica è un elenco di corrispondenze. Indica al tunnel cosa cifrare fra due peer; un pacchetto che non vi corrisponde semplicemente non è protetto. Ampliarla cambia l'ampiezza della protezione e nulla più.

Per questo aggiungere una sottorete lì può far salire un tunnel mentre l'applicazione reale continua a fallire. Il tunnel è attivo perché ora esiste una corrispondenza. L'applicazione fallisce ancora perché nulla in quell'elenco permette qualcosa. Due domande diverse, due elenchi diversi.

Che cosa salta davvero l'impostazione di bypass

sysopt connection permit-vpn consente al traffico protetto di saltare il controllo ACL dell'interfaccia che altrimenti si applicherebbe sul lato in ingresso. È una comodità per le implementazioni VPN, ed è globale. Non tocca la group policy e non tocca un filtro di autorizzazione per utente.

Leggete il valore reale invece dell'ipotesi: show running-config all sysopt stampa l'impostazione anche quando non è mai stata configurata in modo esplicito, ed è lì che inizia molta confusione.

Poiché l'impostazione è globale, provarla come esperimento rapido su una sola sottorete che non funziona è un cattivo scambio. Ogni altro tunnel di quel firewall condivide il risultato. Tenetela per una modifica deliberata con un piano di ripristino.

Leggete il filtro nella direzione decifrata

Un vpn-filter LAN-to-LAN si scrive dal punto di vista del tunnel, non dell'interfaccia. La rete remota occupa la posizione di origine e la rete locale quella di destinazione, perché è così che appare il pacchetto dopo la decifratura. Lo stesso filtro viene poi valutato di nuovo nella direzione opposta prima della cifratura, con i ruoli degli indirizzi invertiti.

Le condizioni di porta meritano più attenzione di un'ACL dell'interfaccia copiata proprio per questo motivo. Una regola che permette una porta di destinazione può avere un effetto indesiderato nella direzione inversa, dove una nuova connessione usa quella porta come origine. Annotate quale lato può iniziare, il servizio reale e la controparte che deve restare chiusa prima di costruire l'elenco.

Confermate quale filtro è realmente collegato: show running-config group-policy e show vpn-sessiondb detail l2l insieme dicono cosa ha ereditato la sessione. Modificare un'ACL a cui nessuna policy fa riferimento non cambia nulla.

Non riutilizzate un solo oggetto ACL per due compiti

Un access-group dell'interfaccia e un vpn-filter sembrano lo stesso tipo di oggetto e vengono valutati in punti diversi con orientamenti degli indirizzi diversi. Assegnare un unico elenco a entrambi invita a una modifica che sistema il tunnel e allenta silenziosamente l'interfaccia fisica.

Teneteli separati, nominateli secondo il loro compito e fate vedere la differenza di direzione nei nomi.

Verificate con connessioni nuove, in entrambe le direzioni

Dopo una modifica pianificata, aprite una nuova connessione che deve essere permessa e una nuova connessione che deve essere negata, poi annotate indirizzi, direzione e corrispondenza della policy insieme al risultato. Una sessione stabilita non dimostra nulla sul filtraggio delle nuove connessioni, perché è già stata ammessa con le vecchie regole.

Tenete conto anche dell'ispezione. La documentazione del fornitore rileva che un filtro VPN controlla la connessione iniziale e non ogni connessione secondaria aperta da un motore di ispezione, quindi un canale di controllo e il relativo flusso multimediale possono ricevere un trattamento diverso. Se l'applicazione conosce il protocollo, provate il flusso reale invece di una singola sonda di porta.

Un tunnel che diventa utilizzabile dopo un bypass ampio vi dice che la restrizione è stata rimossa, non che è stata soddisfatta. Il risultato che vale la pena conservare è un punto di applicazione con un nome a cui potete rimandare nella prossima revisione.