Elastic IP EC2 bukan alamat VPN privat instans

Instans memiliki alamat privat, Elastic IP dikaitkan dengannya, dan rute untuk /32 publik itu ditambahkan ke VPN dengan harapan keduanya menjadi hal yang sama. Tidak. Elastic IP adalah penerjemahan yang dilakukan di luar tamu, oleh gateway internet, pada lalu lintas yang menempuh jalur internet. Sistem operasi tamu tidak pernah melihat alamat itu terkonfigurasi pada antarmuka. Menambahkannya ke antarmuka terowongan tidak mereproduksi penerjemahan di hulu dan menciptakan identitas kedua yang bertentangan untuk mesin yang sama.

Dua alamat, satu instans

Antarmuka jaringan instans menyimpan alamat privat di dalam VPC, dan itulah alamat yang diketahui tamu. Elastic IP dikaitkan dengan antarmuka yang sama tetapi berada di sisi publik pemetaan.

Apa pun yang mencapai instans melalui internet tiba dalam keadaan diterjemahkan ke alamat privat. Apa pun yang dikirim instans ke internet keluar dengan Elastic IP sebagai sumber, sekali lagi karena penerjemahan itu.

Di dalam tamu ada satu alamat. Di luar ada dua. Asimetri itu menjelaskan sebagian besar kebingungan di bidang ini. Tamu tidak dapat mengonfigurasi apa yang diterjemahkan gateway. Ia hanya dapat menjawab pada alamat yang benar-benar dimilikinya.

Apa yang sebenarnya dilakukan gateway internet

Dokumentasi AWS tentang gateway internet menjelaskan susunannya: instans mengetahui alamat IPv4 privatnya, dan gateway menyediakan penerjemahan IPv4 publik atau Elastic IP yang sesuai untuk lalu lintas pada jalur internet.

Itu penerjemahan alamat jaringan, bukan alias. Pemetaan dipelihara oleh gateway, terikat pada asosiasi, dan hanya berlaku untuk paket yang melewatinya. Hapus asosiasi dan identitas publik menghilang tanpa tamu menyadari apa pun.

Itulah sebabnya paket VPN privat yang dialamatkan ke /32 publik tidak ditafsirkan ulang sebagai paket privat ke alamat lokal tamu. Paket mengikuti rute yang cocok, yang mengirimnya ke gateway internet, dan perilaku gateway bergantung pada apakah jalur itu diizinkan di kedua arah.

Mengapa trik antarmuka terowongan gagal

Menetapkan Elastic IP ke antarmuka terowongan meminta tamu memperlakukan alamat publik sebagai lokal. Kini dua hal mengklaim alamat yang sama: penerjemahan gateway pada jalur internet dan antarmuka lokal di dalam terowongan. Lalu lintas balasan tidak memiliki jawaban konsisten tentang mana yang berlaku.

Bahkan ketika tampak berhasil, desainnya telah menyembunyikan pertanyaan sebenarnya. Klien entah mencapai alamat privat melalui terowongan atau mencapai titik akhir publik melalui internet, dan kedua jalur memiliki grup keamanan berbeda, pencatatan berbeda, dan mode kegagalan berbeda.

Alamatnya tidak pernah menjadi masalah. Pemilihan jalurnya yang menjadi masalah.

Tiga tujuan, tiga desain

Jika tujuannya titik akhir VPN publik, Elastic IP adalah alat yang tepat: rekan jarak jauh terhubung ke sana melalui internet dan transport terenkripsi berakhir di instans. Lalu lintas aplikasi internal kemudian menggunakan alamat privat.

Jika tujuannya akses privat ke aplikasi, tujuannya adalah alamat privat atau nama DNS privat yang mengarah ke sana, dan rute VPN, grup keamanan, serta jalur balik harus semuanya sepakat. Elastic IP sama sekali tidak muncul dalam desain itu.

Jika tujuannya identitas keluar publik yang stabil bagi pengguna VPN, itu desain NAT di sisi keluar, bukan alamat pada terowongan klien. Tiga tujuan yang terdengar mirip menghasilkan tiga diagram berbeda, dan hanya satu yang melibatkan penempatan Elastic IP di tempat baru.

Verifikasi jalur yang Anda pilih

Untuk akses privat, pastikan rute VPN mencakup prefiks privat, tabel rute VPC mengembalikan lalu lintas ke terowongan, grup keamanan mengizinkan sumber klien, dan firewall klien sendiri mengizinkan balasannya. Lalu uji satu permintaan nyata alih-alih ping.

Untuk akses publik, pastikan keluar internet klien, perutean entri publik, dan kebijakan keamanannya. Apakah klien VPN dapat mencapai titik akhir publik melalui terowongan bergantung pada aturan keluar dan firewall terowongan, bukan pada asosiasi Elastic IP.

Jika nama host publik harus berfungsi dari kedua sisi, gunakan desain DNS yang menjawab dengan alamat privat untuk klien VPN dan alamat publik untuk semua orang lain, dan jaga sertifikat tetap valid untuk nama, bukan untuk alamat. Urutan kerja: beri nama tujuannya, pilih alamat yang termasuk di dalamnya, lalu verifikasi rute, kebijakan, dan satu permintaan.