AWS Client VPN bersambung, tetapi EC2 masih tidak memberi respons

Komputer riba saya menunjukkan bersambung. Klien AWS Client VPN menunjukkan keadaan hijaunya, endpoint merekodkan sesi, dan saya masih tidak dapat membuka port MongoDB pada instans EC2 dalam subnet peribadi. Tiada apa yang jelas rosak: sijil sah, profil datang dari konsol, dan terowong membawa trafik. Kesilapannya milik saya, kerana saya membaca bersambung sebagai dibenarkan.

Log masuk menjawab tepat satu soalan: bolehkah identiti ini membentuk sesi? Segala-galanya selepas itu ditentukan oleh peraturan berasingan yang tidak pernah melihat sijil anda. Sesi yang mengesahkan diri dan paket yang tiba ialah dua kejayaan berbeza, dan jurang antaranya ialah tempat kebanyakan laporan jenis VPN menyala tetapi hos tidak dapat dicapai tinggal.

Semakan di bawah ialah urutan yang saya gunakan sekarang.

Apa yang sebenarnya dibuktikan oleh sesi bersambung

Semasa handshake, endpoint mengesahkan sijil klien terhadap trust store-nya, atau mengalihkan pelayar ke penyedia identiti anda apabila SAML dikonfigurasikan. Jika itu lulus, klien menerima alamat daripada CIDR klien endpoint dan konsol menunjukkan sambungan aktif. Pada bila-bila masa dalam pertukaran itu tiada apa yang bertanya sama ada anda boleh mencapai 10.0.4.17 pada port 27017.

Kebenaran untuk sesuatu destinasi ialah objek berasingan pada endpoint. Setiap aliran dipadankan dengan peraturan kebenaran, dan setiap satu memasangkan CIDR destinasi dengan kumpulan yang diberi peraturan itu. Apabila tiada peraturan meliputi destinasi, endpoint menerima sesi dan membuang trafik. Tiada sepanduk, tiada gelung sambung semula, dan tiada apa dalam antara muka klien yang berkata ditolak.

Bandingkan peraturan kebenaran dengan sumber, bukan dengan VPC

Senaraikan peraturan itu dan letakkan di sebelah alamat yang benar-benar dimiliki instans:

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

Output menunjukkan CIDR destinasi dan ID kumpulan bagi setiap peraturan. Dua kegagalan tersembunyi di dalamnya. Peraturan mungkin membenarkan 10.0.0.0/16 sedangkan instans berada dalam VPC yang di-peer pada 10.1.0.0/16; laluan peering wujud, tetapi tiada siapa menulis peraturan kebenaran untuk julat kedua. Atau peraturan menunjuk kepada kumpulan direktori yang pengguna sertai dalam direktori tetapi bukan dalam kumpulan yang dinilai oleh endpoint.

Tulis peraturan paling sempit yang meliputi destinasi, dan tambah satu lagi hanya apabila CIDR kedua benar-benar diperlukan. Peraturan lebar 0.0.0.0/0 daripada permulaan pantas memang berfungsi, dan itulah sebabnya ia bertahan ke pengeluaran dan menyembunyikan modelnya.

Dua jadual laluan menentukan sama ada paket bergerak

Laluan endpoint memetakan CIDR destinasi kepada salah satu subnet yang dikaitkan dengan endpoint. Itu baru separuh jalan. Jadual laluan subnet itu sendiri masih perlu tahu cara memajukan paket, dan itu penting pada saat destinasi berada di sebalik sambungan peering, transit gateway atau julat on-premises yang boleh dicapai melalui terowong site-to-site.

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

Cari laluan yang destinasinya sepadan dengan CIDR sumber dan sasarannya ialah subnet berkaitan. Jika laluan tiada, tambahkannya. Jika ada dan hos masih senyap, jurangnya di sebelah VPC, jadi bandingkan dengan jadual laluan subnet persatuan itu.

Satu tetapan di sebelah klien memecahkan penghalaan tanpa memecahkan terowong: profil yang mengandungi route-nopull. Arahan itu memberitahu klien berasaskan OpenVPN supaya mengabaikan laluan yang ditolak pelayan, jadi antara muka naik hanya dengan alamat endpoint itu sendiri dan destinasi langsung tiada laluan. Semak dengan ip route show di Linux atau netstat -rn di macOS sama ada laluan melalui antara muka tun wujud. Jika tiada, buang route-nopull daripada profil yang dieksport dan sambung semula supaya laluan yang ditolak digunakan.

Kumpulan keselamatan tidak melihat alamat klien anda

Inilah bahagian yang saya salah faham sepanjang satu petang. Untuk endpoint IPv4 yang dikaitkan dengan subnet, perkhidmatan menterjemah alamat sumber klien kepada alamat antara muka rangkaian endpoint dalam subnet itu. Paket yang tiba di instans tidak membawa alamat yang ditunjukkan klien anda, jadi peraturan kumpulan keselamatan yang membenarkan kumpulan klien, katakan 172.16.0.0/22, tidak sepadan dengan apa pun.

Benarkan port daripada kumpulan keselamatan endpoint, yang dipasang pada antara muka persatuan itu, bukan daripada CIDR klien. Merujuk kumpulan lebih tahan lama daripada mengod alamat secara keras, kerana alamat antara muka bukan milik anda untuk dikawal. ACL rangkaian tidak berkeadaan, jadi di tempat ada entri tersuai, arah masuk dan arah keluar kedua-duanya perlu membenarkan aliran.

Sambung juga ke alamat peribadi instans. IP awam membawa paket keluar dari VPC dan masuk semula melalui laluan lain dengan peraturan lain, jadi ujian melalui alamat awam tidak berkata apa-apa tentang laluan peribadi.

Urutan pengasingan yang berhenti pada kegagalan pertama

Lakukan ini mengikut urutan dan berhenti di tempat salah satu gagal. Setiap langkah mengecualikan satu lapisan, bukan semuanya.

1. Pastikan identiti mana yang digunakan oleh sesi dan kumpulan mana yang dinilai oleh endpoint. Sijil daripada satu trust store bukan prinsipal yang sama dengan pernyataan SAML daripada direktori.
2. Pastikan peraturan kebenaran meliputi CIDR sumber untuk kumpulan itu.
3. Pastikan laluan endpoint wujud dan menyasarkan subnet berkaitan, kemudian pastikan jadual laluan subnet boleh memajukan lagi.
4. Pastikan kumpulan keselamatan membenarkan port daripada antara muka endpoint dan bukan daripada kumpulan klien.
5. Uji dari dalam VPC, dengan sesi SSM pada instans lain dalam subnet yang sama, untuk memisahkan masalah aplikasi daripada masalah laluan klien.

Apabila langkah-langkah tidak muktamad, jadual ini yang saya bergantung padanya:

Dua butiran akaun menghasilkan simptom yang kelihatan seperti kegagalan kebenaran. Setiap pengguna memerlukan sijil klien berasingan; berkongsi satu antara dua mesin membuat sesi saling menolak, dan hasilnya gelung sambung semula bukan penolakan. Apabila endpoint baharu dicipta, konsol menunjukkan nama DNS yang sesetengah versi klien hanya terima dengan awalan rawak yang dipaparkan pada halaman endpoint, jadi salin nama penuh dan bukan membinanya semula.

Jika langkah kelima membuat anda tersekat, tarik log sambungan endpoint dan baca entri kebenaran sebelum mengubah apa-apa. Log itu menamakan destinasi yang diperiksa dan peraturan yang sepadan atau tidak, dan itu merumuskan soalan empat lapis menjadi satu jawapan.