UDP-VPN tavst ved en portskanning? Derfor sker det
WireGuard og hærdet OpenVPN dropper datagrammer, der ikke består autentificering, uden at svare. Tavshed fra en scanner er forventet adfærd, ikke en lukket port.
Du scanner VPN-porten, får intet svar og konkluderer, at tjenesten er nede, eller at firewallen er lukket. Med WireGuard og med OpenVPN-kontrolkanaler, der bærer deres egen autentificering, holder den konklusion ikke. Et datagram uden gyldigt autentificeringsmateriale kasseres uden svar, så tavshed er, hvordan en sund tjeneste ser ud udefra. Proben er forkert, før tunnelen er.
Tavshed er protokollen, ikke en fejl
UDP har ingen forbindelsesopbygning, så der er ingen SYN og ingen bekræftelse, der kunne lade en scanner skelne en åben port fra en filtreret. En probe ankommer som et isoleret datagram, og tjenesten kontrollerer, om det matcher den protokol, den forventer. Når det ikke gør, kasseres pakken, og kassering er den dokumenterede adfærd frem for en fejl.
WireGuard validerer sine handshake-beskeder kryptografisk og ignorerer alt, der fejler. OpenVPN med tls-auth eller tls-crypt gør det samme for sin kontrolkanal. I begge tilfælde når en vilkårlig payload aldrig et brugervendt trin, så der er intet at svare med og ingen fejl at returnere.
TCP ville have givet dig et reset fra en lukket port. UDP efterlader dig i tvetydighed, som scannere løser ved at udskrive åben eller filtreret i stedet for at gætte.
Hvad en scanner kan og ikke kan konkludere
Et scanningsresultat er kun så informativt som den payload, det sendte. Sortér de mulige observationer efter, hvad hver af dem faktisk understøtter:
| 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 række som den eneste positive test på listen. Den kræver den rigtige profil, den rigtige nøgle og det rigtige endpoint, og det er netop, hvad en generisk scanner ikke har.
Se på begge ender af stien
For en server, du administrerer, skal du opsnappe på interfacet, før du drager nogen konklusion, og derefter spørge tjenesten, hvad den så. Begge kommandoer kræver root på gatewayen:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showHvis ingen pakke vises på interfacet, droppede stien den, før tjenesten så noget, og næste stop er routing og filtrering. Hvis pakker ankommer, men ingen handshake fuldføres, er tjenesten tilgængelig, og uoverensstemmelsen ligger i nøgler, endpoint-konfiguration eller protokolversion. Den sammenligning besvarer det spørgsmål, scanneren ikke kunne. Kør den, mens en rigtig klient forsøger at forbinde, ikke mens scanneren gentager sig selv.
Skift testen, ikke beskyttelsen
Den fristende genvej er at slå kontrolkanalbeskyttelsen fra, så en diagnosticering får et svar. Det bytter en reel sikkerhedsegenskab for et pænere scanningsresultat, og det er den forkerte retning. Brug i stedet en gyldig profil fra et godkendt netværk, og notér endpoint og tid, så sammenligningen kan gentages.
Den mest nyttige test er en differentiel en: den samme profil på en sti, der virker, og på stien, der ikke gør. Hvis den fungerende sti giver et handshake, og den fejlende sti ikke giver noget på interfacet, har du lokaliseret bruddet uden at svække noget.
En ubesvaret UDP-pakke beviser derfor hverken, at serveren er offline, eller at den er sikker. Den beviser, at denne probe, på denne sti, i dette øjeblik, ikke blev accepteret.