UDP-VPN stille ved ein portskann? Kvifor det skjer
WireGuard og herda OpenVPN kastar datagram som ikkje greier autentisering, utan å svare. Stillheit frå ein skannar er venta åtferd, ikkje ein lukka port.
Du skannar VPN-porten, får ikkje svar og konkluderer med at tenesta er nede eller at brannmuren er lukka. Med WireGuard, og med OpenVPN-kontrollkanalar som ber si eiga autentisering, følgjer ikkje den konklusjonen. Eit datagram utan gyldig autentiseringsmateriale blir forkasta utan svar, så stillheit er korleis ei sunn teneste ser ut utanfrå. Proba er feil før tunnelen er det.
Stillheit er protokollen, ikkje ein feil
UDP har inga oppkopling, så det finst ingen SYN og inga stadfesting som ville la ein skannar skilje ein open port frå ein filtrert. Ei probe kjem inn som eit isolert datagram, og tenesta sjekkar om det samsvarer med protokollen ho ventar. Når det ikkje gjer det, blir pakken forkasta, og forkasting er den dokumenterte åtferda og ikkje ein feil.
WireGuard validerer handshake-meldingane sine kryptografisk og ignorerer alt som feilar. OpenVPN med tls-auth eller tls-crypt gjer det same for kontrollkanalen sin. I båe tilfelle når ei vilkårleg nyttelast aldri eit brukarvendt trinn, så det er ingenting å svare med og ingen feil å returnere.
TCP ville ha gitt deg ein reset frå ein lukka port. UDP lèt deg sitje att med tvitydigheit, som skannarar løyser ved å skrive ut open eller filtrert i staden for å gisse.
Kva ein skannar kan og ikkje kan konkludere
Eit skannresultat er berre så informativt som nyttelasta det sende. Sorter dei moglege observasjonane etter kva kvar av dei faktisk støttar:
| 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 |
Les den tredje rada som den einaste positive testen i lista. Han krev den ekte profilen, den ekte nøkkelen og rett endepunkt, og det er nettopp det ein generisk skannar ikkje har.
Sjå på båe endar av vegen
For ein server du administrerer, fang opp på grensesnittet før du dreg nokon konklusjon, og spør deretter tenesta kva ho såg. Båe kommandoane krev root på gatewayen:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showViss ingen pakke dukkar opp på grensesnittet, kasta vegen han før tenesta såg noko, og neste stopp er ruting og filtrering. Viss pakkar kjem inn, men ingen handshake blir fullført, er tenesta tilgjengeleg, og avviket ligg i nøklar, endepunktkonfigurasjon eller protokollversjon. Den samanlikninga svarar på spørsmålet skannaren ikkje kunne. Køyr henne medan ein ekte klient prøver å kople til, ikkje medan skannaren gientar seg sjølv.
Endre testen, ikkje vernet
Den freistande snarvvegen er å slå av vernet av kontrollkanalen slik at ein diagnostikk får svar. Det byter ein reell tryggleikseigenskap mot eit penare skannresultat, og det er feil retning. Bruk i staden ein gyldig profil frå eit godkjent nettverk, og noter endepunktet og tidspunktet slik at samanlikninga kan gjerast om att.
Den nyttigaste testen er ein differensiell: same profil på ein veg som verkar og på vegen som ikkje verkar. Viss den fungerande vegen gir ein handshake og den feilande vegen ikkje gir noko på grensesnittet, har du lokalisert brotet utan å svekkje noko.
Ein ubesvart UDP-pakke beviser derfor korkje at serveren er fråkopla eller at han er trygg. Han beviser at denne proba, på denne vegen, i dette augeblikket, ikkje vart godteken.