UDP-VPN stil bij een poortscan? Waarom dat gebeurt
WireGuard en gehardened OpenVPN gooien datagrammen die niet authenticeren weg zonder te antwoorden. Stilte van een scanner is verwacht gedrag, geen gesloten poort.
Je scant de VPN-poort, krijgt geen antwoord en concludeert dat de dienst platligt of dat de firewall dicht is. Bij WireGuard, en bij OpenVPN-besturingskanalen die hun eigen authenticatie meebrengen, volgt die conclusie niet. Een datagram zonder geldig authenticatiemateriaal wordt zonder antwoord weggegooid, dus stilte is hoe een gezonde dienst er van buiten uitziet. De test klopt niet voordat de tunnel dat doet.
Stilte is het protocol, geen storing
UDP kent geen verbindingsopbouw, dus er is geen SYN en geen bevestiging waarmee een scanner een open poort van een gefilterde kan onderscheiden. Een probe komt binnen als een geïsoleerd datagram, en de dienst controleert of het bij het protocol past dat hij verwacht. Zo niet, dan wordt het pakket weggegooid, en weggooien is het gedocumenteerde gedrag en geen storing.
WireGuard valideert zijn handshake-berichten cryptografisch en negeert alles wat mislukt. OpenVPN doet met tls-auth of tls-crypt hetzelfde voor zijn besturingskanaal. In beide gevallen bereikt een willekeurige payload nooit een gebruikersgerichte fase, dus er is niets om mee te antwoorden en geen fout om terug te geven.
TCP zou je een reset van een gesloten poort hebben gegeven. UDP laat je achter met onduidelijkheid, die scanners oplossen door open of gefilterd af te drukken in plaats van te gissen.
Wat een scanner wel en niet kan concluderen
Een scanresultaat is alleen zo informatief als de payload die het stuurde. Sorteer de mogelijke waarnemingen naar wat elk ervan werkelijk ondersteunt:
| 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 |
Lees de derde rij als de enige positieve test in de lijst. Die vereist het echte profiel, de echte sleutel en het juiste eindpunt, en dat is precies wat een generieke scanner niet heeft.
Kijk naar beide uiteinden van het pad
Voor een server die je beheert, leg vast op de interface voordat je enige conclusie trekt, en vraag daarna de dienst wat hij zag. Beide commando's vereisen root op de gateway:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showAls er geen pakket op de interface verschijnt, heeft het pad het weggegooid voordat de dienst iets zag, en de volgende stop is routing en filtering. Als pakketten aankomen maar er geen handshake voltooit, is de dienst bereikbaar en zit de mismatch in sleutels, eindpuntconfiguratie of protocolversie. Die vergelijking beantwoordt de vraag die de scanner niet kon. Voer hem uit terwijl een echte client probeert te verbinden, niet terwijl de scanner zichzelf herhaalt.
Verander de test, niet de bescherming
De verleidelijke kortere weg is de bescherming van het besturingskanaal uitzetten zodat een diagnose antwoord krijgt. Dat ruilt een echte beveiligingseigenschap voor een mooier scanresultaat, en dat is de verkeerde richting. Gebruik in plaats daarvan een geldig profiel uit een goedgekeurd netwerk, en noteer het eindpunt en de tijd zodat de vergelijking herhaalbaar is.
De nuttigste test is een differentiële: hetzelfde profiel op een pad dat werkt en op het pad dat dat niet doet. Als het werkende pad een handshake oplevert en het falende pad niets op de interface, heb je de breuk gelokaliseerd zonder iets te verzwakken.
Een onbeantwoord UDP-pakket bewijst dus niet dat de server offline is en ook niet dat hij veilig is. Het bewijst dat deze probe, op dit pad, op dit moment, niet is geaccepteerd.