strongSwan-dan AWS Site-to-Site-a: Child SA niyə heç nə seçmir
IKE tuneli işlək ola bilər, halbuki child assosiasiyası subnetlərinizi istisna edir. Əvvəlcə AWS-in lokal və uzaq CIDR-lərini leftsubnet və rightsubnet ilə müqayisə edin.
Konsol statusu tunelin işlək olduğunu göstərir, strongSwan qurulmuş IKE assosiasiyası bildirir, lakin paketlər hələ də gəlib çatmır. Növbəti müqayisə ediləcək şey əvvəlcədən paylaşılan açar deyil, hər tərəfin tunelin qoruduğuna inandığı prefikslər cütüdür. Aşağıdakı yoxlamaları ardıcıllıqla keçin, çünki ilk iki yoxlama tunelin trafikinizi ümumiyyətlə daşıya biləcəyini həll edir.
AWS-in adlarını strongSwan terminlərinə çevirin
AWS bağlantını müştəri tərəfdən təsvir edir: müştəri şlüzünün ünvanı və lokal CIDR sizə aiddir, uzaq CIDR isə VPC-yə aiddir. strongSwan iki ucu left və right adlandırır; sizin prefiksiniz leftsubnet-də, VPC prefiksi isə rightsubnet-də olur. Cütlərdən birinin tərsinə çevrilməsi yanlış trafiki razılaşdıran və seçən tunel yaradır.
AWS-in bağlantı üçün yaratdığı konfiqurasiyanı endirin və onu məhz həmin bağlantı üçün istinad kimi qəbul edin, tunel ünvanları və prefikslər daxil olmaqla. Yaradılma zamanı hər iki CIDR sahəsini boş buraxmaq xidmətin hər tərəfdə 0.0.0.0/0 defoltundan istifadə etməsinə səbəb olur. Dar prefikslə konfiqurasiya edilmiş marşrutlaşdırıcı onu heç vaxt uyğunlaşdırmayacaq, ona görə ya sahələri doldurun, ya da seçicini qəsdən genişləndirin.
Buradakı uyğunsuzluq marşrutlaşdırma nasazlığı kimi görünür, amma deyil.
AWS-in həqiqətən gördüyü ünvanı sabitləyin
NAT arxasındakı marşrutlaşdırıcı IKE-ni qarşı tərəfin heç vaxt öyrənmədiyi interfeysdən göndərə bilər. AWS-də qeyd olunan şlüz ünvanı AWS-in şəbəkədə gördüyü ünvan olmalıdır və marşrutlaşdırıcı defolt marşrutuna uyğun getmək əvəzinə həmin lokal ünvana sabitlənməlidir.
conn %default
local_addrs = 203.0.113.10
strongSwan-da local_addrs IKE üçün mənbə ünvanını seçir, köhnə OpenSwan konfiqurasiyaları isə eyni fikri left kimi yazır. Onu ictimai ünvanı daşıyan interfeysə yönəldin, sonra NAT cihazının özündə UDP 500 və 4500-ün həmin hosta çatdığını yoxlayın, çünki əvvəlki marşrutlaşdırıcıdan qalmış qayda onları səssizcə atır. Düzgün seçici cütü yanlış mənbə ünvanı ilə yenə də uğursuz olur və jurnal günahı təklifin üzərinə qoyacaq. Bu yanlış istiqamətləndirmə mənbə ünvanının öz yoxlamasına layiq olmasının səbəbidir.
Yönləndirmə qaydasını fərz etmək əvəzinə təsdiqləyin, çünki əvvəlki marşrutlaşdırıcı üçün doğru olan qayda tez-tez qalıq kimi qalır.
1-ci və 2-ci mərhələni ayrı-ayrılıqda ele alın
AWS IKE və ESP seçimlərini ayrı siyahılar kimi təqdim edir. Hər iki tərəfin qəbul etdiyi IKE dəsti ESP təklifi barədə heç nə demir, çünki iki siyahı müstəqildir. Hər ikisini yaradılmış konfiqurasiyadan oxuyun və bir-bir müqayisə edin.
conn aws
ike = aes256-sha1-modp1024
esp = aes256gcm16
Sintaksis implementasiyalar arasında keçmir. OpenSwan-da işləyən cüt, məsələn phase2alg=aes_gcm ilə ike=aes256-sha1;modp1024, strongSwan-ın esp= və ike= formasına çevrilməlidir və alqoritm adları fərqlidir. GCM şifrələdiyi zaman autentifikasiya etdiyi üçün ayrıca bütövlük transformasiyasına ehtiyac duymur, SHA ilə cütləşdirilmiş CBC dəstindən fərqli olaraq. Bir daemondan digərinə tərcümə edilmədən yapışdırılmış 2-ci mərhələ sətri seçici uyğunsuzluğu kimi oxunan rədd yaradır.
Tunel göstəricisini deyil, child assosiasiyasını yoxlayın
Bağlantı yüklənir, amma child assosiasiyası qalxmırsa, ya təklif, ya da seçicilər rədd edilib. Child qalxır və seçiciləri prefikslərinizi istisna edirsə, paketlər tunelə çatmadan filtrlənir. Konsolun göstəricisi yalnız IKE səviyyəsini əhatə edir, ona görə ikisindən hansının baş verdiyini deyə bilməz.
ipsec statusall
Child təhlükəsizlik assosiasiyasını tapın və yanında çap olunmuş trafik seçicilərini oxuyun, sonra onları yaradılmış konfiqurasiyadakı prefikslərlə müqayisə edin.
Lokal prefiks daxilindəki hostdan VPC prefiksi daxilindəki hosta test edin və geri dönüş yolunu, həmçinin AWS tərəfindəki istənilən təhlükəsizlik qrupunu və ya şəbəkə ACL-ni yoxlayın. Düzgün seçicilər paketi sonradan atılmaqdan qorumur.
Seçicilər uyğunlaşdıqdan sonra hələ də uğursuz olduqda
Hər iki tərəfdə marşrutun tunelə getdiyini təsdiqləyin, sonra NAT cihazının trafiki siyasətin gözləmədiyi şəkildə yenidən yazmadığını təsdiqləyin. Siyasət əsaslı tunel paket ünvanlarına uyğunlaşır, ona görə siyasət qərarından sonra tətbiq olunan tərcümə nəticəni dəyişir.
Başqa təklifi dəyişməzdən əvvəl hər tərəfdə bir girən və bir çıxan paketi qeydə alın.
Biletə seçiciləri, 1-ci və 2-ci mərhələ təkliflərini və mənbə ünvanını qeyd edin. Bu dörd dəyər əksər saytlararası uğursuzluqları zəng etmədən izah edir.