Dua orang mengajukan pertanyaan yang sama tentang AWS Client VPN dan SAML, dan mendapat jawaban yang berlawanan. Yang satu masuk dari laptop Ubuntu setiap pagi; yang lain punya ponsel, profil yang diunduh, dan klien yang menolak satu baris di dalamnya. Perbedaannya bukan keberuntungan dan bukan sakelar tersembunyi di dasbor. Semuanya bergantung pada tiga syarat: apakah platformnya salah satu yang didukung AWS untuk kliennya sendiri, apakah alat di tangan Anda dapat melakukan pertukaran peramban terfederasi, dan apakah endpoint memang dikonfigurasi untuk SAML. Lewatkan salah satu dari ketiganya dan login akan berhenti di titik yang berbeda.

Tiga syarat menentukan apakah login dapat selesai

Platform yang pertama. AWS menyediakan klien Client VPN sendiri untuk Windows, macOS, dan Ubuntu di AMD64, dan pada akhir Oktober 2026 halaman persyaratan Linux menyebut Ubuntu 22.04, 24.04, dan 26.04. Build yang dikemas ulang, paket hasil konversi, atau distribusi lain mungkin berjalan, tetapi itu bukan platform yang didukung, dan ketika rusak, Anda adalah jalur dukungannya.

Klien yang kedua. Login terfederasi bukan opsi profil yang diurai setiap aplikasi yang kompatibel dengan OpenVPN. Klien yang disediakan membuka penyedia identitas Anda di peramban, menerima respons autentikasi yang ditandatangani, dan mengirimkan respons itu ke endpoint. Aplikasi yang hanya membaca profil dan membangun terowongan tidak melakukan langkah ini, sebersih apa pun log koneksinya.

Endpoint yang ketiga. Endpoint yang memakai kredensial Active Directory atau sertifikat timbal balik memiliki tatanan yang sama sekali berbeda, dan mengganti klien tidak akan mengubahnya. Pastikan mode autentikasi dengan pihak yang menerbitkan profil sebelum Anda men-debug hal lain.

Secara keseluruhan, ketiga syarat memberi tabel keputusan yang singkat:

PlatformAWS-provided clientCompletes the SAML exchangeWhat that means
Ubuntu 22.04 / 24.04 / 26.04, AMD64YesYesNormal sign-in path; debug stages, not platforms
Windows or macOSYesYesSame path, different installer
AndroidNo published clientNoNeeds a different access design, not a different profile
Other Linux distributionsNoDepends on the toolRuns at your own support risk

Mengapa impor OpenVPN berhenti di auth-federate

Profil AWS Client VPN yang diekspor membawa direktif yang memberi tahu klien bahwa autentikasi terjadi di luar terowongan, melalui federasi. Klien OpenVPN generik entah menolak baris itu mentah-mentah atau mengabaikannya dan kemudian tidak punya kredensial untuk ditawarkan. Di sinilah sebagian besar upaya Android berakhir: profil diimpor, aplikasi menolak, atau koneksi mati dengan kesalahan konfigurasi sebelum satu paket pun meninggalkan perangkat.

Menghapus auth-federate adalah langkah berikutnya yang menggoda, dan itu mengubah kegagalan yang jelas menjadi membingungkan. Menghapus direktif tidak mengubah endpoint SAML menjadi autentikasi nama pengguna dan kata sandi. Endpoint masih mengharapkan respons SAML yang ditandatangani dan menolak apa yang dikirim klien sebagai gantinya. Kata sandi akun Anda, profil yang diunduh, dan pernyataan yang disalin bukan kredensial yang dapat dipertukarkan.

Masuk ke penyedia identitas di Chrome pada ponsel hanya membuktikan bahwa penyedia identitas menerima pengguna. Itu tidak mengatakan apa pun tentang apakah respons sampai ke klien yang dapat mengirimnya kembali ke endpoint. Justru karena itulah persyaratan autentikasi terfederasi menjadikan klien yang disediakan bagian dari alur: langkah peramban itu perlu dan tidak cukup.

Bagaimana jalur desktop Linux yang didukung terlihat

Pasang paket yang diterbitkan AWS untuk Ubuntu AMD64 dengan manajer paket sistem Anda, lalu buka koneksi dari klien itu alih-alih mengimpor profil ke aplikasi VPN serbaguna. Gunakan profil yang diekspor administrator Anda untuk endpoint ini; jangan ganti URL callback atau pengenal klien dari panduan lama, meskipun klien menerimanya.

