Selettori di traffico IPsec: cosa coprono e cosa no

I selettori di traffico nominano il traffico interno che un accordo IPsec protegge, e la coppia viene negoziata anziché presunta. Due estremità possono autenticarsi perfettamente a vicenda e comunque non essere d’accordo su quali pacchetti appartengano dentro il tunnel. Questo disaccordo è invisibile nello stato della connessione, che di solito riporta un tunnel sano. Leggere i selettori da entrambe le estremità e poi seguire una destinazione lo trova più in fretta di qualsiasi quantità di modifica della politica.

Leggili da entrambe le estremità

Ogni estremità descrive il proprio lato come locale e l’altro lato come remoto. La stessa coppia di prefissi appare quindi scambiata nelle due configurazioni, e questo è corretto, non contraddittorio. Invertire la prospettiva è la prima cosa da fare quando un accordo funzionante sembra sbagliato sulla carta. Confrontare due file fianco a fianco senza scambiarli produce una discrepanza che non esiste.

I valori non sono sempre sottoreti singole. I selettori IKEv2 possono portare intervalli di indirizzi, numeri di protocollo e intervalli di porte, ed è così che una politica protegge un servizio invece di un’intera rete. Un selettore più stretto del traffico previsto produce un tunnel che trasporta alcune destinazioni e ne esclude altre in silenzio.

Scrivi entrambi i lati in un’unica tabella prima di cambiare qualcosa. L’esercizio di solito risolve la questione senza toccare un file di configurazione.

Il restringimento è decisione del responder

L’iniziatore propone, e il responder può accettare solo un sottoinsieme. IKEv2 consente al responder di restringere i selettori di traffico offerti, e il risultato ristretto è ciò che viene realmente installato. Leggere la configurazione dell’iniziatore descrive quindi un’offerta, non l’accordo.

Per questo una sottorete aggiunta al client può produrre un tunnel funzionante che rifiuta comunque la nuova destinazione. Il server ha ristretto l’offerta a ciò che la sua politica consente, mentre il file del client elenca ancora l’intervallo più ampio. Solo lo stato negoziato mostra la verità: su Linux, ip xfrm policy e l’elenco dei child SA nella documentazione IKEv2 di strongSwan riportano ciò che è stato installato e non ciò che è stato richiesto. Quando i due divergono, è la politica del responder quella da cambiare.

Una proposta rifiutata è un sintomo diverso da una ristretta. Il rifiuto compare nel registro della negoziazione e non lascia alcuna associazione child.

Segui una destinazione da un capo all’altro

Scegli una destinazione reale più l’indirizzo di origine che il client userebbe per essa, poi segui quella coppia attraverso tre decisioni indipendenti. La rotta sceglie un percorso, il selettore decide se quel percorso è protetto, e il firewall decide se il pacchetto è consentito. Ognuno può fallire da solo, e un selettore ampio non ripara nessuno degli altri.

ip route get 10.20.30.41
ip xfrm policy list
swanctl --list-sas

La query di rotta nomina l’interfaccia e l’indirizzo di origine che porterebbero il pacchetto. L’elenco delle politiche mostra se esiste una politica di tunnel corrispondente per quella coppia, inclusi direzione e livello. L’elenco SA mostra i selettori child negoziati insieme ai contatori, quindi un’associazione child con zero pacchetti dopo un tentativo di traffico è la firma di selettori che escludono ciò che viene inviato. Tre comandi, tre risposte diverse, e solo una spiega una caduta silenziosa.

Se i contatori child si muovono mentre l’applicazione continua a fallire, il problema è oltre il tunnel. Questo sposta l’indagine verso l’ascoltatore o il firewall dell’host remoto e non verso i selettori.

Tieni separati i due obiettivi

Proteggere una sottorete di ufficio e inviare tutta la navigazione attraverso un’uscita remota sono requisiti diversi con selettori diversi. Un profilo costruito per uno raramente si adatta all’altro, e mescolarli produce o una fuga o una divisione rotta. Ampliare l’intervallo protetto significa cambiare entrambe le estremità e la loro politica di inoltro, perché una modifica unilaterale diventa una proposta rifiutata. È il modo più comune in cui un tunnel che funzionava smette di funzionare dopo una piccola modifica.

I selettori descrivono la copertura crittografica, le rotte scelgono percorsi, e le applicazioni impongono i propri permessi. Un tunnel che copre tutto non riesce comunque a raggiungere un servizio legato a loopback, e una rotta verso il tunnel ha comunque bisogno di un selettore che includa la destinazione. Verifica tutti e tre contro la stessa richiesta di prova, e la discrepanza si nomina da sola.