Mengapa AWS Client VPN Menjatuhkan Trafik Tanpa Rute yang Cocok

Endpoint hanya meneruskan paket jika tabel rutenya mencakup tujuan. Baca rutenya, deklarasikan prefiks dengan for_each, verifikasi jalur balik.

Client VPN memberi klien sebuah alamat, handshake selesai, dan koneksi tetap tidak ke mana-mana. Sebelum menyentuh sertifikat atau versi klien, lihat tabel rute milik endpoint itu sendiri. Endpoint AWS Client VPN hanya meneruskan paket jika salah satu rutenya mencakup prefiks tujuan; jika tidak ada yang cocok, paket dibuang di endpoint dan host tujuan tidak pernah melihat SYN.

Itu keputusan penerusan, bukan keputusan autentikasi. Keputusan ini terjadi setelah tunnel naik dan setelah aturan otorisasi dievaluasi, karena itu sertifikat yang sah dan grup yang sah masih bisa menghasilkan koneksi mati.

Endpoint hanya meneruskan apa yang dicakup tabel rutenya

Setiap rute adalah CIDR tujuan ditambah subnet yang seharusnya menerima trafik. Endpoint membandingkan tujuan klien dengan daftar itu, memilih entri yang cocok, dan mengirim paket ke subnet terkait. Tanpa entri berarti tanpa hop berikutnya.

Perhatikan apa yang bukan rute. Rute bukan entri tabel rute VPC, dan tidak mengotorisasi apa pun. Aturan otorisasi menentukan apakah sebuah grup boleh mencapai tujuan; rute menentukan apakah endpoint punya tempat untuk mengirim paket. Keduanya harus sepakat, dan keduanya gagal dengan gejala berbeda, jadi menebak mana yang rusak menghabiskan satu sore.

Ketidakcocokan klasik adalah VPC yang di-peer. Seseorang menambahkan rute untuk 10.20.0.0/24 padahal host berada di 10.20.4.0/24, sehingga alamatnya jatuh di luar semua entri. Tangkapan di sisi klien menunjukkan SYN berulang tanpa balasan, dan log tujuan tidak menunjukkan apa pun.

Baca daftar rute sebelum sertifikat

Rute endpoint adalah objek tersendiri, jadi tanyakan langsung alih-alih membaca tabel VPC:

aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 --query 'Routes[].{Dest:DestinationCidr,Target:TargetSubnet,Origin:Origin}'

Ambil alamat persis dan panjang prefiks dari klien yang gagal, lalu periksa cakupan karakter demi karakter. Pencocokan prefiks terpanjang berlaku, jadi rute yang lebih lebar tidak menyelamatkan Anda ketika rute yang lebih sempit menunjuk ke tempat lain.

Satu resource per tujuan dengan for_each

Blok rute yang ditulis tangan melenceng begitu seseorang menambahkan prefiks di konsol. Simpan tujuan di dalam map dan buat satu resource per kunci, agar setiap penambahan atau penghapusan tetap terisolasi.

variable "client_vpn_routes" {
  type = map(string)
  default = {
    "10.20.0.0/16"  = "subnet-0aa11bb22cc33dd44"
    "172.31.0.0/20" = "subnet-0aa11bb22cc33dd44"
  }
}

resource "aws_ec2_client_vpn_route" "this" {
  for_each               = var.client_vpn_routes
  client_vpn_endpoint_id = var.client_vpn_endpoint_id
  destination_cidr_block = each.key
  target_vpc_subnet_id   = each.value
  depends_on             = [aws_ec2_client_vpn_network_association.this]
}

Pertahankan dependensi pada asosiasi jaringan. Rute membutuhkan subnet yang terasosiasi, jadi apply yang membuat keduanya harus mengurutkan asosiasi lebih dulu, dan tanpa referensi itu Terraform bebas mencoba rute lebih dulu. Lalu baca plan: jumlah penambahan rute harus cocok dengan prefiks yang Anda tambahkan. Jika plan juga mengganti endpoint, resource endpoint ditulis salah, dan menerapkannya memutus setiap klien yang terhubung.

Mengadopsi endpoint yang tidak Anda buat

Sebagian besar tim mewarisi endpoint yang dibangun di konsol, karena itu tidak ada kode rute. Jangan mendirikan endpoint kedua hanya untuk memasukkan rute ke Terraform.

Impor saja, atau lewatkan id sebagai variabel dan biarkan objek warisan tidak terkelola. Impor membutuhkan format pengenal yang didokumentasikan penyedia untuk setiap tipe resource, yang mengodekan endpoint, prefiks tujuan, dan subnet target. Salin string itu dari dokumentasi resource alih-alih menyusunnya dari ingatan, jalankan plan, dan harapkan tidak ada perubahan sebelum Anda menambahkan sesuatu yang baru.

Lacak paket sesuai urutan perjalanannya

Ketika rute ada dan koneksi tetap gagal, telusuri jalurnya secara berurutan alih-alih menebak di lapisan teratas.

  1. Rute: sebuah prefiks mencakup tujuan dan menunjuk ke subnet yang terasosiasi dengan endpoint.
  2. Otorisasi: aturan otorisasi mengizinkan tujuan itu untuk grup pengguna. Rute saja tidak pernah memberi akses.
  3. Jalur balik: tabel rute subnet tujuan mengirim balasan kembali ke arah endpoint, dan security group mengizinkan port dari kumpulan alamat klien.
  4. Aplikasi: buka koneksi TCP sungguhan dari klien, lalu pastikan log tujuan menunjukkan alamat sumber yang diharapkan dari kumpulan itu.

Ubah satu prefiks per apply, baca ulang daftar rute sesudahnya, dan catat tujuan, aturan yang mengotorisasi, serta jalur balik secara bersamaan. Orang berikutnya yang men-debug koneksi yang ditolak harus mulai dari inventaris itu, bukan dari teori tentang sertifikat.

Artikel terkait