AWS VPN'de yerel ve uzak CIDR: hangi taraf hangisi?

Site-to-Site VPN seçeneklerini açarsınız, yerel ve uzak olarak etiketlenmiş iki CIDR kutusu görürsünüz ve yerel saydığınız adrese, yani VPC'ye uzanırsınız. Bu, API'nin kastettiğinin tersidir. Bağlantı seçeneklerinde LocalIpv4NetworkCidr müşteri ağ geçidi tarafını, RemoteIpv4NetworkCidr ise AWS tarafını adlandırır, çünkü bağlantı müşteri ağ geçidinden kurulur. Konsol bunu asla yüksek sesle söylemez ve makul görünen bir yer değiştirmeyi hiçbir şey reddetmez.

Konsol etiketinden değil, API çağrısından başlayın

Bağlantı seçenekleri başvurusunu bir kez baştan sona okuyun ve her seçeneğin müşteri ağ geçidinin bakış açısıyla yazıldığını fark edin. Bu, adlandırmanın tesadüfü değildir. Tünel, sizin tarafınızda onu sonlandıran cihazın gördüğü gibi anlatılır; yani yerel, ağ geçidinizin arkasındaki ağı, uzak ise AWS ağ geçidinin arkasındaki ağı anlatır. Hem IPv4 hem de IPv6 alanları aynı kurala uyar.

Bir şey yazmadan önce iki etiketi yapışkan nota yazın: müşteri tarafı, AWS tarafı. Sonra adreslerinizi bunlara eşleyin.

Rollerin işaretlendiği bir örnek

Yerel önekin 10.20.0.0/16, VPC önekinin 10.60.0.0/16 olduğunu varsayalım. Seçenekler tam olarak rollerin önerdiği gibi okunur; yerel aralık yerel alandadır:

{
  "LocalIpv4NetworkCidr": "10.20.0.0/16",
  "RemoteIpv4NetworkCidr": "10.60.0.0/16"
}

Şimdi aynı çifti eş cihazı yapılandıran kişiye verin ve tuzağın nasıl çalıştığını izleyin. Birçok güvenlik duvarında yerel, tünelin sonlandığı arayüzü, uzak ise karşı ucu anlatır; bu, AWS tarafı için ters eşlemedir. İkisi de haklı olabilir ve yine de hiç kurulmayan bir tünel ortaya çıkabilir, çünkü iki sözlük farklı uç noktaları anlatır.

Herhangi bir cihaza dokunmadan önce alıştırmayı eşin terminolojisiyle kâğıt üzerinde yineleyin; iki CIDR ve iki etiketle.

Varsayılanlar bir tasarım değildir

Aynı başvuru, IPv4 alanlarının ikisi için de varsayılan olarak 0.0.0.0/0 verir; IPv6 için de benzer değerler vardır. Bu değerleri mevcut bir bağlantıda görmek, alanın hiç daraltılmadığını söyler, internet çıkışının yapılandırıldığını değil. Yol dağıtımı, alt ağ yol tablosu ve güvenlik kontrolleri hangi trafiğin gerçekten geçebileceğine hâlâ karar verir; CIDR değerleri yalnızca tünelin hangi aralıkları seçmeye razı olduğunu anlatır.

Bu yüzden dar bir değeri varsayılanla değiştirmek, tünel kötü davrandığında başvurulacak bir uyumluluk hilesi değildir. Seçiciyi genişletir ve diğer her katmanı tam olduğu gibi bırakır.

Eş cihaz öbür bakış açısını kullanır

AWS tarafı netleştiğinde, kalan karışıklığın çoğu eş yapılandırmasında yaşar. Yerel ağ ve uzak ağ isteyen bir cihaz kendi arayüzünü yerel olarak tanımlar; bu yüzden VPC aralığınız onun uzak alanına, yerel aralığınız onun yerel alanına gider. Bunun yerine trafik seçicilerini çiftler hâlinde istiyorsa, iki yönü de açıkça yazarsınız ve etiketler eşleştirmeden daha az önemlidir.

Cihazın alan adlarını değil, alan yardımını okuyun. Üreticiler aynı iki sözcüğü üç farklı kavram için yeniden kullanır.

Ardından tünel durumunu iki faz için de kontrol edin; uyuşmayan seçici genellikle ikinci faz hatası olarak görünür ve birinci faz sessizce kurulu kalır.

Seçenekleri bir değişiklik gibi değiştirin, belge gibi değil

Çalışan bir VPN'de bağlantı seçeneklerini düzenlemek hizmeti kesebilir, bu yüzden bunu bir bakım penceresi, geri alma değeri ve kimin etkilendiğine dair not içeren bir bakım işlemi olarak ele alın. Önce mevcut seçenekleri, iki CIDR alanı ve tünel seçenekleri dahil kaydedin; böylece geri alma yeniden kurma değil, yapıştırma olur.

Değişiklikten sonra AWS tarafından ve eşten doğrulayın: her aralıktaki bir kaynak diğerindeki bir hedefe ulaşır, iki yönde de. Tek taraftan tek bir ping yalnızca tek bir seçiciyi kanıtlar.

Ardından bağlantı belgelerini rolleri yazarak güncelleyin; böylece sonraki kişi yerelin sizin tarafınız olduğunu yeniden keşfetmek zorunda kalmaz.