ESP decifra correttamente e il pacchetto interno non arriva comunque da nessuna parte

Il contatore di ricezione ESP sale, il tunnel resta attivo e l'applicazione non vede mai il pacchetto. La decifratura è avvenuta, la verifica di integrità è passata, poi il ricevente ha dovuto decidere che cosa sia davvero il carico protetto. È proprio in quest'ultimo passo che compare una discrepanza di formato, e dall'esterno non somiglia affatto a un problema di firewall.

Che cosa vedi quando l'etichetta mente

Niente nel log del client lo distingue da un buco nero di routing. Entrambi producono un timeout dell'applicazione accanto a un tunnel sano, ed è per questo che i contatori vengono incolpati per primi.

Un contatore di ricezione che sale è davvero una buona notizia: i pacchetti arrivano e si autenticano. Non è la prova che il pacchetto interno avesse senso per qualcosa sopra lo strato crittografico.

Il tipo vive nel trailer

In modalità tunnel IPsec ordinaria, il carico protetto da ESP contiene un pacchetto IP interno completo. Il campo di intestazione successiva nel trailer identifica che cosa sia quel carico, e non è una porta TCP, non è un numero di protocollo nell'intestazione esterna e non fa parte del campo iniziale SPI e numero di sequenza. RFC 4303 sezione 2.6 lo definisce come campo del tipo di carico, che è un nome preciso per un compito preciso.

I valori che incontrerai sono piccoli e vale la pena ricordarli: IPv4 è 4 (0x04) e IPv6 è 41 (0x29).

Quei numeri vengono dalle assegnazioni dei numeri di protocollo della IANA e non da una convenzione locale. Un mittente che dichiara IPv4 mentre incapsula un pacchetto IPv6 ha prodotto un'incoerenza di formato, e nessuna regola di firewall ripara byte che contraddicono la propria etichetta.

Come distinguerlo dai soliti sospetti

La maggior parte dei pacchetti mancanti non è un difetto di codifica. Controlla prima i selettori, perché un selettore di traffico che esclude il prefisso IPv6 scarta il traffico prima che qualsiasi cosa venga incapsulata. Poi controlla il routing, quindi il filtraggio locale sull'host ricevente. Solo dopo aver escluso questo, una discrepanza di formato del carico diventa una spiegazione plausibile.

Una cattura cifrata non lo risolverà, perché l'intestazione successiva protetta sta dentro il carico cifrato. Servono diagnostiche dell'implementazione o un punto di osservazione decifrato supportato, ed entrambi richiedono autorizzazione prima dell'uso.

Se nessuno può produrre quella prova, non hai un bug di formato. Hai una teoria, e i selettori restano la scommessa migliore.

Che cosa non è la riparazione

Non disattivare i controlli di integrità per far passare il traffico. Non riscrivere pacchetti cifrati su un router intermedio, perché non può funzionare e corromperà il flusso mentre sembra utile in una cattura. Non aprire una regola di firewall applicativa più ampia sulla teoria che una porta sia bloccata. Niente di tutto ciò tocca la discrepanza di etichetta.

Se una discrepanza confermata arriva da un'implementazione pari, conserva una riproduzione minima e ripulita e portala al canale supportato di quell'implementazione.

Verifica il flusso, non il contatore

Dopo la correzione, prova il flusso IPv6 reale da un capo all'altro: una richiesta applicativa attraverso il tunnel, la sua risposta e la coppia di indirizzi che ciascun lato osserva. Un contatore ESP che sale dimostra soltanto che i pacchetti vengono ricevuti e autenticati. Non dice nulla sul fatto che il pacchetto interno fosse utilizzabile.

Registra entrambi i risultati nel ticket. Movimento del contatore più un flusso funzionante è una riparazione; movimento del contatore da solo è esattamente quello che avevi prima di iniziare.