AWS Site-to-Site VPN ke NAT Gateway: VGW versus Transit Gateway

Semua orang menggambar diagram yang sama pada percobaan pertama: VPN ke VPC, NAT gateway keluar ke internet, selesai. Namun AWS tidak mendukung jalur itu ketika VPN berakhir pada virtual private gateway, dan kegagalannya cukup senyap sehingga tim membangunnya ulang lebih dari sekali. Desain yang berfungsi membutuhkan transit gateway, yang mengubah gateway dan tabel rute di kedua sisi. Bandingkan kedua bentuk sebelum menggambar apa pun.

Topologi yang terlihat jelas dan tidak didukung

Dokumentasi NAT gateway AWS menarik garis yang mengejutkan siapa pun yang hanya membangun desain satu VPC: lalu lintas dari koneksi Site-to-Site VPN tidak dapat dirutekan ke NAT gateway melalui virtual private gateway. Jenis gateway tempat VPN berakhir menentukan apakah ada jalur penerjemahan sama sekali. Kesalahan ini bertahan karena status tunnel UP dan instans EC2 di subnet yang sama mencapai internet tanpa masalah. Tidak ada dari kedua pengamatan itu yang menguji arah yang rusak.

Dalam praktik paket tiba dengan alamat sumber dari jaringan on-premises dan tidak menemukan hop berikutnya yang didukung untuk menerjemahkannya. Bergantung pada tabelnya, paket dibuang di batas keluar, dan karena tunnel tetap UP sementara instans di subnet yang sama masih mencapai internet, kegagalan dilaporkan sebagai masalah firewall di sisi on-premises.

Virtual private gateway versus transit gateway

Virtual private gateway milik satu VPC. Ia mengakhiri VPN, memasang rute ke tabel rute VPC itu, dan berhenti di situ. Ia tidak punya model attachment, sehingga tidak dapat menyerahkan lalu lintas ke VPC lain atau ke segmen keluar bersama. Cakupan satu VPC itulah seluruh batasannya, dan tidak ada rute yang Anda tambahkan di dalam VPC yang mengubahnya.

Transit gateway adalah hub regional tempat VPN, setiap VPC spoke, dan VPC layanan bersama muncul sebagai attachment. Ia punya tabel rutenya sendiri, yang memilih attachment mana yang menerima prefiks tertentu.

Hub itulah yang memungkinkan keluar terpusat: VPN mendarat sebagai satu attachment, VPC keluar sebagai yang lain, dan tabel rute transit gateway mengirim prefiks menuju internet dari yang pertama ke yang kedua. Dengan virtual private gateway tidak ada attachment kedua untuk dikirimi apa pun, karena itu desain ini tidak bisa ditambal belakangan.

Jalur keluar yang didukung, hop demi hop

Desain acuan punya lima hop dan setiap panah adalah keputusan perutean yang harus Anda konfigurasi. Lalu lintas keluar dari jaringan on-premises ke attachment Site-to-Site VPN, tabel rute transit gateway meneruskannya ke attachment VPC keluar, tempat tabel subnet mengirimnya ke NAT gateway publik. NAT gateway menerjemahkan sumber dan internet gateway membawa paket keluar.

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

Dua detail menentukan apakah hop terakhir berhasil. NAT gateway harus publik, dengan elastic IP dan rute ke internet gateway, karena NAT gateway privat menerjemahkan antarjaringan dan tidak pernah menjadi jalan keluar internet.

Rencanakan satu NAT gateway per Availability Zone yang ingin Anda layani, dengan setiap tabel subnet menunjuk ke yang lokal. Simpan tabel transit gateway dan tabel VPC sebagai objek terpisah dalam catatan Anda, karena yang satu memilih attachment dan yang lain memilih sumber daya di dalam VPC. Rute default hanya di salah satunya membuat separuh jalur tidak terdefinisi dan menghasilkan kegagalan sebagian yang paling sulit dikaitkan.

Jalur balik adalah tempat desain ini gagal

NAT gateway menyimpan status untuk alur yang sudah dilihatnya, sehingga balasan koneksi keluar kembali tanpa aturan masuk baru. Sifat itu tidak memublikasikan layanan on-premises ke internet, dan memperlakukannya seolah-olah begitu adalah cara sebuah tim menghabiskan sehari men-debug koneksi yang tidak akan pernah terbentuk. Untuk lalu lintas yang dimulai klien, empat rute harus sepakat: kebijakan on-premises, tabel transit gateway, tabel subnet keluar, dan tabel subnet NAT. Lewatkan yang terakhir dan permintaan keluar dari gedung sementara balasannya mati di dalam AWS.

Validasi dengan klien sungguhan di balik VPN dan periksa alamat sumber publik yang ia tampilkan. Jika itu elastic IP NAT gateway, penerjemahan terjadi; jika bukan, Anda mengukur keluar yang lain.

Versi asimetris dari kegagalan ini layak dikenali lebih awal. Ketika tabel subnet NAT satu Availability Zone punya rute balik ke prefiks klien dan yang lain tidak, koneksi baru berhasil atau gagal tergantung zona tempat alur mendarat, dan polanya salah dibaca sebagai internet yang tidak stabil. Bandingkan tabel subnet untuk setiap zona yang Anda layani alih-alih memperbaiki zona tempat tiket dibuka, karena rute yang hilang adalah seluruh kesalahannya dan tidak ada yang perlu diubah di sisi seberang.

Kapan proxy eksplisit adalah desain yang lebih baik

Proxy HTTP pada instans di VPC keluar adalah alternatif yang sah dan sering lebih murah. Klien dikonfigurasi untuk memakainya, proxy membuka koneksinya sendiri ke luar, dan jalur balik menjadi masalahnya, bukan teka-teki perutean simetris. Untuk sedikit aplikasi, ini menghapus sebagian besar pekerjaan transit gateway. Ia juga memberi log per pengguna yang tidak dapat dihasilkan NAT gateway.

Namun ia tidak transparan. Apa pun yang mengabaikan pengaturan proxy, dan setiap protokol yang bukan HTTP, tidak akan mengikuti jalur itu.

Pilihannya bergantung pada apa yang sebenarnya diucapkan aplikasi Anda dan berapa banyak identitas yang Anda butuhkan di log. Di tempat mereka berbicara HTTP, proxy mendapat tempatnya; di tempat Anda butuh keluar umum untuk protokol sembarang, desain transit gateway adalah yang didukung AWS. Memutuskannya di awal lebih murah daripada menemukannya setelah tabel rute dibangun.