Peered VPC-yə çatmaq üçün AWS Client VPN, yoxsa bastion

Bir Client VPN endpoint-i öz əlaqəli VPC-si ilə peered olan VPC-yə çata bilər və bunu qanuni etmək üçün bastiona ehtiyac yoxdur. Seçim etməyə dəyər məsələ trafikin harada əl dəyişdirməsidir: assosiasiya subpetinə düşən və peering bağlantısını keçən endpoint marşrutu, yoxsa peered VPC-də sessiyanı bitirən host. Hər iki yol işləyir və fərqli yerlərdə uğursuz olur, ona görə qərar AWS-in nəyə icazə verdiyindən deyil, sahiblikdən və audirdən ibarətdir. Budur onların arasında necə seçdiyim və marşrutlaşdırılmış yolu işlədən dörd qeyd.

İki yol, bir endpoint, fərqli sahiblər

Marşrutlaşdırılmış yolda müştəri trafiki endpoint-ə çatır, assosiasiya subpetindəki Client VPN şəbəkə interfeysinin ünvanına çevrilir və həmin subpetdən A-dan-B-yə peering bağlantısı üzərindən çıxır. VPC B heç bir VPN sessiyası bitirmir; o, VPC A-dan gələn adi trafiki görür, buna görə də geri marşrutu müştəri hovuzuna deyil, VPC A-ya yönəlir.

Bastion yolunda müştəri əvvəlcə host-a çatır. A-dakı bastion son hop-u yenə peering bağlantısı üzərindən keçirir, yəni peering işini saxlayır və üstünə sessiya əlavə edir. B-dəki bastion da müştəridən yol tələb edir və həmin yol eyni endpoint marşrutu olduqda marşrutlaşdırılmış dizayn üstəgəl bir hop əldə edirsiniz. Bastion yalnız o zaman işi azaldır ki, artıq mövcud olsun, artıq təsdiqi olsun və arxasındakı şey şəbəkə sərhədi deyil, sessiya sərhədi tələb etsin.

Dörd qeyd marşrutlaşdırılmış yolu işlədir

AWS bu ssenarini Client VPN how-it-works səhifəsində sənədləşdirir və praktikada iş iki və ya üç komandanın sahib olduğu dörd qeydə gəlir. Aralıqlar nümunədir; peered aralıq unikal olmalı, geri aralıq isə planınıza uyğun gəlməlidir.

Marşrut və icazə ayrı-ayrı nəzarətlərdir. Uyğun avtorizasiya qaydası olmayan düzgün endpoint marşrutu müştəriyə heç nə vermir; endpoint-in marşrutlaşdıra bilmədiyi təyinat üçün avtorizasiya qaydası ona qara dəlik verir. Hər ikisi eyni aralığı göstərməlidir.

Endpoint marşrutu endpoint-in öz VPC-sindəki subpetə yönəlir, heç vaxt peering bağlantısına yox. VPC marşrut cədvəlləri peering bağlantısına yönəlir, heç vaxt instansa və ya interfeysə yox. Dəyəri ikisi arasında kopyalamaq şikayətsiz yadda saxlayır və heç nə marşrutlaşdırmır.

Assosiasiya subpeti müştəri mənbəyini çevirdiyi üçün B müştəri hovuzuna deyil, VPC A-ya geri marşrutlaşdırmalıdır. Müştəri aralığını peering bağlantısı üzərindən göndərmək simmetrik görünür, baxışdan keçir və səssizcə uğursuz olur, çünki B heç vaxt müştəri mənbəyi olan paket görmür.

Təhlükəsizlik qrupları və icazənin son metri

Marşrutlaşdırma paketləri B-yə çatdırır; B yenə qərar verir. Eyni regionda aktiv peering bağlantısı üçün B-dəki təhlükəsizlik qrupu Client VPN assosiasiyasına tətbiq olunan qrupa istinad edə bilər, bu da qaydanı dar saxlayır və ünvan dəyişikliklərinə davam edir. Qrup istinadı mümkün olmayanda assosiasiya subpet aralığına açıq icazə verin, 0.0.0.0/0-a qədər genişləndirməyin, çünki bu, marşrut səhvini izahsız timeout-a çevirir.

Sonra marşrutlaşdırmanın heç toxunmadığı şeyləri yoxlayın: hər iki subpetdə şəbəkə ACL-ləri, tətbiqin allow-list-i və ya token auditoriyası və DNS. Peering private hosted zonaları kopyalamır, yəni laptop həll edə bilmədiyi ünvana işlək marşrut saxlaya bilər, peering bağlantısı isə sertifikata etimad əlavə etmir. Endpoint-i B üçün cavab verən resolver-ə yönəldin, sonra private adın və sertifikatın uyğun olduğunu təsdiqləyin.

