UFW bağlantı kəsicisi VPN-inizi bloklayır? Qarşı tərəfə icazə verin

Yoxlama siyahısına əməl etdiniz: gedən trafiki rədd et, tunelə icazə ver, ufw-ni aktivləşdir. Sonra müştəri əl sıxışmasında gözləyir və heç vaxt qoşulmur, ya da qoşulur və heç bir səhifə yüklənmir. Hər iki uğursuzluq eyni boşluqdan qaynaqlanır. Tunelin mövcud olmasına imkan verən qayda yoxdur, çünki tunel paketlərinizin çıxdığı interfeys deyil.

Niyə tun0 üzərində icazə əvvəlcə heç nəyə uyğun gəlmir

tun0 sessiya mövcud olduqdan sonra müştəri tərəfindən yaradılır. Həmin sessiyanı quran dataqramlar provayderə 1194 portuna ünvanlanmış adi UDP paketləridir və fiziki mənbə ünvanı ilə wlan0 və ya eth0 vasitəsilə çıxır. allow out on tun0 yalnız gedən interfeysi tun0 olan trafikə uyğun gəlir, buna görə əl sıxışması zamanı heç nəyə uyğun gəlmir.

Bunun üstünə default deny outgoing qoysanız, xarici paketlər interfeys heç görünməmişdən əvvəl atılır. Müştəri yenidən cəhd edir, vaxt aşımına uğrayır və TLS və ya əl sıxışması xətası bildirir, bu da insanları sertifikatlar və MTU arasında axtarışa göndərir, firewall isə bağlantını sakitcə yeyir. Trafikinizi saxlamaq üçün nəzərdə tutulmuş qayda həmin trafikin saxlanmasına mane olur.

Refleks düzəlişi sızmanı daimi edir. sudo ufw allow out on wlan0, və ya defoltu yenidən icazəyə çevirmək tuneli qaldırır və maşını bağlantı kəsicisi olmadan qoyur: növbəti dəfə tunel düşəndə hər şey fiziki adapter üzərindən davam edir. Mən dəqiq həmin iki düzəlişə bir günorta itirdim, ta ki hansı paketi filtrlədiyimi anlayana qədər.

İki paket dəstinin nəyə ehtiyacı var

Trafikiniz firewall-u iki dəfə, iki formada keçir. Daxili paket tunel ünvanından tun0 vasitəsilə çıxır. Xarici paket fiziki ünvandan qarşı tərəfə gedir və naqildə görünən yeganə şeydir. Hər forma üçün bir qayda:

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

Ünvanı və portu öz profilinizdəkilərlə əvəz edin. WireGuard qarşı tərəfləri adətən 51820/udp üzərindən cavab verir; TCP 443 üzərindən gedən OpenVPN profilləri bunun əvəzinə həmin portu tələb edir. Detallar fərqlənir, forma fərqlənmir: hər iki qayda dardır və birlikdə maşının tunel söndüyü zaman çata bildiyi yeganə təyinatları müəyyən edir.

Sıra ikinci mifdir. Xam iptables ilə zənciri yuxarıdan aşağıya oxuyur və hansı qaydanın qalib gəldiyini düşünürsünüz. ufw yazdığınız siyahının nazik sarğısı deyil; qaydalarınızı öz zəncirlərinə kompilyasiya edir və daxil etmə nöqtələrini seçir. ufw status onları ufw-nin sırası ilə çap edir, sizin sıranızla deyil. Bir qayda laqeyd görünəndə, ufw show added ilə iptables -S | grep ufw -dən kompilyasiya olunmuş dəsti müqayisə edin, hər hansı bir şeyi yenidən yazmazdan əvvəl.

İstisna bir ünvan enində qalmalıdır

