La SA figlia IPsec è attiva, ma i contatori dei pacchetti restano a zero
Contatori dei pacchetti a zero su una SA figlia installata di solito significano che nulla vi è corrisposto. Seguite un flusso fissato attraverso contatori, rotta, selettori e origine.
Avete alzato il tunnel, il timer di rekey sta scendendo e entrambe le direzioni mostrano ancora zero pacchetti. Quella coppia di numeri non dice che il peer ha rifiutato il tunnel: una CHILD SA installata con contatori inattivi è lo stato normale di un’associazione a cui nulla è ancora corrisposto. Il lavoro è dimostrare che un pacchetto avrebbe dovuto corrispondere e poi trovare il punto in cui ha lasciato il percorso descritto dai selettori. Fatelo una volta, in ordine, e mantenete identica la richiesta tra le esecuzioni.
Che cosa dimostra davvero un contatore a zero
Una CHILD SA è una coppia di selettori più le chiavi e gli SPI che cifrano il traffico che cade in quegli intervalli. Installarla significa solo che entrambi i peer hanno concordato quegli intervalli e le chiavi derivate; il kernel la manterrà per ore senza che arrivi un solo pacchetto. La domanda quindi non è mai se il tunnel esista, ma se un pacchetto del vostro test sia caduto negli intervalli negoziati dai due peer. Se nessuno è caduto, i contatori restano a zero e l’associazione scade inutilizzata al termine della sua vita.
Questa distinzione cambia ciò che ispezionate per primo. Una proposta rifiutata, un errore di autenticazione o una IKE SA moribonda emergono nel log o nell’elenco delle SA, non come uno zero silenzioso. Un tunnel che negozia in modo pulito e poi resta inattivo indica invece la corrispondenza, l’instradamento o l’origine del traffico di prova.
Inviate un flusso che sapete descrivere prima di inviarlo
Scegliete una destinazione all’interno della sottorete protetta e aprite una nuova connessione verso di essa; una pagina caricata un’ora fa può essere servita dalla cache, e una risposta in cache non tocca mai il tunnel. Poi annotate quattro valori mentre la richiesta è ancora ipotetica: l’indirizzo sorgente che l’applicazione collegherà, la destinazione, la famiglia di indirizzi e il nome o la coppia di selettori della figlia che state osservando. Quel record è ciò che trasforma un contatore piatto in un’affermazione verificabile.
L’indirizzo sorgente è il valore che la gente salta, ed è quello che rompe più spesso il test. Un portatile con indirizzo cablato, indirizzo Wi-Fi e indirizzo del tunnel può collegare qualsiasi di essi a seconda della ricerca di rotta, e solo uno può trovarsi nell’intervallo negoziato. Usate uno strumento che vi permetta di fissare la sorgente, come ping -I 10.1.0.5 10.2.0.9 o curl --interface 10.1.0.5, così il pacchetto non può scegliere in silenzio un altro indirizzo. Quando l’esecuzione fissata muove i contatori e quella non fissata no, avete trovato un problema di instradamento e non un problema IPsec.
Quali numeri leggere, e dove vivono
Su Linux, ip -s xfrm state stampa ogni associazione con una riga lifetime current: il cui totale di byte e di pacchetti appartiene solo a quella SA, seguita da una riga stats: per i contatori di replica ed errore. Su un peer strongSwan, swanctl --list-sas mostra una riga in e una riga out per ogni figlia installata, ognuna termina con un conteggio di byte e uno di pacchetti; i più vecchi strumenti stroke chiamano la stessa coppia bytes_i e bytes_o. Leggete le due direzioni separatamente, perché quella rimasta piatta è il riscontro. Sommarle nasconde esattamente l’asimmetria che state cercando.
Entrambe le viste sono per associazione, quindi un rekey installa una nuova coppia di SPI e la vostra linea di base torna a zero senza nulla di rotto. Annotate lo SPI che state osservando prima che il timer di rekey scatti, altrimenti confronterete una SA nuova con un numero vecchio. Se l’uscita sale mentre l’ingresso resta piatto, il selettore ha corrisposto e la risposta non è mai tornata, il che sposta l’indagine sull’inoltro del peer e sulla sua stessa politica. La documentazione di configurazione IKEv2 di strongSwan copre il ciclo di vita della SA figlia e i tempi di rekey dietro quei numeri.
Il punto di osservazione è una variabile distinta dall’origine del pacchetto. Un offload hardware può incrementare i contatori dell’associazione mentre una cattura software sull’interfaccia non mostra nulla, perché i pacchetti scaricati saltano l’hook su cui siede la cattura, e l’ingresso può divergere allo stesso modo. Quando i due non concordano, usate i contatori per rispondere se qualcosa ha corrisposto e la cattura per rispondere a com’era il pacchetto.
Rotta, selettori e dove è nato il pacchetto
Confrontate tre cose fianco a fianco: la rotta che il kernel sceglie per la vostra destinazione, la politica che indirizza il traffico nel tunnel e la coppia di selettori negoziata dalla figlia. ip route get 10.2.0.9 from 10.1.0.5 nomina l’interfaccia e la sorgente che il kernel userebbe, e spesso non è la coppia che avete supposto. ip xfrm policy mostra i modelli e i selettori installati localmente, mentre swanctl --list-sas mostra ciò che il peer ha accettato. Una ricerca che manda il pacchetto fuori dall’interfaccia fisica non raggiunge mai la politica, quindi i contatori non possono muoversi.
Le discrepanze arrivano in varie forme che da un contatore sembrano identiche. Una destinazione IPv6 fuori da un selettore IPv4, un indirizzo sorgente della sottorete sbagliata e una politica più stretta della figlia producono lo stesso zero. Correggete prima la causa più stretta, perché allargare un selettore solo per spostare un numero cambia ciò che il tunnel protegge.
Poi c’è l’origine del pacchetto, la trappola che un gateway tende al proprio operatore. Il traffico che il gateway genera da sé viene confrontato con la politica di uscita, mentre un pacchetto che inoltra per un client viene confrontato con la politica di inoltro, quindi un ping dalla macchina può riuscire su un percorso che nessun client prende mai.
Una modifica reversibile e un rapporto che regge la revisione
Cambiate un solo elemento, ripetete la richiesta identica e leggete gli stessi contatori. Cancellare tutte le regole del firewall o sostituire tutti i selettori in una volta sposterà un numero e distruggerà la prova che vi ha detto perché. Se la seconda esecuzione mostra ancora zero, avete eliminato un’ipotesi invece di sprecare il pomeriggio.
Scrivete il riscontro in una forma che altri possano riprodurre: nome della figlia, intervalli accettati, la sorgente che avete fissato, la destinazione provata, la direzione rimasta a zero e lo SPI che stavate leggendo. Quella frase separa un’associazione che nessuno ha usato da un’applicazione remota che ha ricevuto il traffico e l’ha rifiutato. Annullate la modifica quando non ha mosso i contatori e conservate il record; la persona successiva parte da dove vi siete fermati. Nulla del tunnel ha dovuto essere ricostruito per tutto questo, ed è proprio il senso di verificare la corrispondenza prima di toccare la configurazione.