RADIUS展開アーキテクチャ

一般的に推奨されるRADIUS展開アーキテクチャ

トピック

これは最も単純な展開モデルです。単一のアクティブなOkta RADIUS Serverエージェントが提供できる以上の高いスループット要件がない環境の場合、このモデルで十分です。

このアプローチでは、1つのOkta RADIUS ServerエージェントをVPNデバイスのアクティブサーバーとして構成し、別のOkta RADIUS Serverをパッシブフェイルオーバーとして構成します。総スループットは、単一のRADIUS Serverエージェントの能力によって制限されます。

アクティブ-パッシブアプローチを実装する場合、フェイルオーバーはクライアントの責任です。何らかの理由でアクティブRADIUS Serverエージェントに到達できない場合、パッシブRADIUS Serverエージェントインスタンスを指すようにクライアントを再構成できる必要があります。

一部の例と用語では、Cisco ASA VPNクライアントを使用するF5ロードバランサーを想定しています。

最高のスループットと可用性を実現するには、ロードバランサーの背後に2つ以上のOkta RADIUS Server Agentを展開することをお勧めします。このアプローチでは、負荷分散プールに追加のRADIUS Server Agentを追加し、トラフィック負荷をエージェント間で均等に分散することで、水平方向のスケーリングが可能です。RADIUS Server Agentの数は、予想されるボリュームと、ピーク時の1分あたりのトランザクションによって異なります。

  • 仮想ネットワーク

    • RADIUS要求を送信するデバイスごとに個別の仮想サーバーを設定します。仮想サーバーごとに個別のサーバープールを作成します。

  • セッション永続化

    • 特に2FAチャレンジへのユーザー入力の待機がオフバンドで行われる状況（Okta Verify with Pushなど）でパフォーマンスを最適化するために、エンドユーザーのVPNクライアントまたはIPに基づくセッション永続化（別名スティッキーセッション）を使用して負荷分散を行う必要があります。Okta RADIUS Server Agentは、発信元のRADIUSクライアントからの要求の重複排除を処理しますが、要求が複数のエージェント間で分散される場合、Oktaサービス側でのみ重複排除されるため、不要な負荷がかかります。詳細については、以下の「ロードバランサーのセッション永続化に関する注意事項」を参照してください。

    永続化の構成として、通常はCalling-Station-IDとFramed-IPを組み合わせて使用することを推奨しています。多くのVPNでは、Calling-Station-IDは発信元のクライアントIPアドレスになります。別のRADIUS属性がクライアントIPアドレスを格納している場合、代わりにその属性を使用するようにロードバランサーを構成します。

  • 負荷分散方法

    • アクティブなRADIUS Server Agentに負荷を分散できる場合は、最小接続の負荷分散方法を設定することをお勧めします。

  • ヘルスチェック

    • 合成ログインでロードバランサーのヘルスチェック機能を使用して、RADIUS Server Agentの問題発生時にフェイルオーバーをシームレスに行い、ユーザーへの影響を最小限に抑えられるようにします。各仮想サーバーは、それぞれのポートで独自のヘルスチェックを行う必要があります。ヘルスチェックを実行するようにロードバランサーまたはRADIUSクライアントを構成するには、この目的にのみ使用するユーザーアカウントを作成します。以下をお勧めします。

    1. 割り当てられたグループや、アプリケーションへのアクセス権がなく、基本的なユーザーアカウント以上の権限を持たないユーザーを作成します。
    2. ヘルスチェック用のユーザーアカウントには、一意の強力なパスワードを作成します。

      注：パスワードおよびユーザー名にハッシュ（#）文字を含めることはできません。

    3. このインバウンドヘルスチェックをトリアージするためのカスタムRADIUSアプリケーションを作成します。
    4. このユーザーをRADIUSアプリケーションに割り当てます（これによりアクセスが許可されます）。

    このアカウントの目的は、RADIUSクライアントがOktaサービスにアクセスし、認証要求を適切に処理できることを検証することです。第2要素のトランザクションは通常、何らかのユーザー入力または動的応答を必要とするため、通常、ヘルスチェックにはプライマリ認証のみを含める必要があります。

    2回連続して失敗した後、RADIUSサーバーをローテーションから外すようにロードバランサーを設定します。サーバーからの応答が1回成功した後、サーバーをローテーションに戻すようにロードバランサーを設定します。

  • ロードバランサーの高可用性

    • システム全体の可用性を最大限に高めるため、単一障害点を回避できるようにロードバランサーの冗長システムを構成することを検討してください。推奨事項については、ロードバランサーベンダーのドキュメントを参照してください。

RADIUSの負荷分散に関するF5の全体的な推奨事項については、RADIUSの負荷分散に関するF5のドキュメントを参照してください。F5はRADIUSボリュームを管理するためのiAppをサポートしています。このiAppは、エンドユーザーが確実に認証できるようにするための代理トランザクションによる自動ヘルスチェックもサポートしています。