Які кліент можа завяршыць уваход праз SAML у AWS Client VPN
Працоўныя сталы Linux з кліентам AWS могуць завяршыць перадачу браўзера праз SAML; звычайны імпарт OpenVPN на Android не можа. Ваш выпадак вызначаюць тры ўмовы.
Два чалавекі задаюць адно і тое ж пытанне пра AWS Client VPN і SAML і атрымліваюць процілеглыя адказы. Адзін кожную раніцу ўваходзіць з ноўтбука на Ubuntu; другі мае тэлефон, спампаваны профіль і кліент, які адхіляе радок у ім. Розніца не ў удачы і не ў схаваным перамыкачы ў панэлі. Справа ў трох умовах: ці платформа належыць да тых, якія AWS падтрымлівае для ўласнага кліента, ці можа інструмент у вашых руках выканаць федэратыўны абмен праз браўзер, і ці наладжаны канцавы пункт для SAML наогул. Прапусціце хоць адну з трох — і ўваход спыніцца ў іншым месцы.
Тры ўмовы вырашаюць, ці зможа ўваход завяршыцца
Платформа ідзе першай. AWS выпускае ўласны кліент Client VPN для Windows, macOS і Ubuntu на AMD64, і па стане на канец кастрычніка 2026 года старонка патрабаванняў Linux называе Ubuntu 22.04, 24.04 і 26.04. Перапакаваная зборка, сканвертаваны пакет або іншае размеркаванне могуць працаваць, але гэта не падтрымліваемая платформа, і калі яна зламаецца, лініяй падтрымкі будзеце вы.
Кліент ідзе другім. Федэратыўны ўваход — не тая опцыя профілю, якую разбірае кожная праграма, сумяшчальная з OpenVPN. Прадастаўлены кліент адкрывае вашага пастаўшчыка ідэнтычнасці ў браўзеры, атрымлівае падпісаны адказ аўтэнтыфікацыі і перадае гэты адказ канцавому пункту. Праграма, якая толькі чытае профіль і ўздымае тунель, гэты крок не выконвае, як бы чыста ні выглядаў яе журнал злучэнняў.
Канцавы пункт ідзе трэцім. Канцавы пункт з уліковымі данымі Active Directory або ўзаемнымі сертыфікатамі мае зусім іншую схему, і замена кліентаў яе не зменіць. Пацвердзіце рэжым аўтэнтыфікацыі ў таго, хто выдаў профіль, перш чым што-небудзь яшчэ адладжваць.
Узятыя разам, тры ўмовы даюць кароткую табліцу рашэнняў:
| Platform | AWS-provided client | Completes the SAML exchange | What that means |
|---|---|---|---|
| Ubuntu 22.04 / 24.04 / 26.04, AMD64 | Yes | Yes | Normal sign-in path; debug stages, not platforms |
| Windows or macOS | Yes | Yes | Same path, different installer |
| Android | No published client | No | Needs a different access design, not a different profile |
| Other Linux distributions | No | Depends on the tool | Runs at your own support risk |
Чаму імпарт OpenVPN спыняецца на auth-federate
Экспартаваны профіль AWS Client VPN змяшчае дырэктыву, якая паведамляе кліенту, што аўтэнтыфікацыя адбываецца па-за тунелем, праз федэрацыю. Звычайны кліент OpenVPN альбо адхіляе гэты радок цалкам, альбо ігнаруе яго і тады не мае якіх уліковых даных прапанаваць. Менавіта тут завяршаюцца большасць спроб на Android: профіль імпартуецца, праграма пярэчыць, або злучэнне памірае з памылкай канфігурацыі перш, чым хоць адзін пакет пакіне прыладу.
Выдаленне auth-federate — спакуслівы наступны крок, і ён ператварае ясную няўдачу ў заблытаную. Выдаленне дырэктывы не пераўтварае канцавы пункт SAML у аўтэнтыфікацыю па імені карыстальніка і паролі. Канцавы пункт па-ранейшаму чакае падпісаны адказ SAML і адхіляе тое, што кліент дасылае замест яго. Пароль вашага ўліковага запісу, спампаваны профіль і скапіяванае сцвярджэнне не ўзаемазаменныя ўліковыя даныя.
Уваход у пастаўшчыка ідэнтычнасці ў Chrome на тэлефоне даказвае толькі тое, што пастаўшчык ідэнтычнасці прыняў карыстальніка. Гэта нічога не кажа пра тое, ці дойдзе адказ да кліента, які можа адправіць яго назад на канцавы пункт. патрабаванні да федэратыўнай аўтэнтыфікацыі менавіта таму робяць прадастаўлены кліент часткай працэсу: крок у браўзеры неабходны, але не дастатковы.
Як выглядае падтрымліваемы шлях для працоўнага стала Linux
Усталюйце пакет, які AWS публікуе для Ubuntu AMD64, сродкамі сістэмнага менеджэра пакетаў, а затым адкрыйце злучэнне з гэтага кліента, а не імпартуйце профіль ва ўніверсальную VPN-праграму. Выкарыстоўвайце профіль, які ваш адміністратар экспартаваў для гэтага канцавога пункта; не падмяняйце адрас вяртання або ідэнтыфікатар кліента з больш старога кіраўніцтва, нават калі кліент яго прымае.
Запусціце злучэнне, завяршыце ўваход і любы запыт MFA у браўзеры, які адкрыецца, і дайце працэсу вяртання ад браўзера да кліента завяршыцца. Затым запытайце прыватны адрас, які вам сапраўды патрэбны, нанова. Старонка, якая абвяшчае паспяховы ўваход, не з’яўляецца доказам таго, што тунель узняўся.
Кліент Linux пакідае за сабой лакальныя TCP-порты з 8096 па 8115 для адказаў SAML. Калі перадача завісае пасля таго, як пастаўшчык ідэнтычнасці вас прыняў, праверце, што ўжо слухае ў гэтым дыяпазоне:
ss -ltnp | grep -E ":809[6-9]|:81(0[0-9]|1[0-5])"
Заняты порт або праграма бяспекі канцавога пункта, якая блакуе слухача зваротнай сувязі, даюць уваход, які выглядае завершаным, а затым ніколі не злучаецца. Трымайце гэты дыяпазон лакальным. Гэта шлях вяртання на баку кліента, а не тое, што варта адкрываць у групе бяспекі EC2 або ў правіле фаеруола шлюза, і адкрыццё яго ў інтэрнэт дадае ўздзеянне, нічога не выпраўляючы.
Прачытайце этап, на якім адбылася няўдача, перш чым нешта мяняць
Вінаваціць кліент — звычная рэакцыя, але кожная кропка няўдачы належыць розным уладальнікам. Спачатку вызначце, дзе вы насамрэч знаходзіцеся.
- Акно браўзера не адкрываецца. Праверце рэжым аўтэнтыфікацыі профілю, выбранае злучэнне і інтэграцыю з прадвызначаным браўзерам працоўнага стала.
- Пастаўшчык ідэнтычнасці адхіляе ўліковы запіс. Прызначэнне ўліковага запісу, рэгістрацыя MFA або канфігурацыя праграмы SAML — усё гэта зона адміністратара.
- Браўзер завяршаецца, але кліент так і не злучаецца. Пратэрмінаваны або непрыдатны адказ аўтэнтыфікацыі, заблакаваны порт вяртання або няўдалая перадача.
- Тунель узняты, але праграма недаступная. Маршруты канцавога пункта, правілы аўтарызацыі, групы бяспекі, DNS. Паўторны ўваход праз браўзер не можа дадаць адсутнае сеткавае дазвол.
Захавайце тэкст памылкі кліента і час спробы, калі эскалюеце. Сцвярджэнне, што SAML зламаны, і сцвярджэнне, што кліент ніколі не атрымаў сапраўднага адказу аўтэнтыфікацыі, накіроўваюць людзей у зусім розныя месцы.
Калі патрабаванне ўсё ж Android
Android — не тая платформа, для якой AWS публікуе свой кліент, таму сумленны адказ такі: усталёўваць няма падтрымліваемага мабільнага кліента. Гэта абмежаванне дызайну, а не галаваломка, якую трэба развязаць на тэлефоне, рэдагуючы профіль, пакуль нешта не злучыцца.
Змяніцца можа схема доступу за гэтым, і гэтае рашэнне належыць адміністратару: ухвалены шлях доступу да праграмы да адной унутранай службы, патрэбнай тэлефону, мабільны VPN-прадукт, які арганізацыя ўжо эксплуатуе, або падтрымліваемы працоўны стол для канцавога пункта, што выкарыстоўвае толькі SAML. Кожны варыянт нясе сваю канфігурацыю канцавога пункта, рэгістрацыю ідэнтычнасці і правілы аўтарызацыі, і нічога з гэтага карыстальнік не можа стварыць са спампаванага профілю.
Староннія інструменты, якія сцвярджаюць, што зачыняюць прамежак, патрабуюць відавочнай праверкі падтрымкі і бяспекі, якая ахоплівае MFA, апрацоўку адказаў, палітыку прылад і частату абнаўленняў. Іх наяўнасць не робіць іх кліентам Android ад AWS, і не варта пераносіць шматразовыя матэрыялы аўтэнтыфікацыі на тэлефон, каб адзін з іх запрацаваў.
Дайце адміністратару тры факты замест доўгай перапіскі пра дырэктывы: рэжым аўтэнтыфікацыі канцавога пункта, прыватны рэсурс, да якога павінен дабрацца тэлефон, і крайні тэрмін. Гэтага дастаткова, каб выбраць паміж працоўным сталом, шляхам доступу да праграмы і новым VPN-прадуктам.
Праверце ўмовы па парадку, перш чым адкрываць чарговы тыкет: платформа ў спісе прадастаўленых кліентаў, інструмент, здольны завяршыць абмен праз браўзер, канцавы пункт, сапраўды наладжаны для федэрацыі, і на Linux дыяпазон партоў зваротнай сувязі. Першы пункт, які не выконваецца, і трэба выпраўляць. Усё далейшае — здагадкі.