Mulai koneksi, selesaikan login dan setiap permintaan MFA di peramban yang terbuka, dan biarkan alur kembali dari peramban ke klien selesai. Lalu minta alamat privat yang benar-benar Anda butuhkan, dari awal. Halaman yang mengumumkan login berhasil bukan bukti bahwa terowongan sudah naik.

Klien Linux menyediakan port TCP lokal 8096 hingga 8115 untuk respons SAML. Ketika serah-terima menggantung setelah penyedia identitas menerima Anda, periksa apa yang sudah mendengarkan di rentang itu:

ss -ltnp | grep -E ":809[6-9]|:81(0[0-9]|1[0-5])"

Port yang terpakai, atau perangkat lunak keamanan endpoint yang memblokir pendengar loopback, menghasilkan login yang tampak selesai lalu tidak pernah terhubung. Jaga rentang itu tetap lokal. Itu jalur kembali di sisi klien, bukan sesuatu yang dibuka di grup keamanan EC2 atau aturan firewall gateway, dan membukanya ke internet menambah paparan tanpa memperbaiki apa pun.

Baca tahap yang gagal sebelum mengubah apa pun

Menyalahkan klien adalah refleks yang biasa, tetapi setiap titik kegagalan milik pemilik yang berbeda. Tentukan dulu di mana Anda sebenarnya berada.

  • Tidak ada jendela peramban yang terbuka. Periksa mode autentikasi profil, koneksi yang Anda pilih, dan integrasi dengan peramban bawaan desktop.
  • Penyedia identitas menolak akun. Penetapan akun, pendaftaran MFA, atau konfigurasi aplikasi SAML, semuanya wilayah administrator.
  • Peramban selesai tetapi klien tidak pernah terhubung. Respons autentikasi yang kedaluwarsa atau tidak terpakai, port kembali yang diblokir, atau serah-terima yang gagal.
  • Terowongan sudah naik tetapi aplikasi tidak terjangkau. Rute endpoint, aturan otorisasi, grup keamanan, DNS. Mengulang login peramban tidak dapat menambah izin jaringan yang hilang.

Simpan teks kesalahan klien dan waktu percobaan saat Anda mengeskalasi. Pernyataan bahwa SAML rusak dan pernyataan bahwa klien tidak pernah menerima respons autentikasi yang sah mengirim orang ke tempat yang sangat berbeda.

Ketika persyaratannya tetap Android

Android bukan platform yang kliennya diterbitkan AWS, jadi jawaban jujurnya adalah tidak ada klien seluler yang didukung untuk dipasang. Itu batasan desain, bukan teka-teki yang harus dipecahkan di ponsel dengan menyunting profil sampai sesuatu terhubung.

Yang bisa berubah adalah desain akses di belakangnya, dan keputusan itu milik administrator: jalur akses aplikasi yang disetujui ke satu layanan internal yang dibutuhkan ponsel, produk VPN yang mendukung seluler dan sudah dijalankan organisasi, atau desktop yang didukung untuk endpoint yang hanya memakai SAML. Setiap opsi membawa konfigurasi endpoint, pendaftaran identitas, dan aturan otorisasinya sendiri, dan tidak satu pun dapat dibuat pengguna dari profil yang diunduh.

Alat pihak ketiga yang mengklaim menutup celah itu memerlukan tinjauan dukungan dan keamanan yang eksplisit yang mencakup MFA, penanganan respons, kebijakan perangkat, dan irama pembaruan. Keberadaannya tidak menjadikannya klien Android yang disediakan AWS, dan Anda tidak boleh memindahkan materi autentikasi yang dapat dipakai ulang ke ponsel agar salah satunya berfungsi.

Berikan tiga fakta kepada administrator alih-alih utas panjang tentang direktif: mode autentikasi endpoint, sumber daya privat yang harus dicapai ponsel, dan tenggat waktunya. Itu cukup untuk memilih antara desktop, jalur akses aplikasi, dan produk VPN baru.

Periksa syarat-syaratnya secara berurutan sebelum membuka tiket lain: platform ada di daftar klien yang disediakan, alat yang dapat menyelesaikan pertukaran peramban, endpoint yang benar-benar dikonfigurasi untuk federasi, dan di Linux rentang port loopback. Butir pertama yang gagal adalah yang harus diperbaiki. Segala hal setelahnya adalah dugaan.

Artikel terkait