EC2-də strongSwan: VPC iş yükünü marşrutlaşdırsın

Tunel işləyir, şlüz instansı uzaq şəbəkəni ping edə bilir, lakin yanındakı tətbiq instansı heç bir yerə çata bilmir. Heç nə sınmayıb. Uğurlu olan test VPN hostunda başlamışdı və heç vaxt soruşmamışdı ki, həmin host eyni IPsec əlaqəsi ilə fərqli mənbə ünvanını daşıya bilərmi. Bu runbook həmin boşluğu dörd addımda bağlayır, hər nasazlığı görünən saxlayan sıra ilə.

Əvvəlcə dörd ünvanı yazın

Aşağıdakı hər addım bunlara istinad edir, ona görə marşrut cədvəlinə toxunmazdan əvvəl onları öz hesabınız üçün doldurun.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

Nümunə təsdiqlənmiş, işlək siyasət əsaslı IPsec bağlantısını və mənbəni qoruyan axını fərz edir. Bu, bir təyin edilmiş ünvanı borc alan NAT-lı uzaq giriş müştərisi deyil və bu fərq selektorların dəyişməli olub-olmadığını müəyyən edir.

Addım 1: iş yükü alt şəbəkəsinə marşrut verin

Faktiki olaraq iş yükü alt şəbəkəsinə bağlanmış marşrut cədvəlinə uzaq prefiks üçün şlüzün şəbəkə interfeysinə işarə edən yol lazımdır. İnstansiyanın içində quraşdırılmış qonaq marşrutu həmin AWS marşrut cədvəlində qeyd deyil və heç bir strongSwan konfiqurasiyası onu yaratmayacaq.

AWS-in appliance-marşrutlaşdırma təlimatı şəbəkə interfeysi hədəflərini və yönləndirən instansiyanın mənbə/təyinat yoxlaması tələbini təsvir edir. Bu yoxlama dəyişikliyini şlüz roluna məhdudlaşdırın və adi tətbiq instansiyalarına toxunmayın.

Bir təsdiqlənmiş şəbəkəyə yer açmaq üçün VPC-nin yerli marşrutunu və ya bütün mövcud qeydləri dəyişdirməyin. Heç kimin istifadə etmədiyi marşrut cədvəli üçün konsol səhifəsinin göstərdiyinə deyil, nəyin bağlı və aktiv olduğuna baxın. Oxşar görünən iki cədvəlin fərqli bağlantıları ola bilər. Əhəmiyyətli olan, iş yükü alt şəbəkəsinin qoşulduğu cədvəldir.

Addım 2: qonaqda yönləndirməni aktivləşdirin

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

Nüvə yönləndirməlidir və host firewall keçidə icazə verməlidir. Hər şeyi qəbul etmək əvəzinə iş yükü və uzaq prefikslər üçün nəzərdə tutulan forward qaydalarını əlavə edin və şlüz alt şəbəkəsinin öz trafiki üçün istifadə edilə bilən nəqliyyat marşrutu saxladığını təsdiqləyin.

Təhlükəsizlik qrupları bu addımın adətən ilişdiyi yerdir. Aralıq qurğu birbaşa instansiya ünsiyyətinin təhlükəsizlik qrupu istinad davranışını miras almır, ona görə idarə olunan Client VPN nümunəsindən köçürülmüş qayda heç vaxt uyğun gəlməyə bilər. Faktiki yolda təhlükəsizlik qrupunu və alt şəbəkə ACL-ni hər iki istiqamətdə yoxlayın.

Addım 3: selektorları real mənbələrə genişləndirin

AWS tərəfində yalnız 10.60.1.10/32 ünvanını əhatə edən siyasət, 10.60.2.20 ünvanını əhatə etmədən şlüzdən başlayan uğuru izah edir. Uzaq təyinat istiqamətindəki marşrut trafik selektorunu genişləndirmir və bu, həmin sürprizin ikinci yarısıdır.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

Razılaşdırılmış dizayn bütün VPC-ni qoruyursa, hər iki peer 10.60.0.0/16 və 10.90.0.0/24 qəbul etməlidir. Bir iş yükünü qoruyursa, həmin daha dar prefiksi qəsdən istifadə edin. Hər halda, quraşdırılmış CHILD-SA siyasətinə baxın, çünki sizin redaktə etdiyiniz konfiqurasiya ilə onu fərqli şəkildə daraldan peer eyni razılaşma deyil.

Uzaq sahə də qorunan VPC mənbələri üçün cavabları nəzərdə tutulan IPsec şlüzündən geri marşrutlaşdırmalıdır. Digər mənbə-NAT qaydaları olduqda qorunan trafik üçün dəstəklənən NAT istisnasını saxlayın; təsdiqlənməmiş iş yükünü icazəli host ünvanına çevirmək başqa identiklik müqaviləsidir, istədiyiniz girişə qısa yol deyil.

Addım 4: yoxlayın, lazım gələrsə geri qaytarın

İş yükünün özündən yeni icazəli tətbiq əməliyyatı ilə test edin, sonra xaric edilməli təyinatla təkrarlayın. Uzaq xidmətin gördüyü mənbə ünvanını və istifadə etdiyi qayıdış yolunu qeyd edin. Şlüz pingi və ya yaşıl IKE statusu bu test deyil.

Şlüz işləyərkən iş yükü hələ də uğursuz olursa, addımları sıra ilə geri addımlayın: selektor, sonra yönləndirmə və təhlükəsizlik qrupları, sonra bağlı marşrut cədvəli. Hər birinin fərqli simptomu var və təxmin etmək əslində səhv olanı atlayır.

Geri qaytarma eyni sıranı tərsinə çevirir. İş yükü alt şəbəkəsinin marşrutunu ən son silin, əvvəlki selektorları bərpa etdikdən sonra, beləliklə mənbələrini artıq qorumayan şlüzə işarə edən alt şəbəkə qoymayasınız. Bu müqavilələr qüvvədə olduqda öz-özünə hostinq şlüz hostundan çoxuna xidmət edə bilər və AWS tərəfindən idarə olunan Site-to-Site VPN, strongSwan-ın müştəri şlüzü tərəfində otura biləcəyi fərqli bir əməliyyat modelidir.