AWS Client VPN の SAML ログインを完了できるクライアントはどれか

同じ AWS Client VPN と SAML の質問でも、答えは正反対になります。毎朝 Ubuntu ノート PC からサインインする人もいれば、スマートフォンとダウンロードしたプロファイルを持ち、その中の一行をクライアントに拒否される人もいます。違いは運でも、ダッシュボードの隠しスイッチでもありません。決め手は 三つの条件です。そのプラットフォームが AWS 自身のクライアント向けにサポートされているか、手元のツールがフェデレーションのブラウザ交換を実行できるか、エンドポイントがそもそも SAML 用に設定されているか。どれか 一つでも欠けると、サインインは別の場所で止まります。

ログインを完了できるかを決める 三つの条件

まずプラットフォームです。AWS は Windows、macOS、そして AMD64 上の Ubuntu 向けに独自の Client VPN クライアントを提供しており、2026 年の十月下旬時点で Linux の要件ページには Ubuntu 22.04、24.04、26.04 が記載されています。再パッケージしたビルド、変換したパッケージ、別のディストリビューションでも動くかもしれませんが、サポート対象のプラットフォームではなく、壊れたときのサポート窓口はあなた自身になります。

次にクライアントです。フェデレーションサインインは、OpenVPN 互換アプリならどれでも解釈するプロファイル項目ではありません。提供されたクライアントはブラウザで ID プロバイダーを開き、署名済みの認証レスポンスを受け取り、そのレスポンスをエンドポイントに送信します。プロファイルを読んでトンネルを張るだけのアプリはこの手順を行いません。接続ログがどれほどきれいでも同じです。

最後にエンドポイントです。Active Directory の資格情報や相互証明書を使うエンドポイントは仕組みがまったく別で、クライアントを替えても変わりません。ほかの何かを調べる前に、プロファイルを発行した相手に認証モードを確認してください。

三つの条件をまとめると、短い判断表になります：

OpenVPN インポートが auth-federate で止まる理由

エクスポートされた AWS Client VPN プロファイルには、認証がトンネルの外でフェデレーションによって行われることをクライアントに伝えるディレクティブが含まれます。汎用の OpenVPN クライアントはその行をきっぱり拒否するか無視し、その場合は提示できる資格情報がありません。Android での試みの多くはここで終わります。プロファイルはインポートされ、アプリが異議を唱え、あるいは 一つのパケットも端末を出ないうちに設定エラーで接続が落ちます。

auth-federate を削除するのは誘惑される次の一手ですが、明確な失敗を紛らわしい失敗に変えるだけです。ディレクティブを外しても SAML エンドポイントがユーザー名とパスワードの認証になるわけではありません。エンドポイントは依然として署名済みの SAML レスポンスを期待し、クライアントが代わりに送るものは拒否します。アカウントのパスワード、ダウンロードしたプロファイル、コピーしたアサーションは互換性のある資格情報ではありません。

スマートフォンの Chrome で ID プロバイダーにサインインしても、ID プロバイダーがユーザーを受け入れたことしか示しません。レスポンスがエンドポイントへ送り返せるクライアントに届くかどうかは何も語りません。フェデレーション認証の要件が提供されたクライアントをフローの一部としているのはまさにそのためです。ブラウザの手順は必要ですが、十分ではありません。

サポートされる Linux デスクトップの道筋

AWS が Ubuntu AMD64 向けに公開しているパッケージをシステムのパッケージマネージャーで導入し、プロファイルを汎用 VPN アプリにインポートするのではなく、そのクライアントから接続を開いてください。管理者がこのエンドポイント向けにエクスポートしたプロファイルを使い、古い手順のコールバック URL やクライアント識別子に置き換えないでください。クライアントが受け入れるとしても同じです。

接続を開始し、開いたブラウザでサインインと MFA の要求を済ませ、ブラウザからクライアントへの戻りフローを最後まで通します。そのうえで、本当に必要なプライベートアドレスを新たに要求してください。サインイン成功を知らせるページは、トンネルが上がった証拠ではありません。

Linux クライアントは SAML レスポンス用にローカル TCP ポート 8096 から 8115 を確保します。ID プロバイダーがあなたを受け入れた後も受け渡しが止まる場合は、その範囲で何がすでに待ち受けているかを確認してください：

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

ポートが埋まっている、あるいはループバックの待ち受けをエンドポイントセキュリティ製品が遮断していると、サインインは完了したように見えて接続されません。この範囲はローカルのままにしてください。クライアント側の戻り経路であり、EC2 セキュリティグループやゲートウェイのファイアウォール規則で開けるものではありません。インターネットに開けても何も直らず、露出だけが増えます。

何かを変える前に失敗している段階を読む

クライアントのせいにしたくなりますが、失敗する箇所はそれぞれ別の持ち主です。まず自分がどこにいるのかを確かめてください。

• ブラウザのウィンドウが開きません。 プロファイルの認証モード、選択した接続、デスクトップの既定ブラウザとの連携を確認します。
• ID プロバイダーがアカウントを拒否します。 アカウントの割り当て、MFA の登録、SAML アプリケーションの設定。いずれも管理者の領域です。
• ブラウザは終わるのにクライアントが接続しません。 期限切れか使えない認証レスポンス、遮断された戻りポート、失敗した受け渡しです。
• トンネルは上がっているのにアプリケーションに届きません。 エンドポイントのルート、認可ルール、セキュリティグループ、DNS。ブラウザのサインインを繰り返しても、足りないネットワーク権限は増えません。

エスカレーションするときは、クライアントのエラーテキストと試行時刻を残してください。SAML が壊れているという説明と、クライアントが有効な認証レスポンスを受け取っていないという説明では、人が向かう先がまったく違います。

それでも要件が Android のとき

Android は AWS が自社クライアントを公開しているプラットフォームではないため、正直な答えは、インストールできるサポート対象のモバイルクライアントは存在しないということです。これは設計上の制約であり、プロファイルを書き換えて何かがつながるまで粘る電話上のパズルではありません。

変えられるのはその背後にあるアクセス設計であり、その判断は管理者のものです。スマートフォンが必要とする唯一の社内サービスへの承認済みアプリケーションアクセス経路、組織がすでに運用しているモバイル対応 VPN 製品、あるいは SAML のみのエンドポイント向けのサポート対象デスクトップです。どの選択肢も独自のエンドポイント設定、ID 登録、認可ルールを伴い、そのどれも利用者がダウンロードしたプロファイルから作れるものではありません。

隙間を埋めると称するサードパーティ製ツールには、MFA、レスポンスの扱い、デバイスポリシー、更新の頻度を対象とした明示的なサポートとセキュリティのレビューが必要です。存在するからといって AWS 提供の Android クライアントになるわけではなく、どれかを動かすために再利用可能な認証素材をスマートフォンへ移すべきでもありません。

ディレクティブについての長いやり取りではなく、三つの事実を管理者に渡してください。エンドポイントの認証モード、スマートフォンが到達すべきプライベートリソース、そして期限です。デスクトップ、アプリケーションアクセス経路、新しい VPN 製品のどれを選ぶかは、それで足ります。

新しいチケットを開く前に、条件を順に確認してください。プラットフォームが提供クライアントの一覧にあるか、ブラウザ交換を完了できるツールか、本当にフェデレーション用に設定されたエンドポイントか、Linux ではループバックのポート範囲か。最初に落ちた項目が直すべきものです。それ以降は推測にすぎません。