VGW yoxsa TGW? AWS Site-to-Site IPsec tuneli harada bitir

İnsanlar AWS Site-to-Site VPN-in paketi hansı nöqtədə qorumağı dayandırdığını soruşur və tək cavab gözləyirlər: şlüzda. Bu cavabın faydalı variantı hansı şlüz olduğunu adlandırır, çünki virtual özəl şlüz və tranzit şlüzü fərqli qoşma obyektləri olan fərqli quruluşlardır və səhv olanı fərz edən rəyçi qiymətləndirmənin qalanını mövcud olmayan diaqram üzərində qurur. Aşağıdakı üç yoxlamanı sıra ilə işləyin. Hər biri ya sərhədi təsdiqləyir, ya da əvvəlki cavabın başqa resursa aid olduğunu bildirir.

Hər şeyi qiymətləndirməzdən əvvəl üç son nöqtəni adlandırın

Bu yolun şifrələmə auditinə üç adlandırılmış şey lazımdır: müştəri şlüzü, IPsec-i bitirən AWS VPN hədəfi və daxili paketi qəbul edən tətbiq son nöqtəsi. Bir konsol səhifəsi açmadan onları resurs identifikatorları ilə birlikdə yazın, çünki bu nöqtədən sonra hər şey həmin üçündən biri haqqında ifadədir.

Müştəri şlüzü sizindir və konfiqurasiyası sizə görünür. AWS hədəfi idarə olunan resursdur və səhv onu fərz etməkdir: VPN bağlantısı virtual özəl şlüzə və ya birbaşa tranzit şlüzünə qoşula bilər və heç biri digərini nəzərdə tutmur. Üçüncü son nöqtə insanların atladığı nöqtədir və tətbiq məlumatları ilə bağlı faktiki suala cavab verən yeganə nöqtədir.

Yoxlama 1: tuneli əslində hansı şlüz bitirir

Hər iki quruluş dəstəklənir və Site-to-Site VPN arxitektura təlimatı onları yan-yana təsvir edir, ona görə diaqramdan deyil, API-dən soruşun, çünki diaqram çox vaxt bir il köhnəlmiş olur. Bir bağlantı üzərində yalnız oxuma üçün sorğu VPN hədəf sahələrini qaytarır:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

Fərqləndirici TransitGatewayId-dir, VpnGatewayId deyil. TransitGatewayId boş olan bağlantı ayrıca virtual özəl şlüzdə bitir, həmin sahə doldurulmuş bağlantı isə tranzit şlüzünün VPN qoşması-nda bitir və bu halda VpnGatewayId hələ də dolu ola bilər, çünki o, qoşmanın əsas şlüzünü adlandıra bilər. Əvvəlcə TGW sahəsini oxuyun, sonra qoşma növünü sahə adından deyil, qoşmalar siyahısından təsdiqləyin, çünki həmin tranzit şlüzündəki VPC qoşması VPN qoşması deyil. Bağlı VPC-də təyinat instansiyasını tapmaq paketi hansı VPN qoşmasının daşıdığı barədə heç nə demir.

Orada olanda tunelləri də yoxlayın. Bağlantı artıqlıq üçün iki IPsec tuneli daşıyır və ikinci tuneli heç vaxt qalxmamış bağlantı, şifrələmə sərhədi ilə bağlı heç nəyi dəyişməsə də, mövcudluq üçün real bir tapıntıdır:

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

Yoxlama 2: daxili paket hələ nə daşıyır

IPsec bitdikdən sonra AWS deşifrə edilmiş paketi ona uyğun gələn marşrutla yönləndirir. Bu nöqtədən sonra trafik adi VPC trafikidir və VPN-in qorunması bitmişdir. Bu xidmətdə boşluq deyil; sərhədin mənası budur və yoxlama siyahısının bəndi bunu açıq şəkildə deməkdir, "VPN şifrəlidir" ifadəsinin "məlumatlar uçdan-uca şifrəlidir" yerinə keçməsinə imkan verməməkdir.

İndi içəridə nə olduğunu yoxlayın. Daxili paket açıq mətnli tətbiq protokoludursa, başqa bir şey onu şifrələyənə qədər aşağı axında heç nə məxfilik əlavə etmir. Daxili paket artıq TLS sessiyası daşıyırsa, xarici IPsec-in çıxarılması o sessiya üçün heç nəyi dəyişmir: o, öz son nöqtəsinə qədər qorunmuş qalır, həmin son nöqtə harada olursa olsun.

Ümumi həddindən artıq düzəliş şlüzün arxasındakı hər şeyin açıq olduğu qənaətinə gəlməkdir. Belə deyil. Xidmət nəqli, yaddaş şifrələməsi və tətbiq TLS-i ayrı şərtləri olan ayrı mexanizmlərdir və hər biri VPN-in formasından çıxarılmadan, öz şərtləri ilə qiymətləndirilməlidir. ACCEPT göstərən axın jurnalı qeydi marşrutlaşdırmanın işlədiyini sübut edir və məxfilik barədə heç nə demir; bu yoxlama siyahısı məhz bu səhvin qarşısını almaq üçün var.

Yoxlama 3: şlüzün arxasında TLS-i nə bitirir

Ünvana deyil, dinləyiciyə baxın. Yük balanslaşdırıcısı və ya proksi TLS-i bitirirsə, müştərinizin saxladığı bağlantı orada bitir və proksi arxa tərəfə ikinci bağlantı açır ki, bu da açıq mətn və ya fərqli etimad zənciri olan TLS ola bilər. Şəxsi IP ünvanı və uyğun marşrut həmin ikinci bağlantı haqqında sübut deyil.

Həqiqətən vacib olan son nöqtəni VPC-nin içindən sınaqdan keçirin, bir dəfə həll etdiyiniz IP ilə deyil, tətbiqin istifadə etdiyi adla:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

Sorğunun keçdiyi hər addım üçün bunu təkrarlayın. Cavab müştəriyə baxan adla arxa tərəfin adı arasında fərqlənirsə, VPN-in heç vaxt əhatə etmədiyi seqmenti tam olaraq tapmısınız və yazılmalı olan tapıntı budur.

Nəticəni hökm kimi deyil, seqmentlər kimi qeyd edin

Bu yoxlama siyahısının çıxışı hər seqment üçün bir sətir olan kiçik cədvəldir: müştəri şlüzündən AWS VPN hədəfinə, şlüzdən iş yükünə, iş yükündən məlumat anbarına və arada hər hansı proksi addımı. Hər sətir onu nəyin qoruduğunu və bu qorunmanın nədən asılı olduğunu bildirir. Mexanizmsiz və son nöqtəsiz "şifrələnmiş" bir sətir deyil.

Sonra ilkin tələbə onun soruşulduğu şərtlərlə cavab verin. Tələb məlumatların iş yükü onu alana qədər məxfi qalmasıdırsa, VPN yalnız birinci seqmenti ödəyir və qalan sətirlər üçün tətbiq nəqli, xidmət TLS-i və ya yaddaş şifrələməsi ayrıca konfiqurasiya edilməli və yoxlanmalıdır.

Bağlantı identifikatorlarını, tunel vəziyyətlərini və sertifikat subyektlərini qeyddə saxlayın. Kimsə dizayna altı aydan sonra qayıtdıqda, bu üç artefakt sərhəd sualına dəqiqələr içində cavab verir və mübahisəni diaqramdan yenidən başlatmağa ehtiyac qalmır.