Qarşı tərəf qaydası yalnız müştərinin yığdığı ünvanı adlandırdıqca düzgündür. Provayderlər son nöqtələri döndərir və host adını həll edən profil DNS dəyişikliyini yeni ünvana izləyəcək, qayda isə köhnə ünvanı göstərməyə davam edəcək. Aylarla işləyən tunel qalxmağı dayandıranda, hər hansı bir şeyi genişlətməzdən əvvəl qaydadakı ünvanı müştərinin axtardığı ünvanla müqayisə edin.

Bütün alt şəbəkəyə və ya 1194 portundakı hər təyinat yerinə genişlətmək siyasəti yenidən deşikli firewall-a çevirir. İstisna bağlantı kəsicisidir; geniş olandan sonra kəsiləcək heç nə qalmır. Onu tək ünvanda saxlayın və hansı profilə və provayderə aid olduğunu adlandıran şərh buraxın, çünki altı aydan sonra ünvan təsadüfi görünəcək.

Ad həlli ayrı sətirə layiqdir. Axtarış tunel mövcud olmadan əvvəl, fiziki interfeys üzərindən baş verir, buna görə ciddi rədd siyasəti müştərini öz serverini tapa bilməz vəziyyətdə qoya bilər. 53 portuna həlledicinizin ünvanına icazə verin və ya bir dəfə həll edib ünvanı profildə bərkidin. Hər interfeysdə DNS-ə icazə vermək qərardır, defolt deyil.

Siyasəti tunel lazım olmadan əvvəl qurun

ufw enable bütün siyasəti bir anda tətbiq edir və zəncirlərini yenidən yükləyir, işləyən firewall-da defolt siyasəti dəyişmək də onları yenidən yükləyir. ufw təlimatı bunun SSH kimi mövcud bağlantıları ata biləcəyi barədə xəbərdarlıq edir. Buna görə əmrlər bu sıra ilə gedir, SSH qaydası aktivləşdirmədən əvvəl və konsol sessiyası açıq olmaqla:

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

ufw reset qəsdən həmin blokdan kənarda saxlanılıb. O, hər qaydanı silir və firewall-u söndürür, uzaq hostda isə növbəti aktivləşdirmə sessiyanızı atan şeydir. Əgər həqiqətən sıfırlasanız, SSH qaydasını əlavə edin və davam etməzdən əvvəl konsol vasitəsilə ikinci giriş yolunu təsdiqləyin.

Ardıcıllıq kosmetik deyil. ufw işləyərkən əlavə edilən qaydalar heç nəyi təmizləmir, amma defolt siyasəti çevirdiyiniz an zəncirlər yenidən yüklənir və köhnə siyasətin icazə verdiyi sessiya da onlarla gedir. Defoltları, icazələri və aktivləşdirməni bir keçiddə edin, hələ də maşından asılı olmayan giriş yolunuz varkən.

Bloklanmış vəziyyəti yoxlayın və geri qaytarmanı saxlayın

Sınaqdan keçirilməmiş bağlantı kəsicisi təxmindir. Müştərini qəsdən ayırın və səhifə yükləməyə çalışın: uğursuz olmalıdır. Yenidən qoşulun və heç bir qaydaya toxunmadan bərpa olunmalıdır. sudo ufw status verbose defoltları və log vəziyyətini təsdiqləyir, ufw status numbered isə məqsədini aşdıqda hansı test qaydasının silinəcəyini göstərir.

Əks skripti irəli skriptin yanında saxlayın. Rədd edən və ölü tuneli olan maşın öz təmirini yükləyə bilməz, buna görə geri qaytarma diskdə olmalı və konsoldan oxuna bilməlidir:

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Onu tunel artıq söndüyü və qaydaların götürülməli olduğu vaxt işə salın, adi addım kimi deyil. Terminalı bağlamazdan əvvəl dörd şey olmalıdır: qarşı tərəf qaydası dəqiq bir ünvan adlandırır, DNS-in adlandırılmış istisnası var, aktivləşdirmə icazələrdən sonra gəlib və tuneli çəkmək adi trafiki öldürür, müştərini isə birdəfəlik öldürmür.