AWS Site-to-Site VPN'den NAT Gateway'e: VGW'ye karşı Transit Gateway

Herkes ilk seferinde aynı diyagramı çizer: VPN VPC'ye, NAT gateway dışarı internete, bitti. Ancak VPN virtual private gateway'de sonlandığında AWS bu yolu desteklemez ve hata o kadar sessizdir ki ekipler onu birden fazla kez yeniden kurar. Çalışan tasarım bir transit gateway gerektirir; bu da her iki tarafta gateway'i ve rota tablolarını değiştirir. Bir şey çizmeden önce iki biçimi karşılaştırın.

Apaçık görünen ve desteklenmeyen topoloji

AWS'in NAT gateway belgeleri, yalnızca tek VPC tasarımı kuran herkesi şaşırtan bir çizgi çeker: Site-to-Site VPN bağlantısından gelen trafik, virtual private gateway üzerinden NAT gateway'e yönlendirilemez. VPN'in hangi gateway türünde sonlandığı, bir çeviri yolunun var olup olmadığını belirler. Hata ayakta kalır çünkü tünel durumu UP'tır ve aynı subnet'teki bir EC2 örneği internete sorunsuz ulaşır. Bu iki gözlemden hiçbiri bozuk yönü test etmez.

Pratikte paket, şirket içi ağdan gelen kaynak adresiyle ulaşır ve onu çevirecek desteklenen bir sonraki hop bulamaz. Tablolara bağlı olarak çıkış sınırında düşürülür ve tünel UP kalırken aynı subnet'teki örnek internete ulaştığı için hata, şirket içi firewall sorunu olarak bildirilir.

Virtual private gateway'a karşı transit gateway

Bir virtual private gateway tek bir VPC'ye aittir. VPN'i sonlandırır, rotaları o VPC'nin rota tablolarına kurar ve orada durur. Attachment modeli yoktur, bu yüzden trafiği başka bir VPC'ye veya paylaşılan çıkış segmentine aktaramaz. Tek VPC kapsamı tüm kısıtlamadır ve VPC içine eklediğiniz hiçbir rota bunu değiştirmez.

Transit gateway, VPN'in, her spoke VPC'nin ve paylaşılan hizmetler VPC'sinin attachment olarak göründüğü bölgesel bir merkezdir. Belirli bir prefix'i hangi attachment'ın alacağını seçen kendi rota tabloları vardır.

Merkezi çıkışı mümkün kılan bu merkezdir: VPN bir attachment olarak iner, çıkış VPC'si bir diğeri olarak iner ve transit gateway rota tablosu internete yönelen prefix'leri birinciden ikinciye gönderir. Virtual private gateway ile gönderilecek ikinci bir attachment yoktur, bu yüzden tasarım sonradan yamalanamaz.

Desteklenen çıkış yolu, adım adım

Referans tasarımın beş hop'u vardır ve her ok yapılandırmanız gereken bir yönlendirme kararıdır. Trafik şirket içi ağdan Site-to-Site VPN attachment'ına çıkar, transit gateway tablosu onu çıkış VPC attachment'ına iletir, orada subnet tablosu genel bir NAT gateway'e gönderir. NAT gateway kaynağı çevirir ve internet gateway paketi dışarı taşı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 hop'ların çalışıp çalışmadığını iki ayrıntı belirler. NAT gateway genel olmalıdır; elastic IP ve internet gateway'e rota gereklidir, çünkü özel NAT gateway ağlar arasında çeviri yapar ve asla internet çıkışı olmaz.

Hizmet vermeyi planladığınız her Availability Zone için bir NAT gateway planlayın ve her subnet tablosu yerel olana işaret etsin. Notlarınızda transit gateway tablosunu ve VPC tablolarını ayrı nesneler olarak tutun, çünkü biri attachment, diğeri VPC içindeki kaynağı seçer. Yalnızca birinde varsayılan rota olması yolun yarısını tanımsız bırakır ve nedene bağlanması en zor kısmi arızaları üretir.

Bu tasarımlar tam da dönüş yolunda başarısız olur

NAT gateway daha önce gördüğü akışlar için durum tutar, bu yüzden giden bağlantıya verilen yanıtlar yeni bir giriş kuralı olmadan döner. Bu özellik yerel bir hizmeti internete açmaz ve öyle davranmak, bir ekibin hiç kurulmayacak bir bağlantıyı hata ayıklamakla bir gün geçirmesine yol açar. İstemciden başlayan trafik için dört rotanın anlaşması gerekir: yerel politika, transit gateway tablosu, çıkış subnet tablosu ve NAT subnet tablosu. Sonuncuyu atlarsanız istek binadan çıkar, yanıt ise AWS içinde ölür.

VPN'in arkasındaki gerçek bir istemciyle doğrulayın ve hangi genel kaynak adresini sunduğuna bakın. Bu adres NAT gateway'in elastic IP'siyse çeviri oluyor demektir; başka bir şeyse farklı bir çıkışı ölçüyorsunuz.

Bu hatanın asimetrik sürümünü erken tanımakta yarar var. Bir Availability Zone'un NAT subnet tablosunda istemci prefix'ine dönüş rotası varken diğerinde yoksa, yeni bağlantılar akışın düştüğü bölgeye göre başarılı olur veya başarısız olur ve bu desen yanlışlıkla istikrarsız internet olarak okunur. Talebin açıldığı bölgeyi onarmak yerine hizmet verdiğiniz her bölgenin subnet tablolarını karşılaştırın, çünkü eksik rota arızanın tamamıdır ve karşı tarafta hiçbir şeyin değişmesi gerekmez.

Ne zaman açık bir proxy daha iyi tasarımdır

Çıkış VPC'sindeki bir örnek üzerinde HTTP proxy meşru bir alternatiftir ve çoğu zaman daha ucuzdur. İstemciler onu kullanacak şekilde yapılandırılır, proxy kendi bağlantısını dışarı açar ve dönüş yolu simetrik yönlendirme bulmacası değil onun sorunu olur. Az sayıda uygulama için bu, transit gateway işinin çoğunu ortadan kaldırır. Ayrıca NAT gateway'in üretemediği kullanıcı başına günlük sağlar.

Ancak şeffaf değildir. Proxy ayarlarını yok sayan her şey ve HTTP olmayan her protokol bu yolu izlemez.

Seçim, uygulamalarınızın gerçekte ne konuştuğuna ve günlüklerde ne kadar kimliğe ihtiyacınız olduğuna bağlıdır. HTTP konuştukları yerde proxy yerini kazanır; rastgele protokoller için genel çıkış gerektiğinde AWS'in desteklediği tasarım transit gateway'dir. Bunu önceden kararlaştırmak, rota tabloları kurulduktan sonra keşfetmekten daha ucuzdur.