IPsec multi-sottorete perde il traffico di ritorno? Contate i reqid

Il traffico lascia un sito e non torna mai, entrambi i gateway riportano una negoziazione completata, e l'unico indizio è una pila di pacchetti in uscita senza risposte. Su un endpoint Linux la causa abituale non è la forza della cifratura, l'MTU o una tabella di routing. È la granularità delle voci di policy e il numero che collega ogni policy a un'associazione di sicurezza. La procedura qui sotto legge quei due database prima di toccare qualsiasi altra cosa.

Separate il sintomo prima di cambiare qualcosa

Un guasto a senso unico con una negoziazione IKE completata restringe il problema al percorso dei dati. O la policy in uscita corrispondeva e la risposta è stata scartata, oppure la risposta non è mai arrivata perché l'altro lato non aveva nulla con cui inviarla. Per un'applicazione i due casi sembrano identici, e i database xfrm li distinguono.

Non partite dall'MTU. Un MTU errato produce blocchi e sintomi di frammentazione, non una netta separazione di direzione con contatori in uscita che salgono.

Leggete il database delle policy e quello degli stati

Su Linux la cifratura è decisa dalle voci di policy, quindi una policy corrispondente, non una rotta, è ciò che mette un pacchetto nel tunnel. Eseguite ip xfrm policy per vedere selettori, direzione, priorità e modello di ogni voce, e ip xfrm state per vedere le associazioni stabilite con i loro reqid. La policy e l'associazione sono unite da quel reqid.

Guardate tutte e tre le direzioni. In uscita e in entrata coprono il traffico da e verso questo host; la direzione di inoltro conta quando l'host fa routing per altri. Una voce mancante o discordante in una direzione spiega un risultato a senso unico senza alcun difetto crittografico.

L'asimmetria classica: un reqid per più sottoreti

Un guasto comune viene da un peer che installa policy per tutte le sottoreti negoziate sotto un unico reqid, cosa che accade con generate_policy require di racoon. Il traffico esce allora dall'associazione stabilita per ultima, mentre l'altro lato mantiene un'associazione separata per sottorete. Le risposte arrivano su un'associazione il cui reqid non identifica la policy che dovrebbe accettarle, e il kernel le scarta dopo la decifratura.

La correzione è una modifica di configurazione, non una regola del firewall: generate_policy unique; dà a ogni policy il proprio reqid, così le associazioni per policy del peer hanno partner corrispondenti. Applicatela, rinegoziate e contate i reqid distinti per le sottoreti attese prima di dichiarare il successo.

Se due sottoreti condividono ancora un reqid mentre l'altro lato ne aspetta due, avete trovato l'asimmetria. Registrate la mappatura, perché è la prova che la modifica successiva l'ha corretta o conservata.

I selettori vengono dalla negoziazione, non dalla vostra configurazione

Gli intervalli protetti sono ciò su cui entrambe le estremità si sono accordate, non ciò che una parte ha chiesto. Un client che propone una coppia di host contro un ampio intervallo remoto riceve la versione ristretta del gateway, e il client non può ampliarla. Leggete i selettori installati invece di quelli nel vostro file locale.

Quando l'obiettivo è l'opposto, tenere una destinazione fuori dal tunnel, aggiungete una policy di bypass con un numero di priorità più basso così vince sulla voce installata automaticamente. Una policy senza modello consente il testo in chiaro, il che la rende un'eccezione deliberata per un registro delle modifiche invece di un passo di debug.

Verificate in questo ordine, e sappiate come tornare indietro

Elencate le policy per ogni sottorete in entrambe le direzioni, incluso l'inoltro se l'host fa routing. Contate i reqid distinti e confermatene uno per policy sul lato che lo aspetta. Confrontate i selettori installati con quelli negoziati. Rileggete i contatori per associazione dopo un rinnovo di chiave, perché l'associazione esaminata potrebbe essere già sparita. Controllate le rotte per ultime, poiché una rotta mancante verso la sottorete remota produce un sintomo a senso unico simile con contatori di policy puliti.

Prima di modificare il peer, salvate l'output attuale di entrambi i comandi xfrm. Se la nuova impostazione non ripristina la direzione di ritorno, ripristinare quell'output è un rollback più rapido che ricostruire il tunnel a memoria, e mantiene onesto il confronto.