ike-scan non riceve risposta da un apparato IPsec funzionante

Il gateway serve telefoni e portatili ogni giorno, eppure ike-scan riferisce che nessun host ha risposto. Quell’output sembra la prova che IPsec manchi dal dispositivo. Di solito significa che il dispositivo ha scartato ogni proposta della sonda e ha scelto di non rispondere nulla. Il silenzio è una risposta, ed è la meno informativa che lo strumento possa darti.

Affronta tre domande separate: il pacchetto è arrivato, qualche proposta ha corrisposto e qualcos’altro ha rifiutato il peer?

Passo 1: leggi la proposta che lo strumento invia

La modalità principale inizia con un payload SA che elenca le trasformazioni che l’iniziatore accetterà, e ike-scan riempie quell’elenco da un valore predefinito compilato. Il set predefinito è volutamente vecchio: DES e 3DES per la cifratura, MD5 e SHA1 per l’hashing, gruppi 1 e 2 per lo scambio di chiavi, chiavi pre-condivise per l’autenticazione. Nessun AES, nessun SHA-2, nessun gruppo 14. Un gateway configurato per AES-256 con SHA-256 e modp2048 non condivide nulla con esso.

Alcune implementazioni rispondono a una sonda non corrispondente con una notifica NO-PROPOSAL-CHOSEN. Altre la scartano semplicemente, cosa comune sugli apparati che trattano i peer sconosciuti come rumore. In ogni caso la scansione non stampa nulla, e quel nulla è identico a ciò che appare dall’esterno un UDP 500 filtrato, come la documentazione del progetto ike-scan chiarisce riguardo al set predefinito.

Passo 2: offri una proposta moderna

Sostituisci il set predefinito con --trans. La forma ad attributi prende direttamente i numeri di attributo IKE: 1 per la cifratura, 2 per l’hash, 3 per l’autenticazione, 4 per il gruppo e 14 per la lunghezza della chiave quando l’algoritmo la richiede. Quello che esce è una riga che puoi leggere ad alta voce in una revisione delle modifiche.

La forma posizionale porta gli stessi valori in ordine ed evita le parentesi, il che conta quando il comando passa attraverso una shell.

ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10

Una proposta per pacchetto è lenta quando enumeri, quindi cicla sui valori plausibili: cifratura 5, 7/128, 7/192, 7/256; hash 1, 2, 5, 6, 7; gruppi 1, 2, 5, 14, 15, 19, 20, 21; autenticazione 1 per una chiave pre-condivisa e 3 per le firme RSA. Stampa ogni comando prima di eseguirlo, così il transcript mostra cosa è stato offerto e in quale ordine.

Passo 3: interpreta una risposta

Una risposta prova esattamente due cose: un responder IKE è raggiungibile a quell’indirizzo e una proposta offerta era accettabile. Non dice nulla sulla chiave pre-condivisa, sul livello L2TP o sull’esistenza di un account utente. Una scansione riuscita è del tutto compatibile con il fallimento di ogni fase successiva.

Su un gateway che gestisci, questa è la parte davvero utile. La scansione ti dice quali proposte il dispositivo accetta ancora, e un risultato limitato a trasformazioni legacy è una scoperta sulla politica del dispositivo, non un motivo per indebolire il client.

Passo 4: interpreta il silenzio

Il silenzio è una prova più debole di quanto sembri. Ogni proposta può essere stata rifiutata, UDP 500 e 4500 possono essere filtrati, l’origine può essere limitata nel traffico dopo una raffica, oppure il servizio può ascoltare su un indirizzo diverso da quello scansionato. Confronta il log IKE del gateway con un client che si connette già usando credenziali valide prima di concludere qualsiasi cosa sull’apparato.

Il comportamento a raffica rientra in quell’elenco perché l’enumerazione genera molti pacchetti in una finestra breve. Un gateway che risponde ai primi tentativi e poi tace sta descrivendo la sua politica anti-DoS, non il suo set di proposte.

Passo 5: registra ciò che hai dimostrato

Scrivi la combinazione accettata accanto alla versione del firmware, poi confrontala con le trasformazioni che i client che ti interessano offrono per impostazione predefinita. Il divario tra quelle due liste è il problema di configurazione, e la scansione lo ha solo reso visibile. Se le uniche proposte accettate sono quelle che non sceglieresti, la correzione appartiene alla politica del gateway o a un profilo client, mai alla sonda.

Una sonda che non ha mai risposto ha comunque risposto a qualcosa: mostra quali proposte questo dispositivo è disposto a discutere e quali preferirebbe lasciar cadere.