OpenBSD VPN şlüzündə tun0 vasitəsilə LAN üçün NAT

Eyni OpenBSD şlüzünü alan iki mühəndis çox vaxt uzaq şəbəkəyə çatmaq üçün sizə iki fərqli qayda dəsti verəcək və hər ikisi müdafiə oluna bilər. Mənbə translyasiyası ilə geri marşrut arasındakı seçim heç də sintaksis məsələsi deyil. Məsələ uzaq tərəfin 192.168.88.0/24 haqqında artıq nə bildiyindən və jurnallarınızda nəyi saxlamaq istədiyinizdən asılıdır. Bunu səhv etsəniz, nat-to sətri tamamilə düzgün görünəcək, halbuki cavablar uzaq defolt şlüzündə yox olacaq.

Marşrutlaşdırma və yenidən yazma fərqli suallara cavab verir

Marşrut cədvəli 172.20.0.0/16-nın tun0 üzərindən əlçatan olduğuna qərar verir və bu qərar hər hansı pf translyasiyasına baxılmadan əvvəl baş verir. Sonra mənbə translyasiyası paket başlığını dəyişir ki, uzaq tərəf LAN hostu əvəzinə şlüzün tunel ünvanını görsün. Heç bir mexanizm digərini əvəz etmir: nat qaydası marşrutu yoxdan yarada bilməz, marşrut isə sizin şəxsi alt şəbəkəniz barədə heç vaxt eşitməmiş uzaq marşrutlaşdırıcını inandıra bilməz. Uzaq tərəfin geri yolu olmadıqda, cavablar atılır və ya onun defolt şlüzünə yönləndirilir və bunu heç bir qayda tənzimləməsi düzəltmir.

Sadə dildə desək, yönləndirmə trafikin hara getdiyini, translyasiya isə onun kimdən gəldiyi göründüyünü cavablandırır. Qayda dəstini dizayn edərkən onları ayrı zehni qutularda saxlayın.

Buna qərar verən üç şərt

Üç sualı ardıcıllıqla verin və dizayn adətən özünü seçir. Uzaq şəbəkənin 192.168.88.0/24 üçün tunel ünvanına işarə edən statik marşrutu varmı, yoxsa onun administratoru həmin yoldakı marşrutlaşdırıcılara nəzarət edir? Əgər bəli, LAN ünvanlarının dəyişmədən getməsinə icazə verin və translyasiyanı tamamilə atlayın. Uzaq tərəfdə hər müştəri üzrə görünürlük lazımdırmı, istər giriş siyasəti, istərsə audit izi üçün? Əgər bəli, mənbənin saxlanması marşrut işinə dəyər. Tunel ünvanı uzaq marşruta yazılacaq qədər sabitdirmi, yoxsa yenidən qoşulmalar arasında dəyişir?

Əgər hər hansı cavab xeyr və ya naməlumdursa, nat-to praqmatik seçimdir və o, həm də geri qaytarıla bilən seçimdir. Uzaq tərəf düzgün marşrut əlavə etdikdən sonra translyasiya qaydası bir sətirdə çıxarılır. Heç vaxt quraşdırılmamış geri marşrut hər dəfə kimsə tunelin niyə yalnız bir istiqamətdə işlədiyini soruşanda sizə bir dəstək müzakirəsi baha başa gəlir.

Fraqmenti pf-nin həqiqətən qiymətləndirəcəyi yerə qoyun

Aşağıdakı fraqment LAN-ın 192.168.88.0/24, uzaq şəbəkənin 172.20.0.0/16 və tunel interfeysinin tun0 olduğunu fərz edir. İçində heç nə növbəti hopu seçmir. O, yalnız artıq tuneldən çıxan paketlərdə mənbəni yenidən yazır.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