Bastionun dürüst cavab olduğu hallar

Bastionu qəsdən seçmək üçün üç tetik saxlayıram. Peered VPC aralığınız üçün geri marşrut əlavə etməyəcək və ya qrup istinadını qəbul etməyəcək komandaya aiddir. Giriş hər sessiya üzrə təsdiqlənməli və ya qeyd edilməlidir, tətbiq isə bunu özü daşıya bilmir. Yoxsa son hop B-nin içində qalmalıdır, çünki xidmət yalnız orada həll olunur və TLS kimliyi daxili ada bərkidilib.

Bunların heç biri peering-in keçidli olmamasının ətrafından yan keçmək deyil. Keçidsizlik B-dəki resursların nə edə biləcəyini məhdudlaşdırır: onlar A-dan A-nın peered olduğu üçüncü VPC-yə tranzit kimi istifadə edə bilməz. Bu heç vaxt VPN istifadəçisinin birbaşa peered VPC-yə çata bilməməsi demək deyildi və bu yanlış oxunuşun ətrafından keçmək üçün qurulan bastion səbəbsiz yamaqlanacaq host-dur.

Əks səhv zamanla daha baha başa gəlir: hər komandanı artıq mövcud olan tək bastiondan keçirin, sonra görün ki onun təhlükəsizlik qrupu, marşrut cədvəli və yamaq pəncərəsi istehsalat asılılığıdır. Host-un hansı tetikə xidmət etdiyini yazın və tetik yox olanda onu təqaüdə çıxarın.

Transit Gateway və bir neçə assosiasiya hesabı dəyişir

Endpoint subpetə deyil, birbaşa Transit Gateway-ə qoşulubsa, model dəyişir: müştərilər artıq assosiasiya subpetindəki interfeys ünvanına çevrilmir və gateway marşrut cədvəlləri müştəri aralığını üstəgəl peered VPC-yə aparan qoşulmanı daşımalıdır. Bu, miqyasda daha təmizdir, amma iş dörd qeyddən gateway marşrut cədvəllərinə keçir.

Bir neçə assosiasiya yoxlamaları çoxaldır. Endpoint marşrutu endpoint-ə aiddir, lakin hər assosiasiya subpeti real peering növbəti hopu olan marşrut cədvəlinə ehtiyac duyur. Sessiya bir assosiasiyadan keçə bilər, digərinin geri yolu olmaya bilər, ona görə hər birini sınayın.

Qırılmanı tez tapan yoxlama sırası

Bunları sıra ilə işlədin; hər addım keçə bilər, növbəti isə uğursuz ola bilər və müştəri timeout-u demək olar ki, heç vaxt hansının qırıldığını demir.

1. Tətbiq adını müştəridən həll edin və ünvanın peered aralığın içində olduğunu yoxlayın.
2. Qoşulun, sonra sessiyanı bitirən assosiasiya üçün endpoint bağlantı jurnalını oxuyun.
3. Həmin assosiasiya subpetində marşrut cədvəlinin peered aralığı aktiv peering bağlantısına yönəltdiyini təsdiqləyin.
4. B-dəki resurs subpetində interfeys aralığı üçün geri qeydini və uyğun qrup qaydalarını təsdiqləyin.
5. Bir icazəli əməliyyatı və əlçatmaz qalmalı bir resursu sınayın; ikincisi sazlama qalıqlarını tutur.
6. Hər split-tunnel marşrut dəyişikliyindən sonra yenidən qoşulun, çünki işləyən tunel yeni marşrut dəstini götürməyəcək.

İki simptomu yadda saxlamağa dəyər. B-yə çatıb cavabsız qalan SYN demək olar ki, həmişə itkin geri marşrutdur. Tamamlanıb sonra sıfırlanan bağlantı adətən qrup, ACL və ya tətbiqdir. Heç biri endpoint jurnalında səbəb kimi görünmür, ona görə dörd qeydi hər birinin yanında sahibi ilə saxlayın.

Üç tetikdən heç biri keçərli deyilsə, marşrutlaşdırılmış yolu bitirin və o dörd qeydi yazın. Biri keçərlidirsə, bastionu yalnız həmin sərhəd üçün saxlayın və endpoint marşrutunu qarşısında sessiya tələb etməyən xidmətlər üçün buraxın.