Dopo la decifratura: quale policy vede per prima il traffico VPN

Un flusso VPN può essere perfettamente cifrato e perfettamente autenticato e comunque finire dove nessuno aveva pianificato. Il cavo che inserisci non determina quale regola elabora il pacchetto interno; lo fanno l’hook di policy e la rotta. Perciò due progetti identici su uno schema di rack possono avere un’applicazione del tutto diversa. Scegliere tra loro comincia dal nominare il controllo che vede per primo il flusso decifrato.

Decidi per l’hook di policy, non per la porta

Ogni piattaforma VPN valuta il traffico decifrato in un punto prima di inoltrarlo, e quel punto ha un nome nella configurazione. Su una piattaforma è un filtro di policy di gruppo, su un’altra una policy di interfaccia o una coppia di zone, e su un apparato che instrada può essere semplicemente la catena forward. L’hook applica la regola, mentre la porta dello switch è solo il punto in cui termina il cavo. Trovare l’hook è la prima decisione, perché tutto il resto è collocazione rispetto a esso.

Prima di guardare l’hardware, scrivi il flusso: chi è la sorgente, dove va, quale protocollo lo trasporta e quale servizio è permesso. Poi trova il controllo che applica ciascuno di quei quattro fatti.

Due percorsi, due storie di applicazione

Due forme sono comuni e ciascuna può essere corretta per un requisito diverso.

endpoint -> shared inside subnet -> server
endpoint -> dedicated transit -> policy firewall -> server subnet

La prima forma può applicare tutto il necessario sul gateway, purché la policy sia scritta per quella destinazione e il server non abbia un percorso che la aggiri. La seconda aggiunge un confine, ma solo se le rotte e la policy fanno davvero attraversare il traffico. Un server sullo stesso segmento del punto finale può non seguire mai il salto intermedio immaginato. Il diagramma mostra l’intenzione e la tabella di routing mostra ciò che accade.

Verifica con una ricerca di rotta e non con il disegno. L’interfaccia da cui esce un pacchetto e il salto successivo che sceglie decidono se la seconda forma si comporta come progettato.

ip route get 10.30.7.20
sudo iptables -S FORWARD
sudo tcpdump -ni inside0 host 10.30.7.20

Separa la topologia dall’isolamento

Condividere una sottorete non rende un luogo inaffidabile, e un transito dedicato non lo rende protetto. Decide la restrizione realmente applicata, l’inoltro che realmente avviene e chi amministra ogni parte. Contare gli switch non dice nulla su nessuno dei tre. Decidi dalla policy e dalla rotta, poi lascia che la topologia segua la decisione.

Tratta separatamente anche le popolazioni di traffico. I pool di accesso remoto, i prefissi sito a sito e le reti a linea dedicata possono condividere un apparato e richiedere comunque regole diverse, perché identità e rischio differiscono. Una regola scritta per una popolazione copre silenziosamente le altre quando condividono un piano di indirizzi.

Verifica guasto e gestione di ogni collocazione

Ogni collocazione ha un modo di guastarsi, e la domanda utile è che cosa funziona ancora quando un componente si ferma. Più interfacce logiche su un solo apparato morto non danno recupero indipendente, e un firewall a valle che condivide la stessa alimentazione o lo stesso amministratore non è un secondo confine. Chiedi dove passa il cammino di gestione, perché una console raggiungibile solo dal tunnel non è affatto un cammino di recupero; ssh [email protected] true da fuori del tunnel è il modo più economico per dimostrare che la console non ne dipende. La documentazione di policy di gruppo di una piattaforma colloca il filtro su traffico post-decifratura e pre-cifratura, esattamente il tipo di hook nominato da cercare in ogni prodotto.

Scrivi la storia di guasto di ogni candidato accanto alla storia di applicazione. Una collocazione che vince in ispezione e perde in recupero è uno scambio, e va registrata come tale invece di essere scoperta durante un incidente.

Accetta con un flusso permesso e uno negato

Con un piano di test approvato, controlla tre cose dalla sorgente VPN reale: un’applicazione che dovrebbe funzionare, una risorsa che non dovrebbe, e la direzione da cui torna la risposta. Il diniego è la prova che la policy è attiva, mentre il flusso permesso dimostra solo che esiste un percorso.

Conserva il percorso scelto e il risultato della policy insieme, perché un risultato senza percorso non è riproducibile e un percorso senza risultato non è difendibile. Quella coppia è molto più utile per scegliere un punto di collegamento di qualsiasi affermazione su quale livello di commutazione sia intrinsecamente più sicuro.