UDP skanı “filtrli” deyir: WireGuard peer-iniz həqiqətən işləmir?
Autentifikasiya olunmamış prob sağlam peer-dən cavab ala bilməz. Əsl müştərini sınayın, sonra serverdə dinləyicini və paket yolunu əlaqələndirin.
Skanerlar UDP portu üçün açıq və ya filtrli nəticə çap edir və qənaət adətən saniyələr içində gəlir: tunel sınıb. Ola bilər, amma skan bunu təsdiqləmədi. UDP heç bir bağlantı əl sıxması daşımır və WireGuard autentifikasiya edə bilmədiyi heç nəyə cavab vermir, ona görə də əksər problar üçün sükut gözlənilən cavabdır.
Bunun əvəzinə müştəridən bayıra doğru işləyin və skanı bir neçə zəif məlumat nöqtəsindən biri kimi qəbul edin.
Skaner nəyi görə bilir, nəyi görə bilmir
UDP skaneri yük göndərib gözləyir. ICMP port-əlçatmaz cavabı qayıdırsa, portu bağlı kimi bildirə bilər. Heç nə qayıtmırsa, nəticə dizayn etibarilə qeyri-müəyyəndir: filtrli yol, mövcud olmayan host və yükü nəzərə almayan işləyən xidmət eyni sükutu yaradır. Üç fərqli vəziyyət, bir çıxış sətri.
WireGuard bu qeyri-müəyyənliyi qəsdən daha da pisləşdirir. Protokol paketi yalnız autentifikasiya etdikdə qəbul edir, buna görə səhv açarlarla gələn prob cavabsız atılır. Barmaq izi götürmək üçün nə banner, nə versiya sətri, nə də xəta mesajı var.
Eyni port nömrəsi üzərində TCP testi əlaqəli heç nə sınamır. O, mövcud olmaya bilən başqa bir dinləyicini işə salır və onun imtinası UDP haqqında heç nə demir.
Buna görə açıq filtrli vəziyyətlər serverinizi deyil, skanerin qeyri-müəyyənliyini daha dəqiq təsvir edir.
Real müştərini profildən içəri doğru addımlayın
Müştərinin öz baxışından başlayın. İnterfeysdə ünvan varmı, konfiqurasiya düzgün endpoint-i göstərirmi və bağlantı cəhdi zamanı əl sıxma sayğacı hərəkət edirmi? Heç paket göndərməmiş müştəri ilə paketləri atılmış müştəri status pəncərəsində eyni görünür. Onları yalnız sayğaclar fərqləndirir, ona görə əvvəlcə sayğacları oxuyun.
Sonra ayrı bir skanı üçüncü yerdən işlətmək əvəzinə, bir icazəli cəhd baş verərkən server tərəfini izləyin:
wg show wg0 latest-handshakes
tcpdump -n -i eth0 udp port 51820 -c 10
Birinci əmr hər peer üzrə son əl sıxmanı göstərir, bu da autentifikasiyalı mübadilənin tamamlandığına dair birbaşa sübutdur. İkincisi dinləyici üçün paketlərin ümumiyyətlə gəlib-gəlmədiyini göstərir və bununla yol problemini konfiqurasiya problemindən bir addımda ayırır.
Tutma heç nə göstərmirsə, paket hosta heç vaxt çatmayıb və tunel konfiqurasiyası şübhəli deyil. Gözlənilən ünvandan gələn paketlər görünür, əl sıxma isə sıfırda qalırsa, növbəti baxılacaq yer açarlar və ya peer-in icazəli ünvanlarıdır.
İdarə etdiyiniz serverdə korrelyasiya aparın
Dinləyicinin mövcud olduğunu və provayderin firewall-unun UDP portuna icazə verdiyini təsdiqləyin. Host firewall qaydası və bulud təhlükəsizlik qrupu iki müstəqil qapıdır və hər biri digərinin buraxdığı paketi ata bilər. Hər ikisini yaddaşınızdakı porta deyil, konfiqurasiyadakı real porta görə yoxlayın.
Ünvan port qədər vacibdir. Müəyyən ünvanda dinləyən server başqa ünvana gələn paketa cavab verməyəcək və çoxinterfeysli host probu nəzərdə tutmadığınız interfeysdə qəbul edə bilər.
Hər testi test etməyə icazəli olduğunuz sistemlərin içində saxlayın. Faydalı müqayisə bir real müştəri cəhdi ilə gözlənilən server yolu arasındadır, eyni provayderə aid təsadüfi ünvanların daha geniş siyahısı deyil.
Skan nəticəsini dürüst oxumaq
Skan hostun mövcud olduğunu və portun aralıq cihaz tərəfindən açıq şəkildə bloklanmadığını yoxlamağın ucuz yoludur. Bu, autentifikasiyalı protokol üçün əlçatanlıq sübutu deyil və qətiyyən konfiqurasiya testi deyil.
Daha güclü sübut həqiqətən əhəmiyyət verdiyiniz müştəridən tamamlanmış əl sıxma, ardınca tuneldən istifadə edib cavab alan sorğudur. Bu ardıcıllıq açarları, icazəli ünvanları, hər iki firewall-u və qayıdış yolunu bir anda sınaqdan keçirir.
Real cəhd uğursuz olursa, nasazlıq yenə də başqa probla deyil, müştərinin sayğacları və serverin tutması ilə diaqnostika edilməlidir. Protokol təsviri autentifikasiya olunmamış paketin niyə cavab almadığını izah edir və skan nəticəsinin qeyri-müəyyən olmasının bütün səbəbi budur.