UDP-VPN tyst vid en portskanning? Därför händer det
WireGuard och härdad OpenVPN släpper datagram som inte klarar autentisering utan att svara. Tystnad från en skanner är förväntat beteende, inte en stängd port.
Du skannar VPN-porten, får inget svar och drar slutsatsen att tjänsten är nere eller att brandväggen är stängd. Med WireGuard, och med OpenVPN-kontrollkanaler som bär sin egen autentisering, följer inte den slutsatsen. Ett datagram utan giltigt autentiseringsmaterial kastas utan svar, så tystnad är hur en frisk tjänst ser ut utifrån. Proben är fel innan tunneln är det.
Tystnaden är protokollet, inte ett fel
UDP har ingen anslutningsuppbyggnad, så det finns ingen SYN och ingen bekräftelse som skulle låta en skanner skilja en öppen port från en filtrerad. En probe anländer som ett isolerat datagram, och tjänsten kontrollerar om det matchar protokollet den förväntar sig. När det inte gör det kastas paketet, och kastande är det dokumenterade beteendet och inte en funktionsstörning.
WireGuard validerar sina handshake-meddelanden kryptografiskt och ignorerar allt som misslyckas. OpenVPN med tls-auth eller tls-crypt gör samma sak för sin kontrollkanal. I båda fallen når en godtycklig nyttolast aldrig ett användarvänt steg, så det finns inget att svara med och inget fel att returnera.
TCP skulle ha gett dig en reset från en stängd port. UDP lämnar dig i oklarhet, som skannrar löser genom att skriva ut öppen eller filtrerad i stället för att gissa.
Vad en skanner kan och inte kan dra för slutsats
Ett skanningsresultat är bara så informativt som nyttolasten det skickade. Sortera de möjliga observationerna efter vad var och en av dem faktiskt stöder:
| 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 |
Läs den tredje raden som det enda positiva testet i listan. Det kräver den riktiga profilen, den riktiga nyckeln och rätt slutpunkt, och det är just vad en generisk skanner inte har.
Titta på båda ändarna av vägen
För en server du administrerar, fånga på gränssnittet innan du drar någon slutsats, och fråga sedan tjänsten vad den såg. Båda kommandona kräver root på gatewayen:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showOm inget paket dyker upp på gränssnittet har vägen kastat det innan tjänsten såg något, och nästa stopp är routing och filtrering. Om paket kommer in men ingen handshake slutförs är tjänsten nåbar och avvikelsen ligger i nycklar, slutpunktskonfiguration eller protokollversion. Den jämförelsen svarar på frågan skannern inte kunde. Kör den medan en riktig klient försöker ansluta, inte medan skannern upprepar sig.
Ändra testet, inte skyddet
Den frestande genvägen är att stänga av skyddet för kontrollkanalen så att en diagnostik får svar. Det byter en verklig säkerhetsegenskap mot ett snyggare skanningsresultat, och det är fel riktning. Använd i stället en giltig profil från ett godkänt nätverk, och notera slutpunkten och tiden så att jämförelsen kan upprepas.
Det mest användbara testet är ett differentiellt: samma profil på en väg som fungerar och på vägen som inte fungerar. Om den fungerande vägen ger en handshake och den misslyckade vägen inte ger något på gränssnittet, har du lokaliserat brottet utan att försvaga något.
Ett obesvarat UDP-paket bevisar därför varken att servern är offline eller att den är säker. Det bevisar att denna probe, på denna väg, i detta ögonblick, inte accepterades.