Dua orang bertanya soalan yang sama tentang AWS Client VPN dan SAML, dan mendapat jawapan yang bertentangan. Seorang log masuk dari komputer riba Ubuntu setiap pagi; seorang lagi mempunyai telefon, profil yang dimuat turun dan klien yang menolak satu baris di dalamnya. Perbezaannya bukan nasib dan bukan suis tersembunyi dalam papan pemuka. Semuanya bergantung pada tiga syarat: sama ada platform itu salah satu yang disokong AWS untuk kliennya sendiri, sama ada alat di tangan anda boleh melakukan pertukaran pelayar bergabung, dan sama ada titik akhir dikonfigurasikan untuk SAML. Tertinggal salah satu daripada tiga dan log masuk akan terhenti di tempat lain.

Tiga syarat menentukan sama ada log masuk boleh selesai

Platform dahulu. AWS membekalkan klien Client VPN sendiri untuk Windows, macOS dan Ubuntu pada AMD64, dan pada akhir Oktober 2026 halaman keperluan Linux menyebut Ubuntu 22.04, 24.04 dan 26.04. Binaan yang dibungkus semula, pakej yang ditukar atau pengedaran lain mungkin berfungsi, tetapi ia bukan platform yang disokong, dan apabila ia rosak, anda ialah barisan sokongan.

Klien kedua. Log masuk bergabung bukan pilihan profil yang dihuraikan oleh setiap aplikasi serasi OpenVPN. Klien yang dibekalkan membuka penyedia identiti anda dalam pelayar, menerima respons pengesahan yang ditandatangani dan menghantar respons itu ke titik akhir. Aplikasi yang hanya membaca profil dan membina terowong tidak melakukan langkah ini, sesuci mana pun log sambungannya kelihatan.

Titik akhir ketiga. Titik akhir yang menggunakan kelayakan Active Directory atau sijil bersama mempunyai susunan yang sama sekali berbeza, dan menukar klien tidak akan mengubahnya. Sahkan mod pengesahan dengan pihak yang mengeluarkan profil sebelum anda menyahpepijat apa-apa lagi.

Diambil bersama, tiga syarat memberikan jadual keputusan yang pendek:

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 import OpenVPN berhenti pada auth-federate

Profil AWS Client VPN yang dieksport membawa arahan yang memberitahu klien bahawa pengesahan berlaku di luar terowong, melalui persekutuan. Klien OpenVPN generik sama ada menolak baris itu terus atau mengabaikannya dan kemudian tidak mempunyai kelayakan untuk ditawarkan. Di sinilah kebanyakan percubaan Android berakhir: profil diimport, aplikasi membantah, atau sambungan mati dengan ralat konfigurasi sebelum satu paket pun meninggalkan peranti.

Memadam auth-federate ialah langkah seterusnya yang menggoda, dan ia mengubah kegagalan yang jelas menjadi mengelirukan. Membuang arahan tidak menukar titik akhir SAML menjadi pengesahan nama pengguna dan kata laluan. Titik akhir masih menjangka respons SAML yang ditandatangani dan menolak apa yang klien hantar sebagai gantinya. Kata laluan akaun anda, profil yang dimuat turun dan penegasan yang disalin bukan kelayakan yang boleh ditukar ganti.

Log masuk ke penyedia identiti dalam Chrome pada telefon hanya membuktikan bahawa penyedia identiti menerima pengguna. Ia tidak mengatakan apa-apa tentang sama ada respons itu sampai kepada klien yang boleh menghantarnya kembali ke titik akhir. Keperluan pengesahan bergabung menjadikan klien yang dibekalkan sebahagian daripada aliran itu semata-mata kerana sebab itu: langkah pelayar itu perlu dan tidak mencukupi.

Bagaimana rupa laluan desktop Linux yang disokong

Pasang pakej yang diterbitkan AWS untuk Ubuntu AMD64 dengan pengurus pakej sistem anda, kemudian buka sambungan dari klien itu dan bukan mengimport profil ke aplikasi VPN serba guna. Gunakan profil yang dieksport pentadbir anda untuk titik akhir ini; jangan ganti URL panggil balik atau pengecam klien daripada panduan lama, walaupun klien menerimanya.

Mulakan sambungan, lengkapkan log masuk dan sebarang gesaan MFA dalam pelayar yang terbuka, dan biarkan aliran balik dari pelayar ke klien selesai. Kemudian minta alamat persendirian yang benar-benar anda perlukan, sekali lagi. Halaman yang mengumumkan log masuk berjaya bukan bukti bahawa terowong telah naik.

Klien Linux menempah port TCP tempatan 8096 hingga 8115 untuk respons SAML. Apabila penyerahan tergantung selepas penyedia identiti menerima anda, lihat apa yang sudah mendengar dalam julat itu:

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

Port yang diduduki, atau perisian keselamatan titik akhir yang menyekat pendengar gelung balik, menghasilkan log masuk yang kelihatan selesai dan kemudian tidak pernah bersambung. Kekalkan julat itu setempat. Ia laluan balik di sebelah klien, bukan sesuatu untuk dibuka dalam kumpulan keselamatan EC2 atau peraturan tembok api get laluan, dan membukanya ke internet menambah pendedahan tanpa membaiki apa-apa.

Baca peringkat yang gagal sebelum mengubah apa-apa

Menyalahkan klien ialah refleks biasa, tetapi setiap titik kegagalan milik pemilik yang berbeza. Tentukan dahulu di mana anda sebenarnya.

  • Tiada tetingkap pelayar terbuka. Semak mod pengesahan profil, sambungan yang anda pilih dan integrasi dengan pelayar lalai desktop.
  • Penyedia identiti menolak akaun. Penetapan akaun, pendaftaran MFA atau konfigurasi aplikasi SAML, semuanya wilayah pentadbir.
  • Pelayar selesai tetapi klien tidak pernah bersambung. Respons pengesahan yang tamat tempoh atau tidak boleh digunakan, port balik yang disekat atau penyerahan yang gagal.
  • Terowong sudah naik tetapi aplikasi tidak dapat dicapai. Laluan titik akhir, peraturan kebenaran, kumpulan keselamatan, DNS. Mengulang log masuk pelayar tidak boleh menambah kebenaran rangkaian yang hilang.

Simpan teks ralat klien dan masa percubaan apabila anda meningkat. Kenyataan bahawa SAML rosak dan kenyataan bahawa klien tidak pernah menerima respons pengesahan yang sah menghantar orang ke tempat yang sangat berbeza.

Apabila keperluan itu tetap Android

Android bukan platform yang kliennya diterbitkan AWS, jadi jawapan jujurnya ialah tiada klien mudah alih yang disokong untuk dipasang. Itu kekangan reka bentuk, bukan teka-teki untuk diselesaikan pada telefon dengan menyunting profil sehingga sesuatu bersambung.

Apa yang boleh berubah ialah reka bentuk akses di belakangnya, dan keputusan itu milik pentadbir: laluan akses aplikasi yang diluluskan ke satu perkhidmatan dalaman yang diperlukan telefon, produk VPN yang menyokong mudah alih dan sudah dikendalikan organisasi, atau desktop yang disokong untuk titik akhir yang hanya menggunakan SAML. Setiap pilihan membawa konfigurasi titik akhir, pendaftaran identiti dan peraturan kebenarannya sendiri, dan tiada satu pun boleh dicipta pengguna daripada profil yang dimuat turun.

Alat pihak ketiga yang mendakwa menutup jurang itu memerlukan semakan sokongan dan keselamatan yang jelas merangkumi MFA, pengendalian respons, dasar peranti dan kadar kemas kini. Kewujudannya tidak menjadikannya klien Android yang dibekalkan AWS, dan anda tidak sepatutnya memindahkan bahan pengesahan yang boleh digunakan semula ke telefon supaya salah satunya berfungsi.

Berikan tiga fakta kepada pentadbir dan bukan urutan panjang tentang arahan: mod pengesahan titik akhir, sumber persendirian yang perlu dicapai telefon, dan tarikh akhir. Itu cukup untuk memilih antara desktop, laluan akses aplikasi dan produk VPN baharu.

Semak syarat mengikut urutan sebelum membuka tiket lain: platform dalam senarai klien yang dibekalkan, alat yang boleh melengkapkan pertukaran pelayar, titik akhir yang benar-benar dikonfigurasikan untuk persekutuan dan, pada Linux, julat port gelung balik. Item pertama yang gagal ialah yang perlu dibaiki. Segala-galanya selepas itu ialah tekaan.

Artikel berkaitan