Quando IKEv2 restituisce TS_UNACCEPTABLE, confronta le sottoreti reali

Leggi TS_UNACCEPTABLE come un disaccordo sulla copertura, non come un profilo corrotto. Il gateway sta dicendo che i due peer non sono riusciti a concordare quali indirizzi questo tunnel può trasportare. L'IKE SA può già essere attiva in quel momento, ed è per questo che un client può sembrare connesso senza alcuna SA figlia dietro. Una volta inquadrato così, il lavoro diventa meccanico. Annota i prefissi previsti di entrambi i lati, confrontali in una sola direzione e restringi finché non si intersecano.

Annota prima le coppie previste

Prima di toccare la configurazione, elenca quattro valori: l'intervallo di origine dell'iniziatore, il suo intervallo di destinazione e la stessa coppia vista dal risponditore. Annota anche la famiglia di indirizzi di ciascuno. Un intervallo IPv4 e un intervallo IPv6 sono tipi di selettore diversi, e nessuno dei due può essere ripiegato nel payload dell'altro.

Aggiungi qualsiasi restrizione di protocollo o di porta che la politica porta con sé. Una regola che consente solo TCP 445 verso un server di file descrive un insieme più ristretto della sottorete in cui si trova. Se lo lasci fuori dalle tue note, il risultato della negoziazione sembrerà incoerente per ragioni che non vedi.

Inverti le etichette prima di confrontarle

Locale e remoto sono etichette relative. Il prefisso locale del client è l'intervallo remoto del gateway, e l'intervallo locale del gateway è quello remoto del client. Per questo le schermate dei due estremi non coincidono mai, e confrontarle alla lettera è il modo abituale di perdere un pomeriggio.

Un risponditore può restringere un'offerta a un sottoinsieme accettabile invece di rifiutarla. Quel risultato è peggiore di un fallimento pulito, perché funziona a metà. Chiedi 10.0.0.0/16 quando la politica consente 10.0.5.0/24 e puoi ritrovarti con una SA figlia che copre solo quella /24. Un host risponde, tutto il resto resta fuori, e nulla nel client lo dice. Leggi i selettori accettati invece di quelli richiesti prima di concludere che la negoziazione è riuscita.

I profili road warrior che chiedono una rotta predefinita finiscono qui continuamente. Un gateway costruito per l'accesso diviso restringe un'offerta a intervallo completo alle proprie sottoreti, e il client deve accettare il risultato ristretto o fallire rumorosamente.

Leggi il rifiuto da un solo tentativo

Raccogli entrambi i registri dallo stesso tentativo di connessione. Un profilo salvato mostra ciò che hai configurato, non ciò che è stato proposto, e su strongSwan swanctl --log stampa la notifica ricevuta insieme ai selettori che portava.

Poi controlla cosa è stato realmente installato. swanctl --list-sas mostra i selettori della SA figlia, e ip xfrm policy mostra gli stessi intervalli come voci di politica del kernel. Una SA figlia in quell'elenco con selettori che non intendevi è un evento di restringimento; nessuna SA figlia più TS_UNACCEPTABLE nel registro è un rifiuto.

Finché sei lì, separa i vicini prossimi. INVALID_SELECTORS si lamenta di un selettore dentro una SA figlia stabilita, mentre INTERNAL_ADDRESS_FAILURE significa che il risponditore non è riuscito ad assegnare un indirizzo virtuale, che è un problema di pool e non di copertura.

Controlla cosa restringe l'insieme in silenzio

Tre cose restringono un insieme di selettori senza dire nulla. La politica del risponditore è la prima, tramite elenchi di sottoreti, regole di gruppo o autorizzazione per utente che riducono l'offerta a un sottoinsieme. La famiglia di indirizzi è la seconda: un client dual stack propone spesso IPv6 accanto a IPv4 e riceve un rifiuto per intervalli che il gateway non ha mai configurato.

Le restrizioni di protocollo e porta sono la terza. Dove la politica consente solo TCP 445, una SA figlia può salire mentre ICMP e UDP restano fuori, e l'utente segnala un tunnel rotto quando un solo protocollo era tutto ciò che era mai stato permesso.

Quindi ampliare solo gli indirizzi non può correggere una politica limitata per porta, e questo è il caso che più probabilmente sopravvive intatto a tre giri di diagnostica.

Dimostra la copertura con traffico adatto

Dopo che la SA figlia è installata, invia una richiesta che cade sicuramente dentro gli intervalli accettati. Guarda i contatori invece dell'icona di stato: ip -s xfrm state e i contatori dietro ip xfrm policy aumentano quando un pacchetto viene associato e protetto. Un conteggio di byte che resta a zero dopo traffico reale significa che il kernel non ha mai selezionato quella politica.

Quello zero è un problema di instradamento o di ordine delle politiche, non di crittografia. Sembra anche identico a un rifiuto di selettore dal posto dell'utente, ed è per questo che vale la pena raccogliere i contatori prima di riaprire il profilo. I contatori che salgono solo in una direzione indicano invece il percorso di ritorno.

Termina scrivendo la coppia accettata nel ticket, accanto all'intervallo richiesto in origine. Mantieni la selezione stretta quanto il requisito, perché eliminare l'errore sostituendo un intervallo privato con tutti gli indirizzi concede molto più accesso di quanto sia stato approvato per l'account.