AWS Site-to-Site VPN və NAT Gateway: VGW yoxsa Transit Gateway

Hamı ilk dəfə eyni diaqramı çəkir: VPC-yə VPN, oradan NAT gateway ilə internetə, hazırdır. Lakin VPN virtual private gateway-də bitəndə AWS bu yolu dəstəkləmir və uğursuzluq o qədər səssizdir ki, komandalar onu bir dəfədən çox yenidən qurur. İşləyən dizayn transit gateway tələb edir və bu, hər iki tərəfdə gateway-i və marşrut cədvəllərini dəyişir. Nə isə çəkməzdən əvvəl iki formanı müqayisə edin.

Aşkar görünən, amma dəstəklənməyən topologiya

AWS-in NAT gateway sənədləri yalnız bir VPC dizaynı qurmuş hər kəsi təəccübləndirən bir xətt çəkir: Site-to-Site VPN bağlantısından gələn trafik virtual private gateway vasitəsilə NAT gateway-ə yönləndirilə bilməz. VPN-in hansı gateway növündə bitdiyi ümumiyyətlə tərcümə yolunun olub-olmadığını müəyyən edir. Səhv ona görə qalır ki, tunel statusu UP-dır və eyni subnet-dəki EC2 instansı internetə problemsiz çatır. Bu iki müşahidənin heç biri pozulmuş istiqaməti yoxlamır.

Təcrübədə paket on-premises mənbə ünvanı ilə gəlir və onu tərcümə edəcək dəstəklənən növbəti hop tapmır. Cədvəllərdən asılı olaraq çıxış sərhədində atılır və tunel UP qaldığı, eyni subnet-dəki instans internetə çatdığı üçün nasazlıq on-premises firewall problemi kimi bildirilir.

Virtual private gateway və transit gateway

Virtual private gateway bir VPC-yə aiddir. O, VPN-i bitirir, marşrutları həmin VPC-nin marşrut cədvəllərinə yazır və orada dayanır. Onun attachment modeli yoxdur, ona görə trafiki başqa VPC-yə və ya ortaq çıxış seqmentinə ötürə bilmir. Bütün məhdudiyyət bu tək VPC əhatəsidir və VPC daxilində əlavə etdiyiniz heç bir marşrut bunu dəyişmir.

Transit gateway regional mərkəzdir; burada VPN, hər spoke VPC və ortaq xidmətlər VPC-si attachment kimi görünür. Onun öz marşrut cədvəlləri var və verilmiş prefiksi hansı attachment-in alacağını onlar seçir.

Mərkəzləşdirilmiş çıxışı məhz bu mərkəz mümkün edir. VPN bir attachment kimi düşür, çıxış VPC-si başqa attachment kimi düşür və transit gateway marşrut cədvəli internetə yönələn prefiksləri birincidən ikinciyə göndərir. Virtual private gateway ilə göndəriləcək ikinci attachment yoxdur, buna görə dizaynı sonradan yamaqla yaratmaq mümkün deyil.

Dəstəklənən çıxış yolu, addım-addım

İstinad dizaynında beş hop var və hər ox konfiqurasiya etməli olduğunuz marşrut qərarıdır. Trafik on-premises şəbəkəsindən Site-to-Site VPN attachment-inə çıxır. Transit gateway marşrut cədvəli onu çıxış VPC attachment-inə ötürür, orada subnet cədvəli onu public NAT gateway-ə göndərir. NAT gateway mənbəyi tərcümə edir, internet gateway paketi bayıra daşıyır.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

Son hopların işləyib-işləmədiyini iki detal həll edir. NAT gateway public olmalıdır, elastik IP-si və internet gateway-ə marşrutu olmalıdır, çünki private NAT gateway şəbəkələr arasında tərcümə edir və heç vaxt internet çıxışına çevrilmir.

Xidmət göstərmək istədiyiniz hər Availability Zone üçün bir NAT gateway planlayın və hər subnet cədvəli yerli olana baxsın. Transit gateway cədvəlini və VPC cədvəllərini qeydlərinizdə ayrı obyektlər kimi saxlayın, çünki biri attachment, digəri VPC daxilində resurs seçir. Yalnız birində default marşrut yolun yarısını qeyri-müəyyən qoyur və aid etməsi ən çətin qismən nasazlıqları yaradır.

Bu dizaynlar məhz qayıdış yolunda sıradan çıxır

NAT gateway artıq gördüyü axınlar üçün stateful-dur, ona görə çıxan bağlantıya cavablar yeni inbound qayda olmadan qayıdır. Bu xassə on-premises xidmətini internetə açmır və elə davranmaq komandanın heç vaxt qurulmayacaq bağlantını bir gün debug etməsinin yoludur. Müştəridən başlayan trafik üçün dörd marşrut uzlaşmalıdır: on-premises siyasəti, transit gateway cədvəli, çıxış subnet cədvəli və NAT subnet cədvəli. Sonuncunu qaçırsanız, sorğu binadan çıxır, cavab isə AWS daxilində ölür.

VPN arxasında real müştəri ilə yoxlayın və onun təqdim etdiyi public mənbə ünvanına baxın. Bu ünvan NAT gateway-in elastik IP-sidirsə, tərcümə baş verir; başqa bir şeydirsə, fərqli çıxışı ölçürsünüz.

Bu nasazlığın asimmetrik variantını erkən tanımaq dəyərlidir. Bir Availability Zone-un NAT subnet cədvəlində müştəri prefiksinə qayıdış marşrutu var, digərində yoxdursa, yeni bağlantılar axının düşdüyü zonadan asılı olaraq uğur qazanır və ya uğursuz olur və bu pattern qeyri-sabit internet kimi yanlış oxunur. Biletin açıldığı zonanı düzəltmək əvəzinə xidmət etdiyiniz hər zonanın subnet cədvəllərini müqayisə edin, çünki çatışmayan marşrut bütün nasazlıqdır və qarşı tərəfdə heç nə dəyişməməlidir.

Açıq proxy nə vaxt daha yaxşı dizayndır

Çıxış VPC-sindəki instansda HTTP proxy qanuni alternativdir və çox vaxt daha ucuzdur. Müştərilər ondan istifadə etmək üçün konfiqurasiya olunur, proxy öz bağlantısını bayıra açır və qayıdış yolu simmetrik marşrut tapmacası deyil, proxy-nin problemidir. Kiçik sayda tətbiq üçün bu, transit gateway işinin çoxunu aradan qaldırır. Həm də NAT gateway-in verə bilməyəcəyi istifadəçi-üzrə logging qazandırır.

Ancaq şəffaf deyil. Proxy parametrlərini nəzərə almayan hər şey və HTTP olmayan hər protokol bu yolla getməyəcək.

Seçim tətbiqlərinizin həqiqətən nə danışdığından və loglarda nə qədər kimlik lazım olduğundan asılıdır. HTTP danışdıqları yerdə proxy öz yerini qazanır; ixtiyari protokollar üçün ümumi çıxış lazım olduqda AWS-in dəstəklədiyi transit gateway dizaynıdır. Bunu əvvəlcədən qərarlaşdırmaq marşrut cədvəlləri qurulduqdan sonra kəşf etməkdən ucuzdur.