Serverin ictimai ünvanına SSH işləməyi dayandırarkən qalxan tunellər serverin bağlantını rədd etməsi kimi görünür. Windows-da daha ehtimallı səbəb lokaldır: tam tunel AllowedIPs dəyəri /0 olduqda, tunelin öz nəqlini və çox az başqa şeyi icazə verən məhdudlaşdırıcı firewall qaydaları işə düşür. Həmin ünvana çatan şifrələnmiş paketlər eyni ünvana ayrı TCP bağlantısının çıxa bilib-bilmədiyi barədə heç nə demir.

Peer siyahısına toxunmazdan əvvəl endpoint-in ictimai ünvanını onun daxili tunel ünvanından ayırın. Bunu AllowedIPs-i redaktə edərək düzəltməyə çalışan demək olar hər cəhd siyasəti zəiflədir, marşrutu düzgün etmir.

Marşrut icazəsi ilə firewall icazəsi fərqlidir

Marşrut paketin hara göndəriləcəyini, firewall qaydası isə onun ümumiyyətlə göndərilə biləcəyini həll edir. Buna görə endpoint-in ictimai IP-si üçün marşrut əlavə etmək filtrin yenə də bloklaya biləcəyi bir yol yaradır və bu simptomun yaratdığı çaşqınlıq məhz budur. Windows-da filtr əlavə deyil, tətbiqin bir hissəsidir, ona görə heç bir marşrut qeydi onu dəyişmir. Bu iki qərar başqa yerlərdə də ayrıdır, baxmayaraq ki, defolt dəyərlər fərqlənir.

Buna görə endpoint-ə traceroute uğur qazana bilər, SSH cəhdi isə uğursuz olur. Birincini istisnaya sahib xidmət daşıyır, ikincini yox.

Windows-da /0 nə edir

İcazə verilən ünvanları bütün IPv4 fəzasını əhatə edən tək peer ilə WireGuard for Windows, əks halda tuneldən kənara çıxacaq trafiki bloklayan məhdudlaşdırıcı firewall vəziyyəti tətbiq edir. Tunel xidmətinin öz nəqlinə icazə verilir, çünki VPN başqa cür işləyə bilməzdi. Eyni ictimai ünvana gedən başqa tətbiq belə icazə almır, çünki istisna ünvana deyil, nəqlə aiddir. Windows şəbəkə qeydləri bu davranışı və redaktorda olan əlaqəli idarəetmə elementini təsvir edir.

Bu qaydalar kill switch ifadəsinin arxasındakı mexanizmdir. Onlar belə adlanan qeyd xanası ilə deyil, konfiqurasiyanın forması ilə aktivləşir.

İstisnalar müdafiə modelini dəyişir

/0-ı iki yarımdefolt prefikslə əvəz etmək məhdudlaşdırıcı semantika olmadan geniş marşrutlaşdırmanı saxlamağın sənədləşdirilmiş yoludur və bu, qısa yazılış deyil, fərqli müdafiə modelidir. Endpoint ünvanını icazə verilən prefikslərdən çıxmaq digər geniş yayılmış işarədir; bu, siyahını uzadır və hansı qaydaların aktivləşdiyini də dəyişir. Heç biri lokal təsirə malik lokal düzəliş deyil. Hər biri maşındakı hər axın üçün sərhədi dəyişir, yalnız düzəltdiyiniz bağlantı üçün deyil.

Birbaşa ictimai SSH həqiqətən tələb olunduqda, profil sahibi həm xarici marşrutu, həm də onun firewall icazəsini layihələndirməli və tunel düşəndə əlaqəsiz trafikin nə olacağını qərar verməlidir. IPv4 və IPv6-nı ayrıca nəzərdən keçirmək də buna aiddir, çünki qaydalar hər ailə üzrə ifadə olunur. Bir idarəetmə sessiyasını xilas etmək üçün əlavə edilən geniş yan keçid adətən sessiyadan daha çoxunu ifşa edir.

Seçdiyiniz idarəetmə yolunu sınayın

Əvvəlcə idarəetmənin tunelin içindən, yoxsa çölündən getməli olduğunu qərarlaşdırın, sonra hər ikisini birdən deyil, həmin seçimi sınayın. Aşağıdakı əmrlər müştərinin ünvanlarını, peer vəziyyətini və hər hədəfə bağlantını yoxlayır. Onları tunel qalxarkən Windows müştərisindən işə salın.

ipconfig | findstr /i "WireGuard IPv4"
wg show
ssh -v [email protected]
Test-NetConnection 203.0.113.9 -Port 22

Daxili ünvana uğurlu SSH tunelin idarəetmə trafikini daşıdığını və serverin öz firewallunun onu peer aralığından qəbul etdiyini sübut edir. Hər iki hədəfdə uğursuzluq Windows marşrutu deyil, server tərəfi və ya açar problemidir. Daxili ünvan işləyirsə, xarici işləmirsə, lokal firewall vəziyyəti məhz dizayn edildiyi işi görür. Profili redaktə etməzdən əvvəl üç nəticəni bu sıra ilə oxuyun.

İdarəetmə yolunu, istifadə olunan ünvanı və tunel düşəndə davranışı qeyd edin. Beş dəqiqə qazanmaq üçün yan keçidi genişləndirməyin qarşısını alan məhz bu qeyddir.

Əlaqəli məqalələr