AWS Client VPN: login berhasil tetapi subnet tidak dapat dijangkau

Klien Anda menampilkan Connected, sertifikatnya valid, dan halaman intranet tetap berakhir dengan timeout. Selisih itu hampir tidak pernah soal autentikasi. AWS Client VPN mengotorisasi tujuan secara terpisah dari login, dan dua penyebab biasa adalah nilai grup yang tidak cocok dengan yang dikirim penyedia identitas serta aturan tujuan yang lebih spesifik yang mengalahkan aturan luas. Keduanya terlihat di konfigurasi endpoint begitu Anda tahu harus melihat ke mana.

Login berhasil; aturannya tidak cocok

Autentikasi menjawab siapa penggunanya. Aturan otorisasi menjawab prefiks jaringan mana yang boleh dijangkau identitas itu. Pengguna bisa lolos yang pertama dan gagal di yang kedua, dan klien hanya memberi Anda koneksi yang tetap hidup sementara setiap permintaan berakhir dengan timeout.

Mulailah dengan memastikan endpoint memiliki aturan otorisasi yang tujuannya memuat alamat yang gagal. Jika tidak ada aturan yang cocok, koneksi berperilaku benar; kebijakannya yang tidak ada.

Dari mana nilai grup sebenarnya berasal

Dengan Active Directory, kolom access-group memuat SID grup, bukan nama tampilannya. Dengan federasi SAML, kolom itu memuat ID atau nama grup yang benar-benar dibawa atribut grup SAML yang dikonfigurasi. Salin nilainya dari assertion atau dari pencarian direktori, bukan dari halaman wiki.

Grup IAM adalah bidang kendali yang berbeda. Izin untuk mengelola endpoint Client VPN tidak membuat grup IAM menjadi grup VPN pengguna, dan menempelkan nama grup IAM ke kolom access-group tidak menerjemahkannya menjadi SID AD atau nilai atribut SAML.

Grup dengan nama serupa di direktori lain tidak membuktikan apa pun. Periksa metode autentikasi endpoint dan keanggotaan atau assertion pengguna di sistem yang sama.

Prefiks terpanjang menang, termasuk 0.0.0.0/0

Otorisasi dievaluasi berdasarkan kecocokan prefiks terpanjang, dan aturan untuk semua tujuan dievaluasi terakhir, bukan pertama. Tambahkan aturan 10.46.0.0/16 untuk Engineering dan aturan 0.0.0.0/0 untuk semua orang, dan pengguna di luar Engineering tetap tidak bisa menjangkau 10.46.20.10 melalui aturan luas itu.

Di sinilah perbaikan bisa salah arah. Menghapus aturan sempit memulihkan akses pengguna dan juga memberikan subnet itu kepada setiap identitas yang dicakup aturan luas. Bangun matriks grup ke jaringan sebelum menghapus apa pun, dan catat grup mana yang seharusnya menjangkau rentang mana. Aturan ini hanya mengizinkan; tidak ada entri penolakan untuk memotong pengecualian dari izin yang luas.

Perubahan juga memerlukan koneksi baru agar dinilai dengan adil. Hubungkan ulang klien setelah menyunting aturan, lalu uji lagi.

Pisahkan otorisasi dari jalur data

Aturan yang cocok bukanlah rute. Endpoint memerlukan subnet terkait dan entri tabel rute untuk tujuan, dan grup keamanan sumber daya target harus menerima lalu lintasnya. Lalu lintas balasan dan DNS juga harus bekerja.

Uji pengguna yang seharusnya berhasil dan pengguna yang seharusnya tetap dikecualikan. Keduanya bisa login sementara hanya satu yang menjangkau subnet, dan perbedaan itulah bukti yang Anda inginkan.

Jika alamat IP berfungsi tetapi nama host tidak, lihat resolver sebelum menyentuh otorisasi. Jika tidak ada rute yang mencakup alamat itu, perbaiki asosiasi atau tabel rute. Jika paket tiba dan layanan menolaknya, kebijakan layanan itulah persinggahan berikutnya. Memperluas matriks otorisasi ke semua pengguna menyembunyikan lapisan mana yang sebenarnya rusak.

Sebelum menutup tiket, catat sumber identitas, nilai grup yang tepat, prefiks tujuan, dan rute yang membawa lalu lintas. Catatan itu mengubah laporan berikutnya tentang terhubung tetapi tidak punya akses menjadi perbandingan dua menit alih-alih satu putaran dugaan lagi.