AWS Client VPN qoşulub, amma EC2 yenə cavab vermir

Noutbukum qoşulduğunu göstərirdi. AWS Client VPN müştərisi yaşıl vəziyyətini göstərdi, endpoint sessiya qeydə aldı, amma mən yenə də şəxsi subnetdəki EC2 instansiyasında MongoDB portunu aça bilmədim. Açıq-aşkar heç nə sınmamışdı: sertifikat etibarlı idi, profil konsoldan gəlirdi və tunel trafiki daşıyırdı. Səhv mənim idi, çünki qoşulub sözünü icazə verilib kimi oxuyurdum.

Giriş yalnız bir suala cavab verir: bu kimlik sessiya qura bilərmi? Bundan sonrakı hər şeyi sertifikatınızı heç vaxt görməyən ayrı qaydalar həll edir. Autentifikasiyadan keçən sessiya ilə gəlib çatan paket iki fərqli uğurdur və VPN işləyir, amma host əlçatmaz deyən şikayətlərin çoxu bu ikisinin arasındakı boşluqda yaşayır.

Aşağıdakı yoxlamalar indi istifadə etdiyim sıradır.

Qoşulmuş sessiya əslində nəyi sübut edir

Handshake zamanı endpoint müştəri sertifikatını öz trust store-u ilə yoxlayır və ya SAML konfiqurasiya edilibsə, brauzeri identity provider-ə yönləndirir. Bu keçərsə, müştəri endpoint-in müştəri CIDR-indən ünvan alır və konsol aktiv bağlantı göstərir. Bu mübadilənin heç bir məqamında 10.0.4.17 ünvanına 27017 portundan çata biləcəyiniz soruşulmur.

Hədəf üçün icazə endpoint-də ayrı bir obyektdir. Hər axın avtorizasiya qaydaları ilə müqayisə olunur və hər qayda hədəf CIDR-ini qaydanın verildiyi qrupla birləşdirir. Hədəfi heç bir qayda əhatə etmədikdə endpoint sessiyanı qəbul edir və trafiki atır. Nə banner var, nə yenidən qoşulma dövrəsi, nə də müştəri interfeysində imtina yazısı.

Avtorizasiya qaydasını VPC ilə deyil, resursla müqayisə edin

Qaydaları sadalayın və onları instansiyanın həqiqətən malik olduğu ünvanın yanına qoyun:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Çıxış hər qayda üçün hədəf CIDR-i və qrup identifikatoru göstərir. İçində iki nasazlıq gizlənir. Qayda 10.0.0.0/16 ünvanına icazə verə bilər, halbuki instansiya 10.1.0.0/16 üzərində peer edilmiş VPC-də yerləşir; peerinq marşrutu mövcuddur, amma ikinci diapazon üçün heç kim avtorizasiya qaydası yazmayıb. Ya da qayda istifadəçinin kataloqda üzv olduğu, amma endpoint-in qiymətləndirdiyi qrupda olmadığı kataloq qrupuna işarə edir.

Hədəfi əhatə edən ən dar qaydanı yazın və ikinci CIDR həqiqətən lazım olduqda ikinci qayda əlavə edin. Sürətli başlanğıcdan gələn geniş 0.0.0.0/0 qaydası işləyir və buna görə istehsalata qədər yaşayır və modeli gizlədir.

Paketin hərəkət edib-etmədiyini iki marşrut cədvəli həll edir

Endpoint marşrutu hədəf CIDR-ini endpoint-in əlaqələndiyi subnetlərdən birinə xəritələyir. Bu yolun yarısıdır. Subnetin öz marşrut cədvəli hələ də paketi necə yönləndirəcəyini bilməlidir və bu, hədəf peerinq bağlantısı, transit gateway və ya site-to-site tuneli ilə əlçatan yerli diapazon arxasında olanda dərhal vacib olur.

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Hədəfi resurs CIDR-inə uyğun gələn və hədəf obyekti əlaqəli subnet olan marşrut axtarın. Marşrut yoxdursa, əlavə edin. Mövcuddursa və host hələ də səssizdirsə, boşluq VPC tərəfindədir, ona görə əlaqə subnetinin marşrut cədvəli ilə müqayisə edin.

