La policy IPsec sta inghiottendo il tuo traffico locale: come capirlo

La stampante sulla scrivania smette di rispondere nel momento in cui il tunnel si alza, e nulla nella configurazione del tunnel la menziona. Di solito è successo che un intervallo protetto è stato scritto così ampio da includerla, così la macchina ora prova a cifrare traffico che doveva restare sul segmento locale. Leggere la policy installata spiega la cattura; restringerla nel punto giusto mantiene protetto il traffico remoto. Il percorso dalla richiesta che fallisce alla policy corrispondente richiede pochi minuti.

Segui il flusso prima di cambiare un selettore

Parti dalla richiesta che fallisce e annota quattro valori: l’indirizzo di origine usato dalla macchina, la destinazione esatta, la rotta scelta dal kernel e la policy che corrisponde a quella coppia.

Questi quattro fatti decidono se la cattura è voluta o accidentale. Una destinazione che cade nel selettore remoto è protetta per progetto, anche se il progetto era sbagliato. Una destinazione fuori da esso che viene comunque catturata significa che sta corrispondendo qualcos’altro, e cambiare il selettore non aiuterà. Entrambi i casi sono comuni, e li distingue un solo comando.

Fallo prima di modificare qualsiasi cosa, perché il caso interessante è la sottorete locale che si sovrappone a un intervallo privato protetto dalla connessione. Prefissi noti come 192.168.0.0/16 compaiono in molte reti, e un selettore scritto per uno di essi può coprire silenziosamente il tuo.

Tre tipi di locale che si comportano diversamente

Una destinazione assegnata a questo host, una destinazione sullo stesso collegamento e una destinazione dietro un’altra interfaccia sono tre casi diversi. Il kernel tratta ciascuno in modo diverso quando decide se il traffico necessita di protezione.

Il traffico generato dal gateway stesso non è nemmeno uguale al traffico inoltrato da un client. Una policy che sembra corretta per il traffico inoltrato può catturare la sessione di gestione del gateway, ed è così che un amministratore perde l’accesso mentre sistema il tunnel.

L’abitudine utile è nominare il caso ad alta voce: questo pacchetto viene da me, va al mio collegamento o passa attraverso di me? Ogni risposta indica un punto diverso da restringere. Scrivere il caso impedisce anche alla persona successiva di rifare lo stesso lavoro.

Quando l’intervallo protetto è un intero spazio privato, tutti e tre i casi possono caderci dentro insieme, e il sintomo diventa una macchina che non raggiunge nulla tranne l’estremo del tunnel.

Leggi la policy installata, non il file

I file di configurazione descrivono l’intenzione; il kernel tiene le policy che corrispondono davvero. Mostra entrambi e tratta una discrepanza come il primo risultato.

Questi comandi mostrano la rotta scelta per la destinazione e le policy installate in ciascuna direzione:

ip route get 192.168.50.20
ip xfrm policy list
sudo swanctl --list-conns

La rotta ti dice quale interfaccia userebbe il pacchetto. L’elenco delle policy ti dice se a quel pacchetto viene poi applicato un modello, e l’elenco delle connessioni mostra quali selettori il demone ritiene di aver installato. Se la destinazione compare in un selettore remoto, hai trovato la cattura senza indovinare.

Restringi il selettore o aggira la destinazione

Ci sono due riparazioni supportate e rispondono a domande diverse. Restringere il selettore dice che questa connessione protegge solo un intervallo più piccolo, il che è corretto quando l’intervallo più ampio era un errore. Aggiungere un aggiramento dice che questa destinazione specifica non deve mai essere protetta, il che è corretto quando l’intervallo protetto è davvero ampio e una destinazione è un’eccezione.

Scegli la prima quando puoi, perché un selettore più piccolo è più facile da ragionare e compare nella definizione della connessione. Scegli la seconda quando l’intervallo ampio è intenzionale e l’eccezione è un singolo host o una sottorete che puoi nominare.

Entrambe appartengono alla configurazione che possiede la connessione. Una regola di runtime aggiunta a mano sparisce alla riconnessione successiva, e il guasto torna in un momento in cui nessuno ricorda la soluzione temporanea.

Eccezioni sicure alla reinstallazione

Dopo la modifica, ripeti la stessa richiesta innocua e guarda gli stessi contatori. La destinazione locale dovrebbe rispondere, e la destinazione remota prevista dovrebbe ancora mostrare traffico cifrato.

Questi due controlli confermano che l’eccezione è sopravvissuta e che la protezione no:

ip xfrm policy list | grep -c out
ping -c 3 192.168.50.20

Poi disconnetti e riconnetti il tunnel di proposito, e ripeti entrambi. Un’eccezione che funziona prima della riconnessione e fallisce dopo è stata applicata al livello sbagliato, ed è il modo più comune in cui questo problema ritorna.