UDP-skann sier filtrert: er WireGuard-motparten din faktisk nede?

Skannere skriver ut åpen eller filtrert for en UDP-port, og konklusjonen kommer vanligvis innen sekunder: tunnelen er ødelagt. Det kan den være, men skanningen har ikke påvist det. UDP bærer ingen tilkoblingshåndtrykk, og WireGuard svarer ikke på noe det ikke kan autentisere, så stillhet er det forventede svaret på de fleste prober.

Arbeid i stedet fra klienten og utover, og behandle skanningen som ett svakt datapunkt blant flere.

Hva skanneren kan og ikke kan se

En UDP-skanner sender en nyttelast og venter. Hvis det kommer en ICMP port-unreachable tilbake, kan den rapportere porten som lukket. Hvis ingenting kommer tilbake, er resultatet tvetydig av design: en filtrert rute, en fraværende vert og en kjørende tjeneste som ignorerte nyttelasten gir alle samme stillhet. Tre forskjellige tilstander, én utdatastreng.

WireGuard gjør den tvetydigheten verre med vilje. Protokollen godtar bare en pakke når den autentiserer seg, så en probe med feil nøkler forkastes uten svar. Det finnes ingen banner, ingen versjonsstreng og ingen feilmelding å fingeravtrykke.

En TCP-test på samme portnummer tester ingenting beslektet. Den øver en annen lytter som kanskje ikke finnes, og avvisningen sier ingenting om UDP.

Åpne filtrerte tilstander beskriver derfor skannerens usikkerhet mer presist enn de beskriver serveren din.

Gå gjennom den ekte klienten fra profilen og innover

Start med klientens eget syn. Har grensesnittet en adresse, navngir konfigurasjonen riktig endepunkt, og beveger håndtrykk-telleren seg når en tilkobling forsøkes? En klient som aldri sendte en pakke, og en klient hvis pakker ble droppet, ser identiske ut i et statusvindu. Bare tellerne skiller dem, så les tellerne først.

Se deretter på serversiden mens ett autorisert forsøk skjer, i stedet for å kjøre en separat skanning fra et tredje sted:

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

Den første kommandoen rapporterer siste håndtrykk per motpart, noe som er direkte bevis på at en autentisert utveksling ble fullført. Den andre viser om pakker for lytteren i det hele tatt ankommer, noe som skiller et ruteproblem fra et konfigurasjonsproblem i ett trinn.

Hvis opptaket ikke viser noe, nådde pakken aldri verten, og tunnelkonfigurasjonen er ikke den mistenkte. Hvis det viser pakker som ankommer fra den forventede adressen mens håndtrykket blir stående på null, er nøklene eller motpartens tillatte adresser neste sted å se.

Korreler på serveren når du administrerer den

Bekreft at lytteren finnes og at leverandørens brannmur tillater UDP-porten. En vertsbrannmurregel og en skysikkerhetsgruppe er to uavhengige porter, og hver av dem kan droppe en pakke som den andre tillot. Kontroller begge mot den faktiske porten i konfigurasjonen i stedet for porten du husker.

Adressen betyr like mye som porten. En server som lytter på en bestemt adresse, svarer ikke på en pakke som ankommer på en annen, og en vert med flere grensesnitt kan motta proben på grensesnittet du ikke mente.

Hold hver test innenfor systemer du har tillatelse til å teste. Den nyttige sammenligningen er mellom ett ekte klientforsøk og den forventede serverruten, ikke en bredere gjennomgang av adresser som tilfeldigvis tilhører samme leverandør.

Å lese et skanneresultat ærlig

En skanning er en billig måte å kontrollere at en vert finnes og at en port ikke åpenbart blokkeres av en mellomliggende enhet. Det er ikke et nåbarhetsbevis for en autentisert protokoll, og absolutt ikke en konfigurasjonstest.

Det sterkere beviset er et fullført håndtrykk fra klienten du faktisk bryr deg om, etterfulgt av en forespørsel som bruker tunnelen og får et svar. Den sekvensen øver nøklene, de tillatte adressene, begge brannmurene og returveien på én gang.

Der det ekte forsøket mislykkes, må feilen likevel diagnostiseres med klientens tellere og serverens opptak i stedet for med enda en probe. Protokollbeskrivelsen forklarer hvorfor en uautentisert pakke ikke får svar, og det er hele grunnen til at skanneresultatet er tvetydig.