VPN su UDP silenziosa durante una scansione delle porte? Perché accade

Scansionate la porta della VPN, non ricevete risposta e concludete che il servizio è inattivo o che il firewall è chiuso. Con WireGuard, e con i canali di controllo di OpenVPN che portano la propria autenticazione, quella conclusione non segue. Un datagramma privo di materiale di autenticazione valido viene scartato senza risposta, quindi il silenzio è l’aspetto di un servizio sano visto dall’esterno. La sonda è sbagliata prima che lo sia il tunnel.

Il silenzio è il protocollo, non un guasto

UDP non ha instaurazione di connessione, quindi non c’è SYN né alcun riscontro che permetta a uno scanner di distinguere una porta aperta da una filtrata. La sonda arriva come datagramma isolato e il servizio verifica se corrisponde al protocollo che si aspetta. Quando non corrisponde, il pacchetto viene scartato, e lo scarto è il comportamento documentato e non un malfunzionamento.

WireGuard convalida crittograficamente i propri messaggi di handshake e ignora tutto ciò che fallisce. OpenVPN con tls-auth o tls-crypt fa lo stesso per il suo canale di controllo. In entrambi i casi un carico arbitrario non raggiunge mai una fase rivolta all’utente, quindi non c’è nulla con cui rispondere e nessun errore da restituire.

TCP vi avrebbe dato un reset da una porta chiusa. UDP vi lascia nell’ambiguità, che gli scanner risolvono stampando aperta o filtrata invece di indovinare.

Cosa può e cosa non può concludere uno scanner

Il risultato di una scansione è tanto informativo quanto il carico che ha inviato. Ordinate le possibili osservazioni in base a ciò che ciascuna sostiene davvero:

Leggete la terza riga come l’unico test positivo dell’elenco. Richiede il profilo reale, la chiave reale e l’endpoint corretto, ed è esattamente ciò che uno scanner generico non ha.

Guardate entrambe le estremità del percorso

Per un server che amministrate, catturate sull’interfaccia prima di trarre qualsiasi conclusione, poi chiedete al servizio cosa ha visto. Entrambi i comandi richiedono root sul gateway:

tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg show

Se sull’interfaccia non compare alcun pacchetto, il percorso lo ha scartato prima che il servizio vedesse qualcosa, e la tappa successiva è l’instradamento e il filtraggio. Se i pacchetti arrivano ma nessun handshake si completa, il servizio è raggiungibile e la discrepanza è nelle chiavi, nella configurazione dell’endpoint o nella versione del protocollo. Quel confronto risponde alla domanda che lo scanner non poteva risolvere. Eseguitelo mentre un client reale tenta di connettersi, non mentre lo scanner ripete se stesso.

Cambiate il test, non la protezione

La scorciatoia tentante è disattivare la protezione del canale di controllo perché una diagnostica riceva risposta. Questo baratta una proprietà di sicurezza reale con un risultato di scansione più bello, ed è la direzione sbagliata. Usate invece un profilo valido da una rete approvata e annotate l’endpoint e l’ora perché il confronto sia ripetibile.

Il test più utile è differenziale: lo stesso profilo su un percorso che funziona e sul percorso che non funziona. Se il percorso funzionante produce un handshake e il percorso che fallisce non produce nulla sull’interfaccia, avete individuato il punto di rottura senza indebolire nulla.

Un pacchetto UDP senza risposta, quindi, non dimostra né che il server sia offline né che sia sicuro. Dimostra che questa sonda, su questo percorso, in questo momento, non è stata accettata.