La scansione UDP dice filtrato: il tuo peer WireGuard è davvero giù?

Gli scanner stampano aperto o filtrato per una porta UDP, e la conclusione di solito arriva in pochi secondi: il tunnel è rotto. Può esserlo, ma la scansione non lo ha dimostrato. UDP non trasporta alcun handshake di connessione, e WireGuard non risponde a nulla che non possa autenticare, quindi il silenzio è la risposta attesa alla maggior parte delle sonde.

Lavora invece dal client verso l’esterno, e tratta la scansione come un debole punto dati tra diversi altri.

Cosa può vedere lo scanner e cosa no

Uno scanner UDP invia un payload e attende. Se torna un ICMP port-unreachable, può segnalare la porta come chiusa. Se non torna nulla, il risultato è ambiguo per progettazione: un percorso filtrato, un host assente e un servizio in esecuzione che ha ignorato il payload producono tutti lo stesso silenzio. Tre stati diversi, un’unica stringa di output.

WireGuard peggiora quell’ambiguità di proposito. Il protocollo accetta un pacchetto solo quando si autentica, quindi una sonda con le chiavi sbagliate viene scartata senza risposta. Non ci sono banner, stringhe di versione né messaggi di errore da improntare.

Un test TCP sullo stesso numero di porta non verifica nulla di correlato. Esercita un altro listener che potrebbe non esistere, e il suo rifiuto non dice nulla su UDP.

Gli stati aperti filtrati descrivono quindi l’incertezza dello scanner con più precisione di quanto descrivano il tuo server.

Percorri il client reale dal profilo verso l’interno

Parti dalla visuale del client stesso. L’interfaccia ha un indirizzo, la configurazione nomina l’endpoint corretto e il contatore degli handshake si muove quando si tenta una connessione? Un client che non ha mai inviato un pacchetto e un client i cui pacchetti sono stati scartati appaiono identici in una finestra di stato. Solo i contatori li distinguono, quindi leggi prima i contatori.

Poi osserva il lato server mentre avviene un tentativo autorizzato, invece di eseguire una scansione separata da una terza posizione:

wg show wg0 latest-handshakes
tcpdump -n -i eth0 udp port 51820 -c 10

Il primo comando riporta l’ultimo handshake per peer, che è prova diretta del completamento di uno scambio autenticato. Il secondo mostra se i pacchetti per il listener arrivano del tutto, il che separa un problema di percorso da un problema di configurazione in un solo passaggio.

Se la cattura non mostra nulla, il pacchetto non ha mai raggiunto l’host e la configurazione del tunnel non è la sospetta. Se mostra pacchetti in arrivo dall’indirizzo atteso mentre l’handshake resta a zero, le chiavi o gli indirizzi consentiti del peer sono il prossimo posto da guardare.

Correla sul server quando lo amministri

Conferma che il listener esista e che il firewall del provider consenta la porta UDP. Una regola di firewall dell’host e un gruppo di sicurezza cloud sono due cancelli indipendenti, e ciascuno può scartare un pacchetto che l’altro ha consentito. Controlla entrambi rispetto alla porta reale nella configurazione, non alla porta che ricordi.

L’indirizzo conta quanto la porta. Un server in ascolto su un indirizzo specifico non risponderà a un pacchetto che arriva su un altro, e un host multi-interfaccia può ricevere la sonda sull’interfaccia che non intendevi.

Tieni ogni test dentro sistemi che sei autorizzato a testare. Il confronto utile è tra un tentativo reale del client e il percorso atteso del server, non una scansione più ampia di indirizzi che appartengono per caso allo stesso provider.

Leggere con onestà un risultato di scansione

Una scansione è un modo economico per verificare che un host esista e che una porta non sia ovviamente bloccata da un dispositivo intermedio. Non è una prova di raggiungibilità per un protocollo autenticato, e di certo non è un test di configurazione.

La prova più solida è un handshake completato dal client che ti interessa davvero, seguito da una richiesta che usa il tunnel e ottiene una risposta. Quella sequenza esercita le chiavi, gli indirizzi consentiti, entrambi i firewall e il percorso di ritorno in un colpo solo.

Quando il tentativo reale fallisce, il guasto va comunque diagnosticato con i contatori del client e la cattura del server, non con un’altra sonda. La descrizione del protocollo spiega perché un pacchetto non autenticato non riceve risposta, ed è l’intera ragione per cui il risultato della scansione è ambiguo.