VPN per UDP en silenci durant un escaneig de ports? Per què passa
WireGuard i OpenVPN endurit descarten els datagrames que fallen l’autenticació sense respondre. El silenci d’un escàner és el comportament esperat, no un port tancat.
Escanegeu el port del VPN, no rebeu cap resposta i concloeu que el servei està caigut o que el tallafoc és tancat. Amb WireGuard, i amb els canals de control d’OpenVPN que porten la seva pròpia autenticació, aquesta conclusió no es dedueix. Un datagrama sense material d’autenticació vàlid es descarta sense resposta, així que el silenci és com es veu un servei sa des de fora. La sonda està malament abans que ho estigui el túnel.
El silenci és el protocol, no una avaria
L’UDP no té establiment de connexió, així que no hi ha SYN ni cap confirmació que permeti a un escàner distingir un port obert d’un de filtrat. La sonda arriba com un datagrama aïllat, i el servei comprova si coincideix amb el protocol que espera. Quan no coincideix, el paquet es descarta, i descartar-lo és el comportament documentat i no un mal funcionament.
WireGuard valida criptogràficament els seus missatges de handshake i ignora tot el que falla. OpenVPN amb tls-auth o tls-crypt fa el mateix amb el seu canal de control. En tots dos casos una càrrega arbitrària no arriba mai a una etapa orientada a l’usuari, així que no hi ha res amb què respondre ni cap error a retornar.
El TCP us hauria donat un reset d’un port tancat. L’UDP us deixa en l’ambigüitat, que els escàners resolen imprimint obert o filtrat en comptes d’endevinar.
Què pot i què no pot concloure un escàner
El resultat d’un escaneig és tan informatiu com la càrrega que ha enviat. Ordeneu les observacions possibles segons què recolza realment cadascuna:
| Probe | Observed result | What it supports |
|---|---|---|
| Empty datagram | No reply | Nothing beyond the fact that UDP was used |
| Random payload | No reply | Consistent with an authenticated service |
| Valid handshake from a real client | A protocol reply | The service is alive and reachable |
| ICMP port unreachable | Unreachable message | The host answered, usually because nothing listens |
Llegiu la tercera fila com l’única prova positiva de la llista. Requereix el perfil real, la clau real i el punt final correcte, que és exactament el que un escàner genèric no té.
Mireu els dos extrems del camí
Per a un servidor que administreu, captureu a la interfície abans de treure cap conclusió i després pregunteu al servei què ha vist. Totes dues ordres necessiten root a la passarel·la:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showSi no apareix cap paquet a la interfície, el camí l’ha descartat abans que el servei veiés res, i la propera parada és l’encaminament i el filtratge. Si els paquets arriben però no es completa cap handshake, el servei és abastable i la discrepància és a les claus, a la configuració del punt final o a la versió del protocol. Aquesta comparació respon la pregunta que l’escàner no podia. Executeu-la mentre un client real intenta connectar-se, no mentre l’escàner es repeteix.
Canvieu la prova, no la protecció
La drecera temptadora és desactivar la protecció del canal de control perquè un diagnòstic rebi resposta. Això canvia una propietat de seguretat real per un resultat d’escaneig més bonic, i és la direcció equivocada. Feu servir un perfil vàlid d’una xarxa aprovada i anoteu el punt final i l’hora perquè la comparació sigui repetible.
La prova més útil és una de diferencial: el mateix perfil en un camí que funciona i en el camí que no. Si el camí que funciona produeix un handshake i el camí que falla no produeix res a la interfície, heu localitzat el trencament sense afeblir res.
Un paquet UDP sense resposta, doncs, no demostra ni que el servidor estigui fora de línia ni que sigui segur. Demostra que aquesta sonda, en aquest camí, en aquest moment, no s’ha acceptat.