Bir müştəri tərəfi parametri tuneli pozmadan marşrutlaşdırmanı pozur: route-nopull olan profil. Bu direktiv OpenVPN əsaslı müştəriyə serverin göndərdiyi marşrutları nəzərə almamağı tapşırır, beləliklə interfeys yalnız endpoint-in öz ünvanı ilə qalxır və hədəfin sadəcə marşrutu olmur. Linux-da ip route show və ya macOS-da netstat -rn ilə tun interfeysindən marşrutun olub-olmadığını yoxlayın. Yoxdursa, ixrac edilmiş profildən route-nopull-u çıxarın və göndərilən marşrutların tətbiq olunması üçün yenidən qoşulun.

Təhlükəsizlik qrupları müştəri ünvanınızı görmür

Bir günorta səhv etdiyim hissə budur. Subnetlə əlaqələndirilmiş IPv4 endpoint üçün xidmət müştərinin mənbə ünvanını endpoint-in həmin subnetdəki şəbəkə interfeysinin ünvanına çevirir. İnstansiyaya gələn paket müştərinizin göstərdiyi ünvanı daşımır, ona görə müştəri hovuzuna, məsələn 172.16.0.0/22-yə icazə verən təhlükəsizlik qrupu qaydası heç nəyə uyğun gəlmir.

Porta müştəri CIDR-indən deyil, əlaqənin interfeysinə bağlanmış endpoint təhlükəsizlik qrupundan icazə verin. Qrupa istinad etmək ünvanı sərt kodlaşdırmaqdan daha davamlıdır, çünki interfeys ünvanı sizin nəzarətinizdə deyil. Şəbəkə ACL-ləri vəziyyətsizdir, ona görə fərdi qeydlərin olduğu yerdə həm daxil olan, həm də çıxan istiqamət axına icazə verməlidir.

Həm də instansiyanın şəxsi ünvanına qoşulun. İctimai IP paketi VPC-dən çıxarır və başqa qaydaları olan başqa yolla geri gətirir, ona görə ictimai ünvanla sınaq şəxsi yol haqqında heç nə demir.

İlk nasazlıqda dayanan izolyasiya sırası

Bunları sıra ilə keçin və hansısa biri uğursuz olanda dayanın. Hər addım hamısını deyil, bir təbəqəni istisna edir.

1. Sessiyanın hansı kimlikdən istifadə etdiyini və endpoint-in hansı qrupu qiymətləndirdiyini təsdiqləyin. Bir trust store-dan gələn sertifikat kataloqdan gələn SAML təsdiqi ilə eyni subyekt deyil.
2. Avtorizasiya qaydasının həmin qrup üçün resurs CIDR-ini əhatə etdiyini təsdiqləyin.
3. Endpoint marşrutunun mövcud olduğunu və əlaqəli subnetə yönəldiyini, sonra subnet marşrut cədvəlinin irəliyə çata bildiyini təsdiqləyin.
4. Təhlükəsizlik qrupunun porta müştəri hovuzundan deyil, endpoint interfeysindən icazə verdiyini təsdiqləyin.
5. Tətbiq problemini müştəri yolu probleminindən ayırmaq üçün VPC-nin içindən, eyni subnetdəki başqa instansiyada SSM sessiyası ilə sınayın.

Addımlar həlledici olmadıqda arxalandığım cədvəl budur:

İki hesab detalları icazə nasazlığına bənzəyən simptomlar yaradır. Hər istifadəçiyə ayrı müştəri sertifikatı lazımdır; birini iki maşın arasında paylaşmaq sessiyaların bir-birini sıxışdırmasına səbəb olur və nəticə imtina deyil, yenidən qoşulma dövrəsi olur. Yeni endpoint yaradılanda konsol elə DNS adı göstərir ki, bəzi müştəri versiyaları onu yalnız endpoint səhifəsində göstərilən təsadüfi prefikslə qəbul edir, ona görə adı yenidən qurmaq əvəzinə tam kopyalayın.

Beşinci addım sizi ilişib qoysa, heç nəyi dəyişməzdən əvvəl endpoint-in bağlantı jurnalını götürün və avtorizasiya qeydlərini oxuyun. Jurnal yoxlanılan hədəfi və uyğun gələn və ya gəlməyən qaydayı adlandırır və bu, dörd təbəqəli sualı bir cavaba endirir.