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

Semua orang melukis gambar rajah yang sama kali pertama: VPN ke VPC, NAT gateway keluar ke internet, selesai. Tetapi AWS tidak menyokong laluan itu apabila VPN berakhir pada virtual private gateway, dan kegagalan itu cukup senyap sehingga pasukan membinanya semula lebih daripada sekali. Reka bentuk yang berfungsi memerlukan transit gateway, yang mengubah gateway dan jadual laluan di kedua-dua belah. Bandingkan kedua-dua bentuk sebelum melukis apa-apa.

Topologi yang kelihatan jelas dan tidak disokong

Dokumentasi NAT gateway AWS menarik garis yang mengejutkan sesiapa yang hanya membina reka bentuk satu VPC: trafik daripada sambungan Site-to-Site VPN tidak boleh dilalukan ke NAT gateway melalui virtual private gateway. Jenis gateway tempat VPN berakhir menentukan sama ada laluan terjemahan wujud. Kesilapan itu kekal kerana status terowong ialah UP dan instans EC2 dalam subnet yang sama mencapai internet tanpa masalah. Kedua-dua pemerhatian itu tidak menguji arah yang rosak.

Dalam amalan paket tiba dengan alamat sumber dari rangkaian on-premises dan tidak menemui hop seterusnya yang disokong untuk menterjemahkannya. Bergantung pada jadual, ia digugurkan di sempadan keluar, dan kerana terowong kekal UP sementara instans dalam subnet yang sama masih mencapai internet, kegagalan dilaporkan sebagai masalah firewall di premis.

Virtual private gateway lwn transit gateway

Virtual private gateway milik satu VPC. Ia menamatkan VPN, memasang laluan ke dalam jadual laluan VPC itu, dan berhenti di situ. Ia tidak mempunyai model attachment, jadi ia tidak boleh menyerahkan trafik kepada VPC lain atau segmen keluar berkongsi. Skop satu VPC itulah keseluruhan hadnya, dan tiada laluan yang anda tambah dalam VPC mengubahnya.

Transit gateway ialah hab serantau tempat VPN, setiap VPC spoke dan VPC perkhidmatan berkongsi muncul sebagai attachment. Ia mempunyai jadual laluannya sendiri, yang memilih attachment mana yang menerima prefix tertentu.

Hab itulah yang menjadikan keluar berpusat mungkin: VPN mendarat sebagai satu attachment, VPC keluar sebagai satu lagi, dan jadual laluan transit gateway menghantar prefix menuju internet daripada yang pertama ke yang kedua. Dengan virtual private gateway tiada attachment kedua untuk dihantar apa-apa, sebab itu reka bentuk tidak boleh ditampal kemudian.

Laluan keluar yang disokong, hop demi hop

Reka bentuk rujukan mempunyai lima hop dan setiap anak panah ialah keputusan penghalaan yang mesti anda konfigurasikan. Trafik keluar dari rangkaian on-premises ke attachment Site-to-Site VPN, jadual laluan transit gateway memajukannya ke attachment VPC keluar, tempat jadual subnet menghantarnya ke NAT gateway awam. NAT gateway menterjemah 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 butiran menentukan sama ada hop terakhir berfungsi. NAT gateway mesti awam, dengan elastic IP dan laluan ke internet gateway, kerana NAT gateway peribadi menterjemah antara rangkaian dan tidak pernah menjadi jalan keluar internet.

Rancang satu NAT gateway bagi setiap Availability Zone yang anda mahu layan, dengan setiap jadual subnet menunjuk ke yang setempat. Simpan jadual transit gateway dan jadual VPC sebagai objek berasingan dalam nota anda, kerana satu memilih attachment dan satu lagi memilih sumber dalam VPC. Laluan lalai hanya dalam satu daripadanya membiarkan separuh laluan tidak ditakrifkan dan menghasilkan kegagalan separa yang paling sukar dikaitkan.

Laluan balik ialah tempat reka bentuk ini gagal

NAT gateway menyimpan keadaan untuk aliran yang telah dilihatnya, jadi balasan kepada sambungan keluar kembali tanpa peraturan masuk baharu. Sifat itu tidak menerbitkan perkhidmatan on-premises ke internet, dan memperlakukannya seolah-olah begitu ialah cara pasukan menghabiskan sehari menyahpepijat sambungan yang tidak akan pernah terbentuk. Untuk trafik yang dimulakan klien, empat laluan mesti bersetuju: dasar on-premises, jadual transit gateway, jadual subnet keluar dan jadual subnet NAT. Terlepas yang terakhir dan permintaan meninggalkan bangunan manakala balasannya mati di dalam AWS.

Sahkan dengan klien sebenar di belakang VPN dan periksa alamat sumber awam yang dipaparkannya. Jika itu elastic IP NAT gateway, terjemahan berlaku; jika yang lain, anda mengukur keluar yang berbeza.

Versi tidak simetri bagi kegagalan ini wajar dikenali awal. Apabila jadual subnet NAT satu Availability Zone mempunyai laluan balik ke prefix klien dan yang lain tidak, sambungan baharu berjaya atau gagal bergantung pada zon tempat aliran mendarat, dan corak itu tersalah baca sebagai internet tidak stabil. Bandingkan jadual subnet bagi setiap zon yang anda layan dan bukan membaiki zon tempat tiket dibuka, kerana laluan yang hilang itulah keseluruhan kesalahan dan tiada apa perlu diubah di sebelah sana.

Bila proxy eksplisit ialah reka bentuk yang lebih baik

Proxy HTTP pada instans dalam VPC keluar ialah alternatif sah dan selalunya lebih murah. Klien dikonfigurasikan untuk menggunakannya, proxy membuka sambungannya sendiri ke luar, dan laluan balik menjadi masalahnya dan bukan teka-teki penghalaan simetri. Bagi beberapa aplikasi ini menghapuskan sebahagian besar kerja transit gateway. Ia juga memberi log setiap pengguna yang NAT gateway tidak dapat hasilkan.

Namun ia tidak telus. Apa-apa yang mengabaikan tetapan proxy, dan setiap protokol yang bukan HTTP, tidak akan mengikut laluan itu.

Pilihan bergantung pada apa yang sebenarnya dituturkan aplikasi anda dan berapa banyak identiti yang anda perlukan dalam log. Di tempat mereka menuturkan HTTP, proxy mendapat tempatnya; di tempat anda perlukan keluar umum untuk protokol sewenang-wenangnya, reka bentuk transit gateway ialah yang disokong AWS. Memutuskannya lebih awal lebih murah daripada menemuinya selepas jadual laluan dibina.