UDP-VPN stille ved en portskanning? Derfor skjer det
WireGuard og herdet OpenVPN dropper datagrammer som ikke består autentisering, uten å svare. Stillhet fra en skanner er forventet atferd, ikke en lukket port.
Du skanner VPN-porten, får ingen svar og konkluderer med at tjenesten er nede eller at brannmuren er lukket. Med WireGuard, og med OpenVPN-kontrollkanaler som bærer sin egen autentisering, følger ikke den konklusjonen. Et datagram uten gyldig autentiseringsmateriale forkastes uten svar, så stillhet er hvordan en sunn tjeneste ser ut utenfra. Proben er feil før tunnelen er det.
Stillhet er protokollen, ikke en feil
UDP har ingen oppkobling, så det finnes ingen SYN og ingen bekreftelse som ville la en skanner skille en åpen port fra en filtrert. En probe kommer inn som et isolert datagram, og tjenesten sjekker om det samsvarer med protokollen den forventer. Når det ikke gjør det, forkastes pakken, og forkasting er den dokumenterte atferden og ikke en feil.
WireGuard validerer handshake-meldingene sine kryptografisk og ignorerer alt som feiler. OpenVPN med tls-auth eller tls-crypt gjør det samme for kontrollkanalen sin. I begge tilfeller når en vilkårlig nyttelast aldri et brukervendt trinn, så det er ingenting å svare med og ingen feil å returnere.
TCP ville ha gitt deg en reset fra en lukket port. UDP lar deg sitte igjen med tvetydighet, som skannere løser ved å skrive ut åpen eller filtrert i stedet for å gjette.
Hva en skanner kan og ikke kan konkludere
Et skanneresultat er bare så informativt som nyttelasten det sendte. Sorter de mulige observasjonene etter hva hver av dem faktisk stø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 |
Les den tredje raden som den eneste positive testen i listen. Den krever den ekte profilen, den ekte nøkkelen og riktig endepunkt, og det er nettopp det en generisk skanner ikke har.
Se på begge ender av veien
For en server du administrerer, fang opp på grensesnittet før du trekker noen konklusjon, og spør deretter tjenesten hva den så. Begge kommandoene krever root på gatewayen:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showHvis ingen pakke dukker opp på grensesnittet, droppet veien den før tjenesten så noe, og neste stopp er ruting og filtrering. Hvis pakker kommer inn, men ingen handshake fullføres, er tjenesten tilgjengelig, og avviket ligger i nøkler, endepunktkonfigurasjon eller protokollversjon. Den sammenligningen svarer på spørsmålet skanneren ikke kunne. Kjør den mens en ekte klient prøver å koble til, ikke mens skanneren gjentar seg selv.
Endre testen, ikke beskyttelsen
Den fristende snarveien er å slå av beskyttelsen av kontrollkanalen slik at en diagnose får svar. Det bytter en reell sikkerhetsegenskap mot et penere skanneresultat, og det er feil retning. Bruk i stedet en gyldig profil fra et godkjent nettverk, og noter endepunktet og tidspunktet slik at sammenligningen kan gjentas.
Den nyttigste testen er en differensiell: samme profil på en vei som virker og på veien som ikke virker. Hvis den fungerende veien gir en handshake og den feilende veien ikke gir noe på grensesnittet, har du lokalisert bruddet uten å svekke noe.
En ubesvart UDP-pakke beviser derfor verken at serveren er frakoblet eller at den er trygg. Den beviser at denne proben, på denne veien, i dette øyeblikket, ikke ble godtatt.