CIDR klien AWS Client VPN tidak boleh tumpang tindih dengan rentang VPC

Endpoint AWS Client VPN membagikan alamat klien dari pool yang Anda pilih, dan AWS memeriksa pool itu terhadap jaringan tujuan sebelum membuat endpoint. Pemeriksaannya bukan apakah subnet tampak kosong. Pemeriksaannya adalah apakah pool tumpang tindih dengan rentang VPC, dan jawabannya sama baik sebuah instans EC2 memakai alamat itu hari ini maupun tidak. Tumpang tindih adalah soal rentang, bukan soal alokasi.

Jalankan lima pemeriksaan secara berurutan. Berhenti pada yang pertama gagal, karena tidak ada langkah berikutnya yang dapat memperbaiki keputusan sebelumnya.

Tumpang tindih adalah uji rentang, bukan uji alamat bebas

Mulai dari CIDR VPC, bukan dari subnet yang hendak Anda kaitkan. Pool 172.20.0.0/22 berada di dalam VPC 172.20.0.0/16 dan ditolak meskipun tidak ada subnet yang menempatinya, karena tumpang tindih adalah sifat rentang, bukan sifat alokasi saat ini. Lalu tambahkan tujuan yang dirutekan endpoint: VPC peer, transit gateway, dan rentang lokal lewat koneksi site-to-site. Rentang apa pun yang mungkin perlu dijangkau klien masuk ke daftar.

Kumpulkan dari akun, bukan dari ingatan: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock", ditambah entri tabel rute untuk subnet yang hendak Anda kaitkan.

Ukuran pool ditentukan sebelum Anda membangun

AWS menerima pool klien IPv4 antara /22 dan /12 pada Client VPN. /24 terlalu kecil, /8 di luar rentang terdokumentasi, dan kedua kesalahan itu berasal dari mengukur pool seperti subnet beban kerja. Ukurlah berdasarkan perkiraan klien bersamaan ditambah cadangan, lalu bulatkan ke prefiks yang diizinkan.

Periksa aritmetikanya sebelum mengetikkannya ke konsol, karena prefiks yang salah ketik mengubah ukuran pool tanpa peringatan apa pun:

python3 -c "import ipaddress; p=ipaddress.ip_network('172.16.0.0/22'); print(p.num_addresses, p.prefixlen, p.overlaps(ipaddress.ip_network('172.20.0.0/16')))"

Itu mencetak jumlah alamat, panjang prefiks, dan apakah kandidat bertabrakan dengan rentang VPC, yang lebih cepat daripada memikirkan netmask di akhir jendela perubahan.

Resolver punya peran alamatnya sendiri

Resolver VPC menjawab pada alamat dasar rentang VPC ditambah dua, yang belum tentu berada di dalam subnet yang Anda kaitkan. Menganggap resolver harus berada di pool klien, atau membangun subnet di sekitar alamat itu, menambah objek tanpa mengubah apa pun. Yang penting adalah endpoint membawa pengaturan DNS yang dapat diterapkan klien dan resolver dapat dijangkau dari tunnel.

Catat resolver, pool klien, dan subnet terkait sebagai tiga butir terpisah dalam rencana alamat. Ketiganya gagal secara independen, dan benarnya satu tidak mengatakan apa pun tentang dua lainnya.

Empat bidang yang Anda tetapkan saat pembuatan

CIDR IPv4 klien ditetapkan saat pembuatan. Mengganti server DNS, menambah asosiasi, menukar grup keamanan, menyunting aturan otorisasi, atau mengubah rute split-tunnel semuanya suntingan biasa, dan tidak satu pun mengganti nama pool. Asimetri itulah alasan ini layak ditinjau: pengaturan murah adalah yang ingin Anda ubah nanti, dan yang mahal adalah yang Anda tetapkan lebih dulu. Baca deskripsi endpoint sebelum merencanakan jendela perubahan.

Periksa endpoint yang sudah diterapkan sebelum menganggap perlu membangun ulang. aws ec2 describe-client-vpn-endpoints mengembalikan pool, DNS, penanda split-tunnel, dan asosiasi dalam satu respons, yang biasanya cukup untuk menyingkirkan pembangunan ulang.

Ganti endpoint daripada menambalnya

Endpoint baru adalah endpoint baru, bukan migrasi. Sesi yang ada tidak berpindah ke sana, profil klien menunjuk ke nama lain, dan setiap pengaturan yang Anda anggap biasa harus dibuat ulang: sertifikat server, autentikasi, asosiasi, rute, grup otorisasi, pencatatan log. Validasi dengan satu klien terhadap layanan privat yang wajib dan terhadap tujuan yang harus ditolak, lalu perluas akses. Apa pun yang Anda lewati akan menjadi tiket dukungan nanti.

Biarkan endpoint lama tetap berjalan sampai validasi itu lolos, dan pertahankan jalur administratif yang tidak bergantung pada yang baru.

Satu batas yang perlu disebut: ini mencakup pool klien IPv4. Pengaturan lalu lintas dual-stack dan IPv6 pada Client VPN mengikuti model pengalamatan sendiri, jadi jangan menyalin daftar ini tanpa membaca dokumentasi untuk mode tersebut.