İki VPN ilə bağlanmış ofis arasında girişi necə məhdudlaşdırmaq olar

Saytlararası tunel bir suala cavab verir, iki ofisin paket mübadiləsi edib-edə bilmədiyini, və vacib olanı açıq qoyur: hansı filial cihazı hansı mərkəzi xidmətə çata bilər. Tunelə qarşılıqlı etimad kimi baxmaq, qonaq noutbukunun maliyyə serveri ilə eyni yolda bitməsinin səbəbidir. Həll daha yaxşı tunel deyil, deşifrədən sonra tətbiq olunan açıq icazə siyahısıdır. Bu təlimat həmin siyahını tərifdən sübut olunmuş rəddə aparır.

Bu ardıcıllıqla işləyin və aşağıdakı siyasət addımları keçməyincə tunel marşrutunu genişləndirməyin.

Şlüzə toxunmadan matrisi yazın

Faydalı sətir üç şeyi adlandırır: mənbə qrupu, təyinat hostu və ya xidmət şəbəkəsi, və tətbiqin həqiqətən istifadə etdiyi protokol və port. Filial və məlumat mərkəzi giriş deyil. Şəxsi DNS və autentifikasiya xidmətləri yalnız tətbiq onlarsız işləyə bilməyəndə öz sətirlərini qazanır.

Mənbələri subnet rahatlığına görə deyil, roluna görə qruplaşdırın: işçilər, qonaqlar, idarəetmə. Hər üçü bir düz LAN-ı paylaşanda şlüz onları şəbəkə qatında ayıra bilmir, ona görə əvvəlcə kimlik nəzarəti və ya seqmentasiya gəlməlidir. Sonra matrisi hər sətirdə sahib və baxış tarixi ilə yazılı şəkildə qoyun.

Qaydaları paketlərin deşifrə olunduğu yerdə tətbiq edin

IKE və ESP-yə icazə verən qaydalar yalnız xarici tuneli qurur. Daxili trafik tunel interfeysinə açıq şəkildə gəlir və icazə siyahısı məhz oraya aiddir: deşifrə olunmuş cihazda yönləndirmə zənciri, standart atma, hər matris sətri üçün bir qayda. Linux şlüzlərində bu, yönləndirmənin aktiv olması və filtr qaydalarının tunel cihazında, fiziki yuxarı keçiddə deyil, olması deməkdir; bunu strongSwan yönləndirmə təlimatı izah edir.

Trafik selektorları marşrut qərarıdır, avtorizasiya qərarı deyil. Hər iki subşəbəkəni əhatə edən geniş selektor marşrutlaşdırma üçün doğru ola bilər, halbuki firewall hələ də yalnız bir hosta TCP 443-ə icazə verir. Selektor tunel üçün razılaşdırılır və ona nəyin girə biləcəyini təsvir edir, hər hansı cihazın nəyi istifadə edə biləcəyini deyil. Selektor genişdir deyə heç vaxt firewall qaydasını genişləndirməyin.

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT və üst-üstə düşən subşəbəkələr qaydaları dəyişir

Filial şlüzü tuneldən əvvəl hər hostu tək bir ünvana çevirdikdə, mənbəyə əsaslanan hər sətir həmin bir ünvanda çökür. Ya tunel trafikini çevirməyi dayandırın, ya da qaydaların başqa bir şeyə, məsələn çevrilmədən əvvəl qeydə alınmış orijinal mənbə ünvanına dayanmalı olduğunu qəbul edin. Uzaq tərəf də eyni problemlə üzləşir, çünki təyinat hostu orijinalı deyil, NAT-dan sonrakı ünvanı görür.

Üst-üstə düşən diapazonlar digər tələdir. Hər ikisi 192.168.1.0/24 istifadə edən iki ofis bir tərəfi xəritələmədən tək siyasət cədvəlində təsvir edilə bilməz və xəritələmə toqquşmayan ünvanlamanın əvəzi deyil. Sonradan açmalı olacağınız qaydaları yazmazdan əvvəl planı düzəldin.

Rəddi sübut edin, yalnız uğuru deyil

Yalnız icazə verilən tətbiqi sınamaq çox az şey sübut edir, çünki yuxarıda haradasa icazəverən bir qayda eyni nəticəni verir.

Adi filial cihazından nəzərdə tutulan xidmətə çatın və bütün sessiyanın işlədiyini təsdiqləyin. Sonra bağlı qalmalı olan bir təyinatı sınayın, məsələn filialın heç bir işi olmayan serverdə inzibati portu, və onu atan sayğacı və ya jurnal qeydini oxuyun. Qayda dəstini işləyib-işləmədiyini yoxlamaq üçün söndürmək testi etibarsız edir və siz baxarkən şlüzü açıq qoyur.

Siyahını canlı saxlayın

Tətbiqlər yer dəyişir və tətbiqindən uzun yaşayan qayda heç kimin sahib olmadığı bir deşiyə çevrilir. Baxış tarixini sətrə bağlayın və xidmət ünvan dəyişdikdə selektor əhatəsini və firewall qaydasını eyni texniki xidmət addımında dəyişin.

Host səviyyəli məhdudiyyətlər tunelin arxasında da vacibdir: serverin öz firewallu filial diapazonunu yalnız yayımladığı xidmət üçün qəbul etməlidir. Razılaşan iki qat, tamamilə etibar edilən bir qatdan daha asan audit olunur.