VPN NAT-ı UFW-nin before.rules faylında hara yazılır və onu necə test etmək olar

Shell-ə yazanda işləyən NAT qaydası before.rules faylına yapışdırıldıqda uğursuz olur, çünki bu fayl skript deyil. O, cədvəl bölmələri, zəncir elanları və hər cədvəl üçün COMMIT markeri olan bərpa formatlı sənəddir. Yanlış yerdə olan sətir ya bütün bərpanı dayandırır, ya da orada olduğuna inandığınız qaydaları səssizcə silir. Aşağıdakı runbook fraqmenti çərçivənin gözlədiyi yerə qoyur və nəticəni növbəti yenidən yükləmədən əvvəl sübut edir.

Shell əmri bərpa faylı deyil

iptables -t nat ilə başlayan sətir iptables binarına göstərişdir, UFW-nin oxuduğu fayl isə tam qaydalar toplusunun təsviridir. Fərq kosmetik deyil: bərpa formatı hansı cədvəldə olduğunu, hansı zəncirlərin mövcud olduğunu və cədvəlin harada bitdiyini bilməlidir. Həmin sənədə yapışdırılan əmr ya sintaksis xətasıdır, ya da daha pisi, səhv cədvələ bağlanmış qaydadır. Çərçivə bu faylları məhz ardıcıl deyil, bəyanedici olduqları üçün bərpa alətləri ilə yükləyir.

Sənəd həm də bütöv yüklənir, ona görə bir səhv bölmə faylın qalan hissəsinin tətbiqini dayandıra bilər. Beləliklə, NAT fraqmentində kiçik bir səhv filtr qaydalarını da özü ilə aşağı çəkir və firewall dəyişikliyi beləcə kəsintiyə çevrilir.

Fraqmenti mövcud cədvəl bölməsinin içərisinə qoyun

NAT fraqmentinin bir forması var və forma içindəki qayda mətnindən daha önəmlidir. Cədvəl başlığı bölməni açır, zəncir elanları sayğacları qurur, qaydalar onların ardınca gəlir və COMMIT bölməni bağlayır.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

Yuxarıdakı hovuz və interfeys öz dəyərləriniz üçün yer tutuculardır; kopyalamağa dəyər hissə strukturdur. Əgər faylda artıq *nat bölməsi varsa, ikinci bir bölmə açmaq əvəzinə qaydayı həmin bölmənin içərisinə əlavə edin, çünki format hər cədvəl üçün bir COMMIT gözləyir və eyni cədvəl üçün iki bölmə baş verəcək bir təmir işidir. Paylama zənciri təyinatlarını toxunulmaz saxlayın, o cümlədən satıcının öz inteqrasiyası üçün əlavə etdiyi hər hansı təyinatı. UFW çərçivə təlimatı before, user və after fayllarını və uyğun COMMIT tələbini sənədləşdirir.

Əgər fayl boş çıxarsa, onu hansısa dərslikdən doldurmayın. Onun hansı paketə aid olduğunu və canlı siyasətin əslində nə olduğunu təsdiqləyin, çünki boş daimi fayl nüvənin heç bir qayda saxlamadığını sübut etmir, yüklənmiş qaydalar toplusu isə növbəti yenidən yükləmənin oxuyacaq tam faylı olduğunu sübut etmir. Əvvəlcə dəstəklənən baza xəttini bərpa edin, sonra sayt dəyişikliklərini onun üzərinə yenidən tətbiq edin.

Namizədi commit etmədən test edin

Bərpa aləti qaydalar toplusunu tətbiq etmədən təhlil edib qura bilər və bu, mövcud ən ucuz testdir. Onu canlı fayl üzərində deyil, qorunan nüsxə üzərində işlədin və yalnız çıxış statusunu deyil, xəta mətnini oxuyun. Təhlil uğursuzluğu sətri və adətən cədvəli adlandırır ki, bu da uğursuz yenidən yükləmənin sizə deyəcəyindən çoxdur.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

Bu yoxlamadan keçmək sənədin təhlil olunduğunu sübut edir, başqa heç nəyi yox. O, namizədin UFW-nin asılı olduğu hər zənciri hələ də saxladığını, yalnız nəzərdə tutduğunuz mənbələrə icazə verdiyini və ya uzaqdan idarəetmənin əlçatan qaldığını sübut etmir. Bunlar ayrı-ayrı yoxlamalardır və sonuncusu başlamazdan əvvəl açılmış ikinci sessiyaya layiqdir.

Quraşdırılmış backend və ünvan ailəsinə uyğun aləti seçin. nft backendini uyğunluq qatı vasitəsilə işlədən host müvafiq əmri tələb edir və IPv6 qaydaları tamamilə başqa faylda yaşayır.

Yönləndirməni, NAT-ı və giriş siyasətini ayrı saxlayın

Mənbə tərcüməsi ünvanlama problemini həll edir və heç nə vermir. Yönləndirmə sysctl və filtr cədvəli ilə idarə olunan ayrıca icazədir və insanların tunel marşrutlaşdırdığı, lakin trafik keçirmədiyi zaman unutduğu şey məhz budur. Giriş siyasəti hansı mənbələrin hansı xidmətlərə çata biləcəyinə dair üçüncü qərardır və heç bir NAT qaydası onu ifadə etmir. Üçünü ayrı saxlamaq uğursuzluğu tək qeyri-müəyyən simptom əvəzinə diaqnoz edilə bilən edir.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Bu üç çıxışı bir-bir deyil, birlikdə oxuyun. Yönləndirmə deaktiv olan masquerade qaydası qoşulan, lakin heç bir yerə çatmayan müştəri yaradır ki, bu da müştəri tərəfindən tam olaraq marşrutlaşdırma nasazlığı kimi görünür və insanları səhv fayla yönəldir. Filtr cədvəli həm də həddindən artıq geniş accept-in gizləndiyi yerdir, ona görə orada olarkən onun standart siyasətini yoxlayın.

Yenidən yükləməni, imtinanı və VPN itkisini yoxlayın

Üç müşahidə tam qəbul testi yaradır: yenidən yükləmə uğurludur, icazə verilmiş müştəri əməliyyatı işləyir və rədd edilməli olan sorğu həqiqətən rədd edilir. Üçüncüsü atlanan həmin müşahidədir və siyasətin ümumiyyətlə nəyəsə yaradığının yeganə sübutudur.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Sonra nəzərdə tutduğunuz nasazlığı test edin. Tuneli endirin və hostun nə etdiyinə baxın, çünki yalnız VPN işləyərkən işləyən siyasət açıqlanmamış asılılığı olan siyasətdir. Sonra bir daha yenidən yükləyin ki, işlək nəticəni hər hansı qalıq işlək vəziyyət deyil, faylın verdiyini sübut edəsiniz.

IPv4 NAT-ı IPv6 haqqında heç nə demir, ona görə hər iki ailə üçün nəzərdə tutulan əhatəni qaydayla eyni qeyddə göstərin. Məqsəd ardıcıl idarə olunan siyasətdir və təsadüfən təhlil olunmuş fraqment bunun sübutu deyil.