WireGuard əl sıxması işləyir, xidmət isə yox

Əl sıxması tamamlanır, müştəri son ötürmə sayğacını göstərir, lakin eyni serverdəki xidmətə sorğu yenə də uğursuz olur. Bu birləşmə insanları çaşdırır, çünki tunelin işlədiyi açıq-aşkardır. Sübut olunmayan şey yerli çatdırılmadır: paket hosta çatıb, host hələ də onu düzgün soketdə qəbul edib cavab vermə icazəsi olan prosesə ötürməlidir. Bu üç yoxlama məntəqəsini sıra ilə keçin.

Uyğun gəlməyən ilk məntəqədə dayanın və digərləri üçün qayda əlavə etməyin.

Əl sıxması yalnız tuneli sübut edir

WireGuard əl sıxması həmyaşıdlar arasında açarlar yaradır və hər həmyaşıdın sadaladığı aralıqlar üçün trafikə icazə verir. O, serverdə hansı proseslərin dinlədiyi barədə heç nə demir və host firewallunun öz ünvanlarından birinə ünvanlanmış paketləri qəbul edib-etmədiyi barədə də heç nə demir.

Ən çox qaçırılan məhz son fərqdir: hostun özünə gedən trafik yerli girişdir, hostdan başqa yerə keçən trafik isə yönləndirmədir. Onlar fərqli firewall zəncirləri və fərqli parametrlərlə idarə olunur. Səhv zənciri yoxlamaq bir günorta itirir və günahsız görünən sayğaclar qaytarır.

Dinləyicini və marşrutu oxuyun

Müştəridə serverin tunel ünvanının tunelə yönləndiyini təsdiqləyin. Serverdə müştərinin istifadə etdiyi ünvanda soketin mövcud olduğunu və arxasındakı prosesin nəzərdə tutduğunuz proses olduğunu təsdiqləyin.

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

127.0.0.1 üzərində dinləyən heç vaxt 10.66.0.1 ünvanına göndərilən sorğuya cavab verməyəcək, firewall nəyə icazə versə də. Ümumi ünvanda dinləyən isə cavab verəcək, əgər qayda onu bloklamırsa. Beləliklə, soket siyahısı hər hansı qayda yoxlanmadan əvvəl halların yarısını həll edir. Port və ünvan birlikdə sorğunun çatıb-çatmayacağını müəyyən edir.

Müştərinin istifadə etdiyi ünvanı serverin tunel interfeysində həqiqətən sahib olduğu ünvanla müqayisə edin. Hər iki tərəfdə köhnə konfiqurasiya düzgün yönləndirilmiş, lakin belə ünvanı olmayan həmyaşıda gedən sorğu yaradır.

Yönləndirmə üçün deyil, yerli giriş üçün qaydalar tətbiq edin

Paket gəlirsə və soket varsa, qalan sərhəd giriş siyasətidir. Yönləndirməyə icazə verən qayda yerli çatdırılmaya icazə vermir və bir interfeysə məhdudlaşdırılmış qayda gözlədiyiniz tunel interfeysi adına uyğun gəlməyə bilər.

Hostu açmaq əvəzinə nəzərdə tutulan xidmətə icazə verilmiş tək portla sınaq keçirin. Sonra tətbiqin öz avtorizasiyasını yoxlayın: icazə siyahısı, hesab tələbi və ya müəyyən host adına bağlanma şəbəkənin uğurla çatdırdığı sorğunu rədd edə bilər.

Sertifikat yoxlamalarını yerində saxlayın. Gözlənilməz sertifikat kimliyi hansı hostun cavab verdiyi barədə məlumatdır, yan keçilməli maneə deyil. Üzərinə klikləmək səhv xidməti müəyyən edən yeganə ipucunu gizlədir.

Ad, ölçü və kimlik uğursuzluqlarını ayırın

Ünvanla işləyib adla uğursuz olan xidmət DNS problemidir və düzəliş firewall-da deyil, müştəriyə göndərilən həlledici konfiqurasiyasındadır. Kiçik sorğulara cavab verib böyük cavablarda dayanan xidmət paket ölçüsünə və MTU-ya işarə edir, bu isə tamamilə başqa araşdırmadır.

Səhv hostu adlandıran HTTPS xətası adətən sorğunun başqa xidmətə çatdığını bildirir, çox vaxt proksi və ya başqa dinləyici həmin porta sahib olduğu üçün. Sertifikatın subyektini oxuyun və ona çatmaq istədiyiniz hostla müqayisə edin. Bu müqayisə heç nəyə başa gəlmir və çox vaxt araşdırmanı bitirir.

Hansı yoxlama məntəqəsinin uğursuz olduğunu qeyd edin: soket, giriş qaydası və ya tətbiq siyasəti. Bu tək sətir şəbəkə nasazlığını avtorizasiya qərarından ayırır. O, həm də növbəti şəxsin heç vaxt problem olmayan portları açmasının qarşısını alır.