IP sumber mana yang dipakai gateway NAT AWS menuju VPN?

Anda membuka konsol VPC karena mitra bertanya rentang sumber mana yang akan tiba melalui VPN situs-ke-situs. Halaman gateway NAT menampilkan gateway publik dengan Elastic IP terlampir, dan godaannya adalah mengirim alamat itu lalu melanjutkan. Itu jawaban yang benar untuk jalur internet dan jawaban yang salah untuk jalur VPN, dan bedanya adalah gateway mana yang ditunjuk tabel rute. Telusuri rutenya sebelum menulis daftar izin.

Mulai dari halaman gateway NAT, bukan dari daftar izin

Halaman gateway NAT memberi tahu subnet, jenis, dan Elastic IP, dan ketiga kolom itu cukup untuk memulai. Yang tidak diberitahukannya adalah jalur yang diambil lalu lintas setelahnya. Itu berasal dari tabel rute yang terpasang pada subnet gateway NAT.

Baca jenisnya lebih dulu, karena publik atau privat menentukan apakah gateway internet akan muncul kemudian dalam rantai. Lalu baca subnetnya, karena di situlah rute kedua berada.

Ikuti kedua penerjemahan

Baik gateway NAT publik maupun privat menerjemahkan sumber IPv4 privat beban kerja ke alamat IPv4 privat gateway NAT itu sendiri. Penerjemahan pertama itu terjadi apa pun jenisnya. Penerjemahan kedua adalah yang dilupakan orang: gateway NAT publik menyerahkan lalu lintas ke gateway internet, yang memetakan alamat ke Elastic IP yang terlampir.

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

Pada jalur privat tidak ada gateway internet dalam rantai. Ketika lalu lintas keluar melalui gateway transit atau gateway privat virtual, panduan gateway NAT mendokumentasikan alamat privat gateway NAT sebagai sumber yang diterima sisi jauh. Alamat itulah yang harus diizinkan mitra, bukan Elastic IP.

Jalur VPN biasanya menampilkan alamat privat

Untuk beban kerja di 10.20.1.0/24 yang mencapai prefiks mitra, tabel rute subnet beban kerja menunjuk gateway NAT, dan tabel rute subnet gateway NAT menunjuk jalur gateway privat. Kedua lompatan itu penting, dan hanya yang kedua menentukan apa yang dilihat mitra. Jika subnet NAT tidak punya rute ke jalur VPN, paketnya tidak pernah tiba, dan itu kegagalan yang berbeda dari alamat sumber yang salah.

Verifikasi rute kedua itu sebelum membahas alamat sama sekali. Rute yang hilang dan sumber yang salah dilaporkan terlihat sama persis bagi mitra yang memang tidak melihat lalu lintas.

Ketika penerjemahan kedua mengubah jawabannya

AWS juga menawarkan pemetaan NAT satu-ke-satu yang eksplisit dan cocok pada lampiran gateway transit. Pemetaan itu dapat menerjemahkan sumber sekali lagi sebelum layanan jauh melihatnya, dan itu bukan perilaku bawaan yang hanya merutekan. Karena harus dikonfigurasi dengan sengaja, perlakukan itu sebagai pengecualian desain dan bukan sesuatu yang Anda warisi tanpa sengaja. Jika tidak ada orang di tim Anda yang ingat menyalakannya, anggap tidak ada sampai Anda membaca lampirannya.

Jika desain Anda memakainya, daftar izin harus menggambarkan pemetaan akhir dan bukan alamat gateway NAT. Kehati-hatian yang sama berlaku untuk jalur ketersediaan: ketika beberapa alamat gateway ikut serta, kumpulan sumber yang diharapkan adalah gabungan, bukan satu alamat perwakilan. Catat alamat mana milik penerjemahan yang mana, karena daftar tanpa asal-usul mustahil diaudit nanti.

Gateway NAT privat tidak bisa diberi layanan internet dengan mengarahkannya ke gateway internet; AWS mendokumentasikan bahwa lalu lintas seperti itu dibuang. Pilih jenisnya dari jalur lengkap, bukan dari kata VPN dalam persyaratan.

Tulis kontrak yang bisa dijalankan mitra Anda

Kontrak yang berguna punya empat bagian: arah dari mana aliran dimulai, identitas terterjemah yang akan dilihat mitra, rute kembali untuk identitas itu, dan cakupan perlindungan yang berlaku. Aliran gateway NAT dimulai dari sisi sumber yang didukung, jadi ini bukan layanan penerusan port masuk untuk memaparkan beban kerja privat. Mengatakannya dengan lantang lebih awal mencegah tinjauan desain di mana tiap pihak mengira pihak lain yang memulai.

Penerjemahan membeli kelegaan dari tumpang tindih alamat dan kebijakan sumber yang dapat diprediksi, dan itu membuat Anda kehilangan identitas beban kerja individual di log mitra. Jika audit memerlukan atribusi per beban kerja, simpan identitas itu di lapisan aplikasi daripada mencoba memulihkannya dari alamat sumber yang diterjemahkan.

Lalu periksa ulang kedua tabel rute setelah setiap perubahan, karena lampiran baru atau subnet yang dipasangkan ulang secara diam-diam menulis ulang jawabannya.