UDP sken kaže filtrirano: je li vaš WireGuard peer zaista pao?

Skeneri za UDP port ispisuju otvoreno ili filtrirano, a zaključak obično slijedi u roku od nekoliko sekundi: tunel je pokvaren. Možda i jeste, ali sken to nije utvrdio. UDP ne nosi nikakav handshake veze, a WireGuard ne odgovara na ništa što ne može autentificirati, pa je tišina očekivani odgovor na većinu sondi.

Umjesto toga radite od klijenta prema van i tretirajte sken kao jednu slabu točku podataka među nekoliko njih.

Šta skener može, a šta ne može vidjeti

UDP skener pošalje teret i čeka. Ako se vrati ICMP port-unreachable, može prijaviti port kao zatvoren. Ako se ništa ne vrati, rezultat je po dizajnu dvosmislen: filtrirana putanja, odsutan host i pokrenuta usluga koja je ignorirala teret proizvode istu tišinu. Tri različita stanja, jedan izlazni niz.

WireGuard namjerno pogoršava tu dvosmislenost. Protokol prihvata paket samo kada ga autentificira, pa se sonda s pogrešnim ključevima odbacuje bez odgovora. Nema bannera, nema niza verzije i nema poruke o grešci za prepoznavanje.

TCP test na istom broju porta ne testira ništa povezano. On vježba drugi slušatelj koji možda ne postoji, a njegovo odbijanje ne govori ništa o UDP-u.

Otvorena filtrirana stanja zato tačnije opisuju nesigurnost skenera nego vaš server.

Prođite stvarnog klijenta od profila prema unutra

Počnite od klijentovog vlastitog pogleda. Ima li interfejs adresu, imenuje li konfiguracija pravi endpoint i pomjera li se brojač rukovanja kada se pokuša veza? Klijent koji nikada nije poslao paket i klijent čiji su paketi odbačeni izgledaju identično u statusnom prozoru. Samo ih brojači razlikuju, pa prvo čitajte brojače.

Zatim gledajte serversku stranu dok se odvija jedan ovlašteni pokušaj, umjesto da pokrećete odvojeni sken s treće lokacije:

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

Prva naredba prijavljuje posljednje rukovanje po peeru, što je direktan dokaz da je autentificirana razmjena završena. Druga pokazuje dolaze li paketi za slušatelj uopće, što odvaja problem putanje od problema konfiguracije u jednom koraku.

Ako snimak ne pokazuje ništa, paket nikada nije stigao do hosta i konfiguracija tunela nije sumnjivac. Ako pokazuje pakete koji dolaze s očekivane adrese dok rukovanje ostaje na nuli, ključevi ili dopuštene adrese peera su sljedeće mjesto za provjeru.

Povežite podatke na serveru kada njime upravljate

Potvrdite da slušatelj postoji i da provajderov firewall dopušta UDP port. Pravilo host firewall-a i sigurnosna grupa u oblaku dva su nezavisna vrata, a svaka može odbaciti paket koji je druga propustila. Provjerite oboje prema stvarnom portu u konfiguraciji, a ne prema portu kojeg se sjećate.

Adresa je jednako važna kao port. Server koji sluša na određenoj adresi neće odgovoriti na paket koji stigne na drugu, a host s više interfejsa može primiti sondu na interfejsu koji niste namjeravali.

Držite svaki test unutar sistema koje ste ovlašteni testirati. Korisna usporedba je između jednog stvarnog pokušaja klijenta i očekivane serverske putanje, a ne šireg pregleda adresa koje slučajno pripadaju istom provajderu.

Pošteno čitanje rezultata skena

Sken je jeftin način da provjerite postoji li host i da port nije očigledno blokiran posredničkim uređajem. To nije dokaz dostupnosti za autentificirani protokol i svakako nije test konfiguracije.

Jači dokaz je završeno rukovanje s klijentom do kojeg vam je zaista stalo, nakon čega slijedi zahtjev koji koristi tunel i dobije odgovor. Taj slijed u jednom potezu provjerava ključeve, dopuštene adrese, oba firewall-a i povratnu putanju.

Kada stvarni pokušaj ne uspije, kvar se ipak mora dijagnosticirati pomoću klijentovih brojača i serverskog snimka, a ne pomoću još jedne sonde. Opis protokola objašnjava zašto neautentificirani paket ne dobija odgovor, i to je cijeli razlog zašto je rezultat skena dvosmislen.