Birinci sətirdəki iki detal ağırlığın çoxunu daşıyır. tun0 ətrafındakı mötərizələr pf-ə hər dəfə vəziyyət qeydi qurarkən interfeys ünvanını oxumağı deyir və bu, tunel yenidən qoşulmadan sonra nömrələndikdə vacibdir. match sözü qaydanın yenidən yazıb sonra aşağı düşdüyünü bildirir, ona görə axını ayrıca pass qaydası hələ də qəbul etməlidir. match sətrində göstərilən interfeys həm də marşrut cədvəlinin seçdiyi interfeys olmalıdır, əks halda pf qaydanı paketin həqiqətən getdiyi yoldan fərqli çıxış yolunda qiymətləndirir.

Nüvə tərəfini unutmayın. IPv4 yönləndirməsi aktiv olmalıdır və tunel və LAN üçün vəziyyətli pass qaydaları bunun hər hansı mənası olmadan əvvəl mövcud olmalıdır. OpenBSD FAQ-nin PF NAT bölməsi burada açar sözlərin sırası üçün düzgün istinaddır.

Trafikə etibar etməzdən əvvəl qayda dəstini yoxlayın

Əvvəlcə pfctl -nf /etc/pf.conf ilə sintaksisi yoxlayın; bu, faylı yükləmədən təhlil edir. Sonra siyasəti yükləyin və nüvənin həqiqətən nə saxladığını oxuyun, çünki təmiz təhlil olunan qayda yenə də kölgələnə və ya səhv interfeysə bağlana bilər. pfctl -sn translyasiya qaydalarını yüklənmiş formasında çap edir, pfctl -sr isə filtr qaydalarını qiymətləndirmə sırası ilə çap edir.

Sonra kabeli izləyin. Şlüzdə tcpdump -ni tun0 'host 172.20.0.10' tuneldən çıxan mənbə ünvanının tunel ünvanı, yoxsa LAN hostu olduğunu göstərir. Sürətli netstat -rn -f inet təyinatın hansı interfeysə həll olunduğunu təsdiqləyir. Trafik axmağa başlayanda pfctl -ss vəziyyət qeydlərini sadalayır; əgər axın heç bir vəziyyət yaratmadısa, paket heç vaxt onu yaradan qaydaya uyğun gəlməyib.

Tunel tərəfi düzgün görünürsə və cavablar hələ də gəlmirsə, pf-i redaktə etməyi dayandırın. Qalan nasazlıq uzaq marşrutlaşdırıcıdadır, orada cavab o tərəfin çata bilmədiyi şəxsi ünvana göndərilir.

Translyasiya qənaət etdiyindən baha başa gələndə

Translyasiya müştəriləri gizlədir və bəzən bu, məhz səhv mübadilədir. Üst-üstə düşən alt şəbəkələr bir haldır: uzaq tərəf də daxildə 192.168.88.0/24 istifadə edirsə, LAN hostlarını şlüz kimi təqdim etmək toqquşmanı yaxşılaşdırmaq əvəzinə pisləşdirir. Trafiki ünvan cütünə görə seçən IPsec siyasətləri başqa haldır, çünki təhlükəsizlik siyasəti verilənlər bazası translyasiyadan əvvəl uyğunlaşdırılır və yenidən yazılmış paketinizi heç vaxt görmür. Hər istifadəçi üzrə hesablaşan, məhdudlaşdıran və ya audit edən istənilən yerləşdirmə, mənbə bir ünvana yıxıldığı anda ehtiyac duyduğu kimliyi də itirir.

Portativ pf törəmələri ayrı bir tələdir. Öz qayda fayllarını yaradan məhsullar NAT-ın onların interfeysi vasitəsilə konfiqurasiya edilməsini gözləyir və əl ilə redaktə edilmiş fraqmentlər növbəti yenidən yükləmədə üzərinə yazılır. match açar sözü mövcud olmadan əvvəl yazılmış bələdçilərdən kopyalanmış qayda dəstləri cari nüvədə yüklənməyəcək, ona görə sintaksisi port edin və təxmin etmək əvəzinə xətanı oxuyun.

Real şəbəkələrlə təmasda yaşayan qərar qaydası qısadır: bacardıqda geri marşrut qurun, bacarmadıqda translyasiya edin və üç şərtdən hansının sizi buna vadar etdiyini yazın. Həmin qeyd növbəti adama bir günortadan qənaət edir.