UDP-scanning siger filtreret: er din WireGuard-modpart faktisk nede?

Scannere udskriver åben eller filtreret for en UDP-port, og konklusionen følger normalt inden for sekunder: tunnelen er brudt. Det kan den være, men scanningen har ikke påvist det. UDP bærer ingen forbindelseshåndtryk, og WireGuard svarer ikke på noget, den ikke kan autentificere, så tavshed er det forventede svar på de fleste prober.

Arbejd i stedet fra klienten og udad, og betragt scanningen som ét svagt datapunkt blandt flere.

Hvad scanneren kan og ikke kan se

En UDP-scanner sender en last og venter. Hvis der kommer en ICMP port-unreachable tilbage, kan den rapportere porten som lukket. Hvis intet kommer tilbage, er resultatet tvetydigt af design: en filtreret rute, en fraværende vært og en kørende tjeneste, der ignorerede lasten, giver alle samme tavshed. Tre forskellige tilstande, én outputstreng.

WireGuard gør den tvetydighed værre med vilje. Protokollen accepterer kun en pakke, når den autentificerer, så en probe med de forkerte nøgler kasseres uden svar. Der er ingen banner, ingen versionstreng og ingen fejlmeddelelse at fingerprinte.

En TCP-test på samme portnummer tester intet beslægtet. Den udøver en anden lytter, som måske ikke findes, og dens afvisning siger intet om UDP.

Åbne filtrerede tilstande beskriver derfor scannerens usikkerhed mere præcist, end de beskriver din server.

Gå den rigtige klient igennem fra profilen og indad

Begynd med klientens eget syn. Har interfacet en adresse, angiver konfigurationen det rigtige endepunkt, og flytter håndtrykstælleren sig, når der forsøges en forbindelse? En klient, der aldrig har sendt en pakke, og en klient, hvis pakker blev droppet, ser identiske ud i et statusvindue. Kun tællerne skelner dem, så læs tællerne først.

Overvåg derefter serversiden, mens ét autoriseret forsøg sker, i stedet for at køre en separat scanning fra et tredje sted:

wg show wg0 latest-handshakes
tcpdump -n -i eth0 udp port 51820 -c 10

Den første kommando rapporterer det sidste håndtryk pr. peer, hvilket er direkte bevis på, at en autentificeret udveksling blev gennemført. Den anden viser, om pakker til lytteren overhovedet ankommer, hvilket adskiller et ruteproblem fra et konfigurationsproblem i ét trin.

Hvis optagelsen intet viser, nåede pakken aldrig værten, og tunnelkonfigurationen er ikke den mistænkte. Hvis den viser pakker, der ankommer fra den forventede adresse, mens håndtrykket bliver på nul, er nøglerne eller modpartens tilladte adresser det næste sted at kigge.

Korreler på serveren, når du administrerer den

Bekræft, at lytteren findes, og at udbyderens firewall tillader UDP-porten. En værtsfirewallregel og en cloud-sikkerhedsgruppe er to uafhængige porte, og hver af dem kan droppe en pakke, som den anden tillod. Kontroller begge mod den faktiske port i konfigurationen i stedet for den port, du husker.

Adressen betyder lige så meget som porten. En server, der lytter på en bestemt adresse, svarer ikke på en pakke, der ankommer på en anden, og en vært med flere interfaces kan modtage proben på det interface, du ikke havde tænkt på.

Hold hver test inden for systemer, du har tilladelse til at teste. Den nyttige sammenligning er mellem ét rigtigt klientforsøg og den forventede serverrute, ikke en bredere gennemgang af adresser, der tilfældigvis tilhører samme udbyder.

At læse et scanningsresultat ærligt

En scanning er en billig måde at kontrollere, at en vært findes, og at en port ikke åbenlyst blokeres af en mellemliggende enhed. Det er ikke et nåbarhedsbevis for en autentificeret protokol, og det er bestemt ikke en konfigurationstest.

Det stærkere bevis er et gennemført håndtryk fra den klient, du faktisk bekymrer dig om, efterfulgt af en anmodning, der bruger tunnelen og får et svar. Den sekvens udøver nøglerne, de tilladte adresser, begge firewalls og returvejen på én gang.

Når det rigtige forsøg fejler, skal fejlen stadig diagnosticeres med klientens tællere og serverens optagelse i stedet for med endnu en probe. Protokolbeskrivelsen forklarer, hvorfor en uautentificeret pakke ikke får noget svar, og det er hele grunden til, at scanningsresultatet er tvetydigt.