Traffico del client VPN e stato del firewall: flusso esterno e interno

Lo handshake VPN si completa, il client ottiene un indirizzo, e un servizio dietro il gateway rifiuta ancora la connessione. Il firewall spesso fa esattamente ciò che gli è stato detto. Ha autorizzato il flusso esterno del tunnel, che è un pacchetto diverso dalla connessione applicativa decapsulata. Ne seguono due decisioni: quale flusso state autorizzando e se la frontiera tiene traccia dello stato.

Finché non separate le due cose, ogni modifica di regola è una congettura.

Il firewall vede due pacchetti diversi

Prima della decapsulazione, il firewall vede traffico indirizzato all’endpoint VPN: un flusso UDP esterno verso l’ascoltatore. Dopo la decapsulazione, un pacchetto inoltrato porta l’indirizzo interno del client e la destinazione del servizio.

Un’autorizzazione per il flusso esterno non autorizza la connessione TCP inoltrata. Possono essere valutate in catene diverse, su interfacce diverse e con indirizzi diversi dopo la traduzione.

Confrontate le catture da posizioni equivalenti su entrambi i lati. Una cattura al bordo del tunnel e una cattura sul server mostrano tuple diverse per la stessa sessione.

Prima decisione: autorizzare il tunnel o il servizio

Se il client ha bisogno solo dell’endpoint VPN stesso, l’autorizzazione esterna può bastare. Se ha bisogno di un servizio oltre il gateway, serve un’autorizzazione all’inoltro per quella destinazione e quella porta. Una regola del tunnel che autorizza anche il servizio è una scelta di progettazione che dovreste nominare, non un incidente.

Mantenete stretti l’intervallo del client e l’ambito del servizio. Un’autorizzazione dalla sottorete del tunnel all’intera LAN è una decisione di fidarsi di ogni host, non una scorciatoia per una singola applicazione.

Scrivete le due regole separatamente. La regola del tunnel e la regola del servizio falliscono in modi diversi e si diagnosticano con prove diverse. Quando una fallisce, sapete quale livello ispezionare per primo.

Seconda decisione: con stato o senza stato a ogni frontiera

Una regola per flussi stabiliti può ammettere le risposte per uno scambio autorizzato, ma il suo comportamento dipende dal prodotto. Un gruppo di sicurezza cloud di solito tiene lo stato; una lista di controllo di sottorete spesso non lo tiene e richiede una gestione esplicita in entrambe le direzioni. Non date per scontato che ogni frontiera del percorso tratti lo stato allo stesso modo. Elencate ogni frontiera e contrassegnatela con o senza tracciamento dello stato prima di progettare le regole.

Se una regola cambia, i flussi tracciati esistenti possono continuare a funzionare mentre i nuovi falliscono, o viceversa. Questa differenza è un indizio utile, non un motivo per svuotare tutto lo stato delle connessioni su un gateway in produzione.

Provate con una richiesta nuova e controllata e ispezionate i contatori pertinenti. Un test pulito è meglio di un riavvio dirompente. Annotate il nome del contatore nel registro delle modifiche, così il prossimo test usa la stessa prova.

Verificate il percorso di ritorno con la stessa politica

Inviate una nuova richiesta dal client al servizio, poi controllate i contatori di andata e ritorno a ogni frontiera. Confermate che la risposta usa il percorso che vi aspettate, soprattutto se è coinvolta una traduzione.

Mantenete stretti l’intervallo di client previsto e l’ambito del servizio, e verificate il percorso di ritorno con lo stesso insieme di regole che ha autorizzato la richiesta. Una regola che funziona solo perché un vecchio flusso è ancora aperto non è una regola funzionante.