AWS NAT gateway VPN-ə doğru hansı mənbə IP-dən istifadə edir?

VPC konsolunu açırsınız, çünki tərəfdaş Site-to-Site VPN üzərindən hansı mənbə aralığının gələcəyini soruşub. NAT gateways səhifəsi Elastic IP bağlanmış ictimai gateway göstərir və cazibə həmin ünvanı göndərib davam etməkdir. Bu, internet yolu üçün doğru, VPN yolu üçün isə səhv cavabdır və fərq marşrut cədvəlinin hansı gateway-ə baxmasındadır. İcazə siyahısını yazmazdan əvvəl marşrutu addım-addım izləyin.

İcazə siyahısından deyil, NAT gateways səhifəsindən başlayın

NAT gateways səhifəsi sizə subneti, tipi və Elastic IP-ni deyir və bu üç sahə başlamaq üçün kifayətdir. Demədiyi şey, trafikin sonra hansı yolla getdiyidir. Bu, NAT gateway-in subnetinə bağlı marşrut cədvəllərindən gəlir.

Əvvəlcə tipi oxuyun, çünki ictimai və ya özəl olma zəncirdə sonradan internet gateway-in görünüb-görünməyəcəyini müəyyən edir. Sonra subneti oxuyun, çünki ikinci marşrut oradadır.

İki çevirməni izləyin

Həm ictimai, həm də özəl NAT gateway-lər iş yükünün özəl IPv4 mənbəyini NAT gateway-in öz özəl IPv4 ünvanına çevirir. Bu birinci çevirmə tipdən asılı olmayaraq baş verir. İkinci çevirmə unudulanıdır: ictimai NAT gateway trafiki internet gateway-ə verir, o da ünvanı bağlı Elastic IP-yə xəritələyir.

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

Özəl yolda zəncirdə internet gateway yoxdur. Trafik transit gateway və ya virtual private gateway vasitəsilə çıxdıqda, NAT gateway təlimatı NAT gateway-in özəl ünvanını uzaq tərəfin aldığı mənbə kimi sənədləşdirir. Tərəfdaşın icazə verməli olduğu ünvan budur, Elastic IP deyil.

VPN yolu adətən özəl ünvanı göstərir

10.20.1.0/24-də tərəfdaş prefiksinə çatan iş yükü üçün iş yükü subnetinin marşrut cədvəli NAT gateway-ə, NAT gateway-in subnetinin marşrut cədvəli isə özəl gateway yoluna baxır. Hər iki addım vacibdir və yalnız ikincisi tərəfdaşın nə gördüyünü müəyyən edir. NAT subnetinin VPN yoluna marşrutu yoxdursa, paket heç vaxt çatmır və bu, səhv mənbə ünvanından fərqli bir uğursuzluqdur.

Ünvanlar haqqında ümumiyyətlə danışmazdan əvvəl o ikinci marşrutu yoxlayın. Çatışmayan marşrut və səhv bildirilmiş mənbə sadəcə trafik görməyən tərəfdaş üçün tam eyni görünür.

İkinci çevirmə cavabı dəyişdikdə

AWS həmçinin transit gateway qoşmasında açıq, uyğun bire-bir NAT xəritələməsi təklif edir. Bu xəritələmə uzaq xidmət görməzdən əvvəl mənbəyi yenidən çevirə bilər və bu, yalnız marşrutlaşdıran standart davranış deyil. Onu qəsdən konfiqurasiya etmək lazım olduğundan, təsadüfən miras aldığınız bir şey kimi deyil, dizayn istisnası kimi qəbul edin. Komandanızda heç kim onu açdığını xatırlamırsa, qoşmanı oxuyana qədər onun olmadığını fərz edin.

Dizaynınız ondan istifadə edirsə, icazə siyahısı NAT gateway-in ünvanını deyil, yekun xəritələməni təsvir etməlidir. Eyni ehtiyat əlçatanlıq yollarına da aiddir: bir neçə gateway ünvanı iştirak etdikdə gözlənilən mənbə çoxluğu birləşmədir, tək nümunəvi ünvan deyil. Hər ünvanın hansı çevirməyə aid olduğunu yazın, çünki mənşəyi olmayan siyahını sonradan audit etmək mümkün deyil.

Özəl NAT gateway-ə onu internet gateway-ə yönəltməklə internet xidməti vermək olmaz; AWS belə trafikin atıldığını sənədləşdirir. Tipi tam yoldan seçin, tələbdəki VPN sözündən deyil.

Tərəfdaşınızın hərəkət edə biləcəyi müqaviləni yazın

İstifadəyə yararlı müqavilənin dörd hissəsi var: axınların başladıldığı istiqamət, tərəfdaşın görəcəyi çevrilmiş kimlik, həmin kimlik üçün qayıdış marşrutu və tətbiq olunan müdafiə əhatəsi. NAT gateway axınları dəstəklənən mənbə tərəfdən başladılır, yəni bu, özəl iş yükünü açmaq üçün gələn port yönləndirmə xidməti deyil. Bunu erkən ucadan demək, hər tərəfin digərinin başladığını güman etdiyi dizayn baxışının qarşısını alır.

Çevirmə ünvan üst-üstə düşməsinin yüngülləşməsini və proqnozlaşdırıla bilən mənbə siyasətini alır, tərəfdaşın jurnallarında fərdi iş yükü kimliyini isə itirir. Audit hər iş yükü üzrə aidiyyət tələb edirsə, o kimliyi çevrilmiş mənbə ünvanından bərpa etməyə çalışmaq əvəzinə tətbiq qatında saxlayın.

Sonra hər dəyişiklikdən sonra hər iki marşrut cədvəlini yenidən yoxlayın, çünki yeni qoşma və ya yenidən əlaqələndirilmiş subnet cavabı səssizcə yenidən yazır.