Distinguere la frammentazione IKEv2 da un problema di catena di certificati

Il tunnel funzionava sulla rete dell’ufficio e si blocca a casa, e il registro mostra il primo scambio completarsi prima che accada qualsiasi altra cosa. Questo schema indica lo scambio di autenticazione, non le credenziali: una catena di certificati rende quel messaggio molto più grande del precedente, e un percorso che non ama i datagrammi grandi lo scarta in silenzio. Sono coinvolti due meccanismi di frammentazione diversi, e sapere quale si sta guardando decide la correzione.

Due meccanismi di frammentazione, un sintomo

IKEv2 ha la propria estensione di frammentazione, definita nella RFC 7383, che divide i messaggi IKE protetti in messaggi IKE più piccoli. I peer negoziano questa capacità, e un messaggio viene riassemblato dall’implementazione IKE anziché dal livello IP.

La frammentazione IP ordinaria è un meccanismo diverso con una modalità di errore diversa. Un router tra i peer frammenta un datagramma grande, oppure lo scarta e restituisce un messaggio ICMP che forse non raggiungerà mai il mittente. Alcune reti scartano i frammenti in silenzio, e alcuni dispositivi intermedi gestiscono il primo frammento ma non il resto. Dal punto di vista dell’applicazione, i tre casi sembrano identici.

L’attraversamento NAT aggiunge una terza variabile, perché allora ESP viene incapsulato in UDP e il pacchetto esterno diventa più grande mentre sembra normale traffico UDP sulla porta 4500. Un percorso che lascia passare bene l’UDP può comunque fallire su un datagramma che non ci sta più.

Leggere lo scambio che ha fallito

Cercate la transizione, non l’errore. Un registro che mostra lo scambio iniziale inviato e risposto, seguito da nulla, vi dice che il messaggio successivo non è mai stato completato. Alzate temporaneamente il livello di registro e confrontate le dimensioni riportate su entrambi i peer.

Ciò che volete stabilire è se il risponditore ha visto la richiesta. Se l’iniziatore ha inviato qualcosa e il risponditore non ne ha alcuna traccia, il problema è la consegna. Se il risponditore ha analizzato una richiesta e l’ha rifiutata, il problema è il certificato stesso, e la frammentazione è una distrazione. Questa distinzione vale più di una pagina di messaggi di timeout.

Cambiate il percorso, non il certificato

Provate lo stesso client, lo stesso certificato e la stessa configurazione da un’altra rete. Un hotspot mobile è di solito il secondo percorso più economico, ed è davvero diverso dal collegamento dell’ufficio, non solo nominalmente.

Se la stretta di mano si completa sul secondo percorso, la catena di certificati va bene e il primo percorso è la variabile. Se fallisce in modo identico su entrambi, smettete di provare reti e guardate i messaggi stessi. Quell’unico confronto elimina circa la metà delle spiegazioni possibili.

Misurate lo scambio prima di modificare qualcosa

Ottenete la dimensione della catena e la dimensione del percorso. Entrambi i numeri limitano ciò che la stretta di mano può inviare, ed entrambi si misurano a poco prezzo:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

I primi due danno il numero di certificati e la dimensione del file, che è un indicatore ragionevole di quanto grande sarà il messaggio di autenticazione. La sonda ping riporta se un datagramma di quella dimensione sopravvive al percorso, e i contatori dell’interfaccia mostrano se i frammenti sono stati scartati dalla vostra parte. Su Windows, la sonda equivalente è un ping con il flag do-not-fragment e una dimensione del payload esplicita.

Ripetete la sonda verso il basso finché non riesce. La dimensione più grande che passa è il budget di lavoro per quel percorso, ed è più utile di qualsiasi valore predefinito pubblicato.

Riparate lo strato che è davvero rotto

Se il percorso scarta i datagrammi grandi, abilitate la frammentazione IKE su entrambi i peer e confermate che l’estensione è stata negoziata e non solo offerta. Se il percorso gestisce male i frammenti a livello IP, la correzione appartiene a quel punto o all’MTU dell’interfaccia esterna, non all’archivio dei certificati.

Se la catena è inutilmente lunga, riducetela ai certificati intermedi di cui un peer ha davvero bisogno. Rimuovere una radice di cui il client si fida già è manutenzione ragionevole; rimuovere un intermedio non lo è, e disattivare la verifica per ridurre un messaggio scambia un problema di consegna con uno di sicurezza.

Annotate quale meccanismo avete cambiato e come appariva la stretta di mano dopo. L’occorrenza successiva è di solito su un’altra rete con lo stesso sintomo, e la nota è ciò che trasforma due ore in dieci minuti.