La rotta predefinita XFRM ha inghiottito IKE ed ESP: conservate il percorso esterno

Il traffico è protetto, il tunnel è attivo, e poi muore al successivo rinnovo delle chiavi. Una rotta predefinita attraverso l'interfaccia XFRM descriveva il traffico che volevate proteggere. Ha anche inghiottito i pacchetti necessari per continuare a proteggerlo.

Le due destinazioni coinvolte non sono intercambiabili. L'instradamento deve dirlo esplicitamente.

Dove va davvero la ricerca del peer

Annotate le regole attive, la tabella che contiene la rotta XFRM e l'indirizzo pubblico del peer. Poi guardate il percorso che prenderebbe la connessione esterna con la sua origine e il suo mark reali. Una destinazione generica non dice nulla su quel percorso di controllo. Solo l'origine e il mark reali danno una risposta utile.

Anche una connessione iniziale riuscita dimostra poco. Il guasto spesso compare dopo che un'installazione di rotta cambia la risposta. L'avvio riesce, poi il primo rinnovo no.

ip rule show
ip route show table 220
ip -4 route get 198.51.100.44 from 10.40.0.2
ip xfrm policy list

Se la ricerca del peer finisce nell'interfaccia XFRM, i pacchetti esterni vengono instradati nel tunnel che essi stessi costruiscono. È il loop, visibile con un solo comando.

Opzioni di esclusione su un gateway moderno

La documentazione di strongSwan sul VPN basato sull'instradamento presenta due risposte pratiche. Una contrassegna IKE ed ESP così che la regola verso la tabella XFRM non li intercetti. L'altra lascia una rotta del peer o un'esclusione che la ricerca può ancora raggiungere.

Prendete quella che il vostro insieme di regole può esprimere senza effetti collaterali. Il mark è pulito quando il resto dello stack usa già i mark. È un pericolo quando la stessa maschera significa altro in un'altra regola. Entrambi i tipi di pacchetto hanno comunque bisogno del trattamento.

Contrassegnare solo IKE lascia i pacchetti dati sul percorso catturato. Questo produce un tunnel che esegue l'handshake e poi non trasporta nulla.

Il mark è un bit nel fwmark del pacchetto che nient'altro sul gateway rivendica: 0x1 con maschera 0x1 è la scelta abituale, e va impostato in due punti perché l'esclusione funzioni. Charon ne ha bisogno sul socket IKE, e le impostazioni del mark in ingresso e in uscita della connessione figlia hanno bisogno dello stesso valore perché anche i pacchetti incapsulati escano contrassegnati. Una maschera 0x1 invece di 0xffffffff lascia liberi i bit restanti, cosa che conta quando un altro sottosistema contrassegna già pacchetti sullo stesso host. Con entrambi impostati, la regola viene scritta come esclusione, così i pacchetti contrassegnati saltano la tabella che contiene la rotta XFRM e cadono nella tabella principale:

ip rule add not fwmark 0x1/0x1 lookup 220 pref 1000
ip -4 route get 198.51.100.44 from 10.40.0.2 mark 0x1

Poi leggete la risposta con il mark applicato. Senza di esso esaminate il percorso che prende il traffico protetto, cioè l'opposto della domanda di questa sezione.

Cosa presuppone l'installazione automatica sulla build

Installazione automatica della rotta per un'interfaccia XFRM dipende dalla versione di strongSwan e dalla sua configurazione. L'ID dell'interfaccia, la politica installata e l'associazione devono tutti riferirsi agli oggetti previsti. Una discrepanza si manifesta come una rotta che punta in silenzio verso un luogo reale.

Copiare un numero di tabella o una maschera di mark da un altro gateway è il modo in cui iniziano le collisioni. Controllate prima cosa la usa già. Una collisione influisce su traffico ben oltre il tunnel che volevate cambiare, e il sintomo raramente indica la copia.

I cambi di indirizzo del peer fanno parte del progetto. Una rotta host per l'indirizzo di ieri non è un piano di ripristino dell'endpoint, mentre un mark sopravvive a quel cambiamento.

Osservate il primo rinnovo

Controllate il percorso esterno dopo che le rotte protette sono installate, non prima. Poi osservate il rinnovo successivo e uno scambio applicativo. Il guasto di solito compare a quella transizione e non all'avvio.

ip -4 route get 198.51.100.44
sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or esp'

Rimuovere temporaneamente la rotta predefinita protetta di solito ripristina la connettività. Quel risultato è diagnostico, non definitivo.

L'obiettivo è una separazione stabile tra il traffico interno e i pacchetti esterni che lo trasportano. Scrivete il meccanismo scelto e la sua tabella o il suo mark nelle note del gateway. Altrimenti la prossima persona che tocca le regole reintrodurrà il loop.