Du homoj demandas la saman demandon pri AWS Client VPN kaj SAML, kaj ricevas kontraŭajn respondojn. Unu ensalutas ĉiun matenon el Ubuntu tekkomputilo; la alia havas telefonon, elŝutitan profilon kaj klienton, kiu rifuzas unu linion en ĝi. La diferenco ne estas bonŝanco kaj ne kaŝita ŝaltilo en la panelo. Ĉio dependas de tri kondiĉoj: ĉu la platformo estas unu el tiuj, kiujn AWS subtenas por sia propra kliento, ĉu la ilo en via mano povas plenumi la federacian retumilan interŝanĝon, kaj ĉu la finpunkto entute estas agordita por SAML. Manku eĉ unu el la tri kaj la saluto haltas ĉe alia punkto.

Tri kondiĉoj decidas, ĉu la saluto povas finiĝi

La platformo venas unue. AWS liveras sian propran Client VPN-klienton por Windows, macOS kaj Ubuntu sur AMD64, kaj fine de oktobro 2026 la paĝo pri Linux-postuloj nomas Ubuntu 22.04, 24.04 kaj 26.04. Repakita konstruaĵo, konvertita pakaĵo aŭ alia distribuo eble funkcios, sed ĝi ne estas subtenata platformo, kaj kiam ĝi rompiĝas, vi estas la subtena linio.

La kliento venas due. Federacia saluto ne estas profila opcio, kiun ĉiu OpenVPN-kongrua aplikaĵo analizas. La provizita kliento malfermas vian identecprovizanton en retumilo, ricevas la subskribitan aŭtentikigan respondon kaj transdonas tiun respondon al la finpunkto. Aplikaĵo, kiu nur legas la profilon kaj starigas tunelon, ne plenumas ĉi tiun paŝon, kiom ajn pura aspektas ĝia konekta protokolo.

La finpunkto venas trie. Finpunkto uzanta Active Directory-akreditilojn aŭ reciprokajn atestilojn havas tute alian aranĝon, kaj ŝanĝi klientojn ne ŝanĝos ĝin. Konfirmu la aŭtentikigan reĝimon ĉe tiu, kiu eldonis la profilon, antaŭ ol vi sencimigos ion alian.

Kune prenitaj, la tri kondiĉoj donas mallongan decidtabelon:

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

Kial OpenVPN-importo haltas ĉe auth-federate

Eksportita AWS Client VPN-profro portas direktivon, kiu diras al la kliento, ke aŭtentikigo okazas ekster la tunelo, per federacio. Ordinara OpenVPN-kliento aŭ tuj rifuzas la linion, aŭ ignoras ĝin kaj tiam havas neniun akreditilon por proponi. Ĉi tie finiĝas la plej multaj Android-klopodoj: la profilo importiĝas, la aplikaĵo protestas, aŭ la konekto mortas per agorda eraro antaŭ ol eĉ unu pakaĵo forlasas la aparaton.

Forigi auth-federate estas la tentiga sekva paŝo, kaj ĝi transformas klaran malsukceson en konfuzan. Forigi direktivon ne transformas SAML-finpunkton en aŭtentikigon per uzantnomo kaj pasvorto. La finpunkto ankoraŭ atendas subskribitan SAML-respondon kaj rifuzas tion, kion la kliento sendas anstataŭe. Via konta pasvorto, la elŝutita profilo kaj kopiita aserto ne estas interŝanĝeblaj akreditiloj.

Ensaluti al la identecprovizanto en Chrome sur la telefono pruvas nur, ke la identecprovizanto akceptis la uzanton. Ĝi diras nenion pri tio, ĉu la respondo atingas klienton, kiu povas resendi ĝin al la finpunkto. La postuloj pri federacia aŭtentikigo faras la provizitan klienton parto de la fluo ĝuste pro tio: la retumila paŝo estas necesa kaj ne sufiĉa.

Kiel aspektas la subtenata Linux-labortabla vojo

Instalu la pakaĵon, kiun AWS publikigas por Ubuntu AMD64, per via sistema pakadministrilo, poste malfermu la konekton el tiu kliento anstataŭ importi la profilon en ĝeneralan VPN-aplikaĵon. Uzu la profilon, kiun via administranto eksportis por ĉi tiu finpunkto; ne anstataŭigu callback-URL aŭ klientan identigilon el pli malnova gvidilo, eĉ se la kliento akceptas ĝin.

