AWS Client VPN terhubung, tetapi EC2 tetap tidak merespons

Laptop saya menampilkan terhubung. Klien AWS Client VPN menunjukkan status hijaunya, endpoint mencatat sesi, dan tetap saja saya tidak bisa membuka port MongoDB pada instance EC2 di subnet privat. Tidak ada yang tampak rusak: sertifikatnya valid, profilnya berasal dari konsol, dan terowongannya membawa lalu lintas. Kesalahannya milik saya, karena saya membaca terhubung sebagai diizinkan.

Login menjawab tepat satu pertanyaan: bolehkah identitas ini membentuk sesi? Semua setelah itu diputuskan oleh aturan terpisah yang tidak pernah melihat sertifikat Anda. Sesi yang terautentikasi dan paket yang tiba adalah dua keberhasilan yang berbeda, dan celah di antara keduanya adalah tempat sebagian besar laporan bertipe VPN-nya hidup tetapi host tidak terjangkau.

Pemeriksaan di bawah ini adalah urutan yang saya pakai sekarang.

Apa yang sebenarnya dibuktikan sesi terhubung

Selama handshake, endpoint memvalidasi sertifikat klien terhadap trust store-nya, atau mengalihkan browser ke penyedia identitas Anda saat SAML dikonfigurasi. Jika itu lolos, klien menerima alamat dari CIDR klien endpoint dan konsol menampilkan koneksi aktif. Pada titik mana pun dalam pertukaran itu, tidak ada yang bertanya apakah Anda boleh mencapai 10.0.4.17 pada port 27017.

Izin untuk tujuan adalah objek terpisah di endpoint. Setiap aliran dicocokkan dengan aturan otorisasi, dan masing-masing memasangkan CIDR tujuan dengan grup yang diberi aturan itu. Ketika tidak ada aturan yang mencakup tujuan, endpoint menerima sesi dan membuang lalu lintasnya. Tidak ada spanduk, tidak ada loop penyambungan ulang, dan tidak ada apa pun di antarmuka klien yang mengatakan ditolak.

Bandingkan aturan otorisasi dengan sumber daya, bukan dengan VPC

Daftarkan aturannya dan letakkan di samping alamat yang benar-benar dimiliki instance:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Keluarannya menunjukkan CIDR tujuan dan ID grup per aturan. Ada dua kegagalan tersembunyi di dalamnya. Aturan bisa mengizinkan 10.0.0.0/16 sementara instance berada di VPC yang di-peer pada 10.1.0.0/16; rute peering ada, tetapi tidak ada yang menulis aturan otorisasi untuk rentang kedua. Atau aturannya menunjuk grup direktori yang diikuti pengguna di direktori tetapi bukan di grup yang dievaluasi endpoint.

Tulis aturan tersempit yang mencakup tujuan, dan tambahkan aturan kedua hanya ketika CIDR kedua benar-benar diperlukan. Aturan lebar 0.0.0.0/0 dari mulai cepat memang berfungsi, dan itulah sebabnya aturan itu bertahan sampai produksi dan menyembunyikan modelnya.

Dua tabel rute menentukan apakah paket bergerak

Rute endpoint memetakan CIDR tujuan ke salah satu subnet yang terkait dengan endpoint. Itu baru separuh jalur. Tabel rute subnet itu sendiri masih harus tahu cara meneruskan paket, dan itu penting pada saat tujuan berada di balik koneksi peering, transit gateway, atau rentang on-premises yang dapat dijangkau lewat terowongan site-to-site.

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Cari rute yang tujuannya cocok dengan CIDR sumber daya dan targetnya adalah subnet terkait. Jika rutenya tidak ada, tambahkan. Jika ada dan host tetap diam, celahnya ada di sisi VPC, jadi bandingkan dengan tabel rute subnet asosiasi.

Satu pengaturan di sisi klien merusak perutean tanpa merusak terowongan: profil yang berisi route-nopull. Direktif itu memberi tahu klien berbasis OpenVPN untuk mengabaikan rute yang didorong server, sehingga antarmuka naik hanya dengan alamat endpoint itu sendiri dan tujuan sama sekali tidak punya rute. Periksa dengan ip route show di Linux atau netstat -rn di macOS apakah ada rute lewat antarmuka tun. Jika tidak ada, hapus route-nopull dari profil yang diekspor dan sambungkan ulang agar rute yang didorong diterapkan.

Grup keamanan tidak melihat alamat klien Anda

Inilah bagian yang saya salah pahami selama satu sore. Untuk endpoint IPv4 yang terkait dengan subnet, layanan menerjemahkan alamat sumber klien menjadi alamat antarmuka jaringan endpoint di subnet itu. Paket yang tiba di instance tidak membawa alamat yang ditampilkan klien Anda, jadi aturan grup keamanan yang mengizinkan kumpulan klien, misalnya 172.16.0.0/22, tidak cocok dengan apa pun.

Izinkan port dari grup keamanan endpoint, yang terpasang pada antarmuka asosiasi, bukan dari CIDR klien. Merujuk grup lebih tahan lama daripada menulis alamat secara keras, karena alamat antarmuka bukan milik Anda untuk dikendalikan. ACL jaringan bersifat tanpa status, jadi di tempat ada entri khusus, arah masuk dan arah keluar keduanya harus mengizinkan aliran.

Sambungkan juga ke alamat privat instance. IP publik membawa paket keluar dari VPC dan masuk kembali lewat jalur lain dengan aturan lain, jadi uji lewat alamat publik tidak mengatakan apa pun tentang jalur privat.

Urutan isolasi yang berhenti pada kegagalan pertama

Kerjakan ini berurutan dan berhenti di tempat salah satunya gagal. Setiap langkah menyingkirkan satu lapisan, bukan semuanya.

1. Pastikan identitas mana yang dipakai sesi dan grup mana yang dievaluasi endpoint. Sertifikat dari satu trust store bukan prinsipal yang sama dengan pernyataan SAML dari direktori.
2. Pastikan aturan otorisasi mencakup CIDR sumber daya untuk grup itu.
3. Pastikan rute endpoint ada dan menargetkan subnet terkait, lalu pastikan tabel rute subnet dapat meneruskan lebih jauh.
4. Pastikan grup keamanan mengizinkan port dari antarmuka endpoint, bukan dari kumpulan klien.
5. Uji dari dalam VPC, dengan sesi SSM pada instance lain di subnet yang sama, untuk memisahkan masalah aplikasi dari masalah jalur klien.

Ketika langkah-langkahnya tidak menentukan, tabel ini yang saya andalkan:

Dua detail akun menghasilkan gejala yang tampak seperti kegagalan izin. Setiap pengguna memerlukan sertifikat klien yang berbeda; berbagi satu sertifikat di dua mesin membuat sesi saling menggeser, dan hasilnya loop penyambungan ulang, bukan penolakan. Saat endpoint baru dibuat, konsol menampilkan nama DNS yang oleh sebagian versi klien hanya diterima dengan awalan acak yang ditampilkan di halaman endpoint, jadi salin nama lengkapnya alih-alih menyusunnya ulang.

Jika langkah kelima membuat Anda macet, tarik log koneksi endpoint dan baca entri otorisasi sebelum mengubah apa pun. Log itu menyebutkan tujuan yang diperiksa dan aturan yang cocok atau tidak cocok, dan itu memadatkan pertanyaan empat lapis menjadi satu jawaban.