Scanarea UDP spune filtrat: partenerul tău WireGuard este într-adevăr căzut?

Scanerele afișează deschis sau filtrat pentru un port UDP, iar concluzia vine de obicei în câteva secunde: tunelul este stricat. S-ar putea să fie, dar scanarea nu a dovedit asta. UDP nu transportă niciun handshake de conexiune, iar WireGuard nu răspunde la nimic ce nu poate autentifica, așa că tăcerea este răspunsul așteptat la majoritatea sondelor.

Lucrează în schimb de la client spre exterior și tratează scanarea ca un singur punct de date slab printre mai multe.

Ce poate vedea scannerul și ce nu

Un scanner UDP trimite o încărcătură și așteaptă. Dacă revine un ICMP port-unreachable, poate raporta portul ca închis. Dacă nu revine nimic, rezultatul este ambiguu prin proiectare: o cale filtrată, un host absent și un serviciu care rulează dar a ignorat încărcătura produc toate aceeași tăcere. Trei stări diferite, un singur șir de ieșire.

WireGuard agravează intenționat această ambiguitate. Protocolul acceptă un pachet doar când se autentifică, așa că o sondă cu cheile greșite este aruncată fără răspuns. Nu există banner, nici șir de versiune și nici mesaj de eroare de amprentat.

Un test TCP pe același număr de port nu testează nimic legat. El exersează un alt listener care poate să nu existe, iar refuzul lui nu spune nimic despre UDP.

Stările deschise filtrate descriu, așadar, incertitudinea scannerului mai precis decât descriu serverul tău.

Parcurge clientul real din profil spre interior

Începe cu viziunea clientului însuși. Interfața are o adresă, configurația numește punctul final corect și contorul de handshake se mișcă atunci când se încearcă o conexiune? Un client care nu a trimis niciodată un pachet și un client ale cărui pachete au fost aruncate arată identic într-o fereastră de stare. Doar contoarele le disting, așa că citește mai întâi contoarele.

Apoi urmărește partea serverului în timp ce are loc o singură încercare autorizată, în loc să rulezi o scanare separată dintr-o a treia locație:

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

Prima comandă raportează ultimul handshake per partener, ceea ce este dovadă directă că un schimb autentificat s-a încheiat. A doua arată dacă pachetele pentru listener ajung deloc, ceea ce separă o problemă de cale de o problemă de configurare într-un singur pas.

Dacă captura nu arată nimic, pachetul nu a ajuns niciodată la host, iar configurația tunelului nu este suspectul. Dacă arată pachete care sosesc de la adresa așteptată în timp ce handshake-ul rămâne la zero, cheile sau adresele permise ale partenerului sunt următorul loc de verificat.

Corelează pe server atunci când îl administrezi

Confirmă că listener-ul există și că firewall-ul furnizorului permite portul UDP. O regulă de firewall pe host și un grup de securitate din cloud sunt două porți independente, iar oricare dintre ele poate arunca un pachet pe care cealaltă l-a permis. Verifică ambele față de portul real din configurație, nu față de portul pe care ți-l amintești.

Adresa contează la fel de mult ca portul. Un server care ascultă pe o adresă anume nu va răspunde la un pachet care sosește pe alta, iar un host cu mai multe interfețe poate primi sonda pe interfața la care nu te-ai gândit.

Ține fiecare test în sisteme pe care ești autorizat să le testezi. Comparația utilă este între o încercare reală a clientului și calea așteptată a serverului, nu o baleiere mai largă a unor adrese care aparțin întâmplător aceluiași furnizor.

Citirea onestă a unui rezultat de scanare

O scanare este o modalitate ieftină de a verifica dacă un host există și dacă un port nu este evident blocat de un dispozitiv intermediar. Nu este o dovadă de accesibilitate pentru un protocol autentificat și cu siguranță nu este un test de configurare.

Dovada mai puternică este un handshake finalizat de la clientul care contează cu adevărat pentru tine, urmat de o cerere care folosește tunelul și primește un răspuns. Acea secvență exersează cheile, adresele permise, ambele firewall-uri și calea de întoarcere dintr-o dată.

Acolo unde încercarea reală eșuează, defectul trebuie totuși diagnosticat cu contoarele clientului și captura serverului, nu cu o altă sondă. Descrierea protocolului explică de ce un pachet neautentificat nu primește răspuns, și exact aceasta este rațiunea pentru care rezultatul scanării este ambiguu.