Startigu la konekton, finu la saluton kaj ajnan MFA-peton en la retumilo, kiu malfermiĝas, kaj lasu la reenan fluon de retumilo al kliento finiĝi. Poste petu la privatan adreson, kiun vi vere bezonas, denove. Paĝo anoncanta sukcesan saluton ne estas pruvo, ke la tunelo stariĝis.

La Linux-kliento rezervas lokajn TCP-pordojn 8096 ĝis 8115 por SAML-respondoj. Kiam la transdono pendas post kiam la identecprovizanto akceptis vin, kontrolu, kio jam aŭskultas en tiu intervalo:

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

Okupita pordo, aŭ finpunkta sekureca programaro, kiu blokas la loopback-aŭskultanton, produktas saluton, kiu ŝajnas finiĝi kaj poste neniam konektiĝas. Tenu tiun intervalon loka. Ĝi estas reena vojo ĉe la klienta flanko, ne io, kion oni malfermas en EC2-sekureca grupo aŭ en fajroŝirma regulo de enirejo, kaj malfermi ĝin al la interreto aldonas eksponiĝon sen ripari ion.

Legi la malsukcesan etapon antaŭ ol ŝanĝi ion

Kulpigi la klienton estas la kutima reflekso, sed ĉiu malsukcesa punkto apartenas al alia posedanto. Unue eltrovu, kie vi efektive estas.

  • Neniu retumila fenestro malfermiĝas. Kontrolu la aŭtentikigan reĝimon de la profilo, la konekton, kiun vi elektis, kaj la integriĝon kun la defaŭlta retumilo de la labortablo.
  • La identecprovizanto rifuzas la konton. Konta atribuo, MFA-registriĝo aŭ la agordo de la SAML-aplikaĵo, ĉio administranta teritorio.
  • La retumilo finiĝas sed la kliento neniam konektiĝas. Eksvalidiĝinta aŭ neuzebla aŭtentikiga respondo, blokita reena pordo aŭ malsukcesa transdono.
  • La tunelo staras sed la aplikaĵo neatingeblas. Finpunktaj itineroj, rajtigaj reguloj, sekurecaj grupoj, DNS. Ripeti la retumilan saluton ne povas aldoni mankan retpermeson.

Konservu la erartekston de la kliento kaj la tempon de la provo kiam vi eskalaas. La aserto, ke SAML estas difektita, kaj la aserto, ke la kliento neniam ricevis validan aŭtentikigan respondon, sendas homojn al tute malsamaj lokoj.

Kiam la postulo tamen estas Android

Android ne estas platformo, por kiu AWS publikigas sian klienton, do la honesta respondo estas, ke ne ekzistas subtenata poŝtelefona kliento por instali. Tio estas dizajna limigo, ne enigmo solvebla sur la telefono per redaktado de la profilo ĝis io konektiĝos.

Kio povas ŝanĝiĝi estas la alirdezajno malantaŭ tio, kaj tiu decido apartenas al la administranto: aprobita aplikaĵalira vojo al la unu interna servo, kiun la telefono bezonas, poŝtelefonebla VPN-produkto, kiun la organizo jam funkciigas, aŭ subtenata labortablo por la finpunkto, kiu uzas nur SAML. Ĉiu opcio kunportas sian propran finpunktan agordon, identecregistriĝon kaj rajtigajn regulojn, kaj nenion el tio uzanto povas krei el elŝutita profilo.

Tridpartaj iloj, kiuj asertas fermi la breĉon, bezonas eksplicitan subtenan kaj sekurecan revizion kovrantan MFA, respondan prilaboradon, aparatan politikon kaj ĝisdatigan ritmon. Ilia ekzisto ne faras ilin AWS-provizita Android-kliento, kaj vi ne devus movi reuzeblan aŭtentikigan materialon al telefono por igi unu el ili funkcii.

Donu al la administranto tri faktojn anstataŭ longa fadeno pri direktivoj: la aŭtentikiga reĝimo de la finpunkto, la privata rimedo, kiun la telefono devas atingi, kaj la limdato. Tio sufiĉas por elekti inter labortablo, aplikaĵalira vojo kaj nova VPN-produkto.

Kontrolu la kondiĉojn laŭorde antaŭ ol malfermi alian bileton: platformo en la listo de provizitaj klientoj, ilo, kiu povas fini la retumilan interŝanĝon, finpunkto vere agordita por federacio kaj, en Linux, la loopback-porda intervalo. La unua ero, kiu malsukcesas, estas tiu, kiun oni riparu. Ĉio post ĝi estas konjekto.

Rilataj artikoloj