SNAT, DNAT və Masquerade: hər VPN NAT qaydası nə edir

VPN şlüzünün hər iki tərəfinə tutma qoyun və bir axın dörd fərqli ünvan göstərə bilər. Mənbə NAT paketin hardan gəldiyini iddia etdiyi yeri yenidən yazır; təyinat NAT onun hara getdiyini yenidən yazır. Masquerade üçüncü istiqamət deyil, ünvanını sabit dəyərdən deyil, çıxan interfeysdən götürən mənbə NAT qaydasıdır. Üçündən hansının həqiqətən lazım olduğunu adlandırın və «VPN işləmir» biletlərinin çoxu qayıdış yolu ilə bağlı suala çevrilir.

Hər qayda nəyi yenidən yazır

Mənbə NAT, adətən SNAT yazılır, axının mənbə ünvanını marşrutlaşdırıcıdan və ya şlüzdən çıxarkən dəyişir. Qəbul edən xidmət tərcümə olunmuş ünvana cavab verir və tərcümə edən qutu bu bağlantı üçün saxladığı vəziyyətdən istifadə edərək dəyişikliyi geri qaytarır. Linux-da bu vəziyyət conntrack-də yaşayır, buna görə conntrack -L orijinal və cavab dəstlərini yan-yana çap edir.

Təyinat NAT, DNAT, bunun əvəzinə təyinatı dəyişir. UDP 51820 üzərindəki açıq ünvana ünvanlanmış paket 10.8.0.2:51820-dəki daxili WireGuard serverinə yenidən yazıla bilər. Ev marşrutlaşdırıcısı və ya bulud yük balanslaşdırıcısı VPN dinləyicisini belə yayımlayır və bu, tunelin sonradan nə daşıya biləcəyi barədə heç nə demir.

Masquerade SNAT ailəsinə aiddir. Qayda heç bir ünvan adlandırmır; paket çıxarkən çıxan interfeysin hansı ünvana sahib olduğunu istifadə edir. Linux ona öz hədəfini verir və bu, ünvanını DHCP və ya PPPoE-dən alan WAN interfeysində adi seçimdir.

Xəritənin harada yaşadığı nasazlığı müəyyən edir

Dəsti hər sərhəddə qeyd edin: tuneldən əvvəl, onun içində və açıq interfeysdə. Tunelin içindəki tutma onun xaricindəkindən qanuni olaraq fərqlənir və tərcümənin harada baş verdiyini bilmədən ikisini müqayisə edən şəxs səhv hostun arxasınca düşəcək.

Qayıdış trafiki xəritəni saxlayan cihazdan keçməlidir. Cavab başqa marşrut, ikinci yuxarı xətt, siyasət marşrutu və ya şəxsi diapazonunuzu heç vaxt eşitməmiş provayder seçərsə, vəziyyətli əks tərcümə heç vaxt baş vermir və müştəri birtərəfli trafik görür. Daha çox mənbə NAT əlavə etmək itmiş qayıdış marşrutunu nadir hallarda düzəldir; bir axında simptomu gizlədə, hər yerdə ünvana əsaslanan siyasəti poza bilər.

Digər ümumi səhv tunelin marşrutlaşdırıla bilənlik yaradacağını gözləməkdir. Paketləri internetə çıxan şəxsi müştəriyə etibarlı çıxış tənzimi lazımdır: standart marşrut, yönləndirən şlüz və adətən açıq ünvana mənbə tərcüməsi. Şifrələmə tək başına şəxsi ünvanı əlçatan etmir.

Masquerade, yoxsa açıq SNAT

İkisini vəd etdiklərinə görə müqayisə edin. Masquerade çıxış ünvanını seçir, açıq SNAT onu bərkidir. Sabit açıq ünvanı olan şlüzdə bərkitmə jurnallara və tərəfdaş icazə siyahılarına bir proqnozlaşdırıla bilən dəyər verir. Dinamik WAN xəttində bərkidilmiş SNAT ünvanı icarə dəyişən anda səhv olur və Masquerade məhz bu hal üçün qurulub.

Əhatə də seçim qədər vacibdir. Şlüzdən çıxan hər paketə uyğun gələn, mənbə və ya təyinat məhdudiyyəti olmayan Masquerade qaydası toxunulmaz saxlamaq istədiyiniz trafiki də tərcümə edir, o cümlədən digər şəxsi şəbəkələrə trafiki. Qaydanı müştəri diapazonu, nəzərdə tutulan təyinat və interfeyslə məhdudlaşdırın.

Siyasət əsaslı IPsec burada ən çox ağrıdır. strongSwan-ın yönləndirmə bələdçisi IP yönləndirmənin aktivləşdirilməsini və müştərilər üçün mənbə NAT qaydasının əlavə edilməsini addım-addım göstərir və həmin sənədlər orijinal ünvanını saxlamalı olan trafikin istisna edilməsini də əhatə edir. Mənbəni təhlükəsizlik siyasəti ona uyğun gəlməzdən əvvəl tərcümə edin və tunel qalxa bilər, trafik isə yenə düşür, çünki paket artıq razılaşdırılmış selektora bənzəmir.

Uzaq tərəfin nə görməli olduğunu da qərarlaşdırın. Tərcümədən sonra xidmət şlüzü görür, ayrı-ayrı müştərini deyil. Bu, qayıdış marşrutlaşdırmasını sadələşdirir və eyni zamanda jurnalları yastılaşdırır, hər müştəri üçün icazə siyahılarını sıradan çıxarır. Müştəri ünvanlarının qorunması vacibdirsə, testin keçməsi üçün onları gizlətmək əvəzinə marşrutlaşdırılmış qayıdış yolu planlaşdırın.

Linux şlüzündə qaydaları oxumaq

10.8.0.0/24 üzərində müştəriləri və eth0 adlı WAN interfeysi olan uzaqdan giriş şlüzü yönləndirmənin aktivləşdirilməsini və axına icazə verən filtr siyasətini tələb edir, yalnız bundan sonra hər hansı NAT qaydası kömək edə bilər. iptables versiyası hər iki istiqaməti nat cədvəlində saxlayır:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

nftables forması eyni iki qarmaqdan adlı interfeys və açıq zəncirlə istifadə edir:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

Hər iki parça filtr zəncirinin yönləndirilən axını artıq qəbul etdiyini fərz edir. NAT icazə qaydası deyil və düzgün tərcümə olunmuş paket bir cədvəl sonra yenə düşə bilər. Canlı xəritəni conntrack -L ilə, yüklənənin nə olduğunu nft list ruleset və ya iptables-save -t nat ilə təsdiqləyin, sonra ünvanın həqiqətən dəyişdiyini görmək üçün hər iki interfeysdə tutma aparın.

Pis qayda kimi görünən nasazlıq rejimləri

Saç sancağı trafiki klassik haldır. Daxili serverə onun açıq ünvanı ilə çatan daxili müştəriyə giriş yolunda DNAT, geri çıxış yolunda isə mənbə tərcüməsi lazımdır, əks halda server birbaşa müştəriyə cavab verir və cavab rədd edilir. Düzəliş həmin daxildən-açığa hal üçün ikinci, daha dar qaydadır, hər şey üçün daha geniş Masquerade qaydası deyil.

İkiqat tərcümə səssiz olandır. Artıq operator səviyyəli NAT arxasındakı müştəri şlüzünüzə geri marşrutlaşdıra bilmədiyiniz ünvanla gəlir, ona görə yenidən tərcümə edirsiniz. İşləyir, amma jurnallar indi iki atlama şəxsi ünvanlaşdırma daşıyır və hər hansı araşdırma iki xəritənin ikisini də tələb edir. Siyasət əsaslı IPsec üçüncü burulğan əlavə edir: siyasət uyğunluğundan əvvəl tərcümə edin və heç bir trafik keçmədən qalxan SA alırsınız, bu isə NAT deyil, firewall xətası kimi oxunur.

Sonra keçən test və uğursuz olan yerləşdirmə gəlir. NAT əmrini əl ilə işlətmək mexanizmi sübut edir, konfiqurasiyanı yox. İşləmə vaxtında əlavə edilən qayda yenidən başlatmada və ya növbəti interfeys hadisəsində yox olur və nömrəni dəyişən interfeysə bağlanmış Masquerade qaydası uzaq tərəfin gördüyü ünvanı səssizcə dəyişə bilər. Qaydanı sahib firewall-un konfiqurasiyasına qoyun və yenidən qoşulmadan sonra yenidən sınaqdan keçirin.

Qaydanı saxlamaqdan əvvəl yoxlama siyahısı

Əvvəlcə istiqaməti adlandırın: mənbə, təyinat və ya hər ikisi. Sonra vəziyyəti kimin saxlamalı olduğunu müəyyənləşdirin — şlüz, yuxarı marşrutlaşdırıcı və ya IPsec həmsöhbəti — və qayıdış yolunun ondan keçdiyini təsdiqləyin. Qaydanı həqiqətən nəzərdə tutduğunuz müştəri diapazonu, təyinat və interfeyslə məhdudlaşdırın və uzaq tərəfin şlüzü, yoxsa orijinal müştəri ünvanını görməli olduğunu əvvəlcədən qərarlaşdırın.

Şlüzdən deyil, müştəridən sınaq keçirin. Şlüzün özündəki brauzer müştəri tərcümə qaydasını tamamilə yan keçə bilər, ona görə orada işləyən səhifə tunel barədə heç nə sübut etmir. Bir müştəri mənşəli sorğu göndərin, sayğacları və conntrack cədvəlini izləyin, iş yerinizdə mümkündürsə tunel yenidən qoşulduqdan və WAN ünvanı dəyişdikdən sonra təkrarlayın.