MRにおける RADIUS フェイルオーバーおよびリトライ
このドキュメントはこちらのページを 2022年4月20日時点で翻訳したものです。
最新の情報は英語版をご確認ください。
Meraki アクセスポイントには、ユーザー認証に 1 つまたは複数の外部 RADIUS サーバーを使用できるサインオンスプラッシュページをホストする機能があります。このドキュメントでは、接続先RADIUS サーバーの決定方法や、設定したサーバーと通信できない場合のアクセスポイント側の動作について解説します。
このドキュメントでは、認証用に 3 つの RADIUS サーバを設定し、それらのホスト名が radius1.example.com、radius2.example.com、および radius3.example.com であると仮定します（この順です）。以下の例では、それぞれをサーバー1、2、3と呼ぶことにします。
ロードバランシングポリシー
ダッシュボードの「ロードバランシングポリシー」設定は、認証試行時に最初に接続するRADIUSサーバーを指定したり、再試行が必要な場合の順序を決定します。
この設定は、ワイヤレス > アクセス制御 で、”Splashページ" で サインオン方法 に "マイ RADIUS サーバー" を設定した場合に表示されます。”完全優先順位”(デフォルト)と”ラウンドロビン”のオプションがあります。
.png?revision=1)
完全優先順位
"SplashページのRADIUS" で設定された順序に従って接続します。この例では、1,2,3 の順番になります。つまり、サーバー1が常に最初に接続され、サーバー1が接続できない場合にのみサーバー2が接続されます。同様に、サーバー3は、サーバー1にもサーバー2にも到達できない場合にのみ接続されます。
接続条件で ”エンタープライズ認証”を設定した場合も”完全優先順位”で接続が行われます。
なお、エンタープライズ認証ではフェールオーバーポリシーをラウンドロビンに変更することはできません。
エンタープライズ認証を選択し、"RADIUS の詳細設定" で RADIUS フォールバック の設定がアクティブの場合以下のような挙動になります。
1. サーバー 1 が到達不能になった場合、サーバー2 へ接続し、認証に成功した場合はサーバー 2 の使用を継続する
2. サーバー2 の使用を継続するが、サーバー1 への疎通確認を並行して行う
3. サーバー 1 への疎通が復旧したことを確認すると、以後の認証はサーバー 1 へ切り戻す(フォールバック)
RADIUS の詳細設定についてはこちらのドキュメントをご確認ください。
ラウンドロビン
接続するサーバーは、最後に使用されたサーバーを基準に順繰りになります。したがって、クライアントからの最初の認証リクエストでは、サーバーに接続する順番は1,2,3となります（つまり、「完全優先順位」の設定と同じです）。しかし、次の認証リクエストでは、2,3,1、3,1,2、そして再び1,2,3という順序になります。この設定により各サーバーが受け取る認証リクエストの数を平準化し認証処理を分散できます。
接続の再試行
RADIUS サーバーに到達できない場合、ダッシュボード は各サーバーに最大 3 回（最初のリクエスト 1 回と再試行 2 回）問い合わせを試みます。
上記の例では、ロードバランシングポリシーによって動作が異なります。
- ポリシーが「完全優先順位」に設定されており、3 台のサーバーすべてが使用できない場合、ダッシュボード は合計 9 つの RADIUS パケットを「1,2,3,1,2,3,1,2,3」の順番で送信します。
- 「ラウンドロビン」に設定されている場合、最初に試行するサーバーは異なる場合があります。（例:2,3,1,2,3,1,2,3,1)
再試行してもどのサーバーからも有効な応答が得られない場合、リクエストは「フェイルオーバー・ポリシー」の設定（下記参照）に従って処理されます。
リトライのタイミング
ダッシュボード は、2 秒のパケットタイムアウトが設定されています。これは、RADIUS 要求パケットを送信した後、ダッシュボード は最大 2 秒間応答を待ちます。2秒間応答がなかった場合 2 回再試行し、いずれもタイムアウトした場合、次のサーバに接続します。
以下のいずれかの条件を満たした場合次のサーバーへ接続します。
- RADIUS要求への応答がタイムアウトした
- エラーパケットを受信した
エラーパケットは通常、ICMP "Destination Unreachable" パケットで、接続が拒否されたか（例：宛先ホストの指定UDPポートでプログラムがリッスンされていない）、ホスト自体が到達不可能である（例：無効なIPアドレス）ことを示します。このようなパケットを受信した場合、ダッシュボード はそのサーバーからの応答パケットを受信できないと判断し、リスト上の次のサーバーに直ちに接続します。
パケットタイムアウトが必要なのは、過負荷状態にあるRADIUSサーバーや、要求パケットをドロップするファイアウォールの背後にあるサーバーが、認証要求に対するエラーパケットを送信しない可能性があるためです。
設定したすべてのRADIUSサーバーが到達不可能な場合、エンドユーザーがサインオンスプラッシュでログインしようとした後に応答を待つ必要がある最大時間は、3*N*T（Nは設定されたRADIUSサーバーの数、Tはパケットごとのタイムアウト）です。T=2秒の通常のケースでは、ユーザーはサーバーごとに最大6秒待つ必要があり、3つのRADIUSサーバーが設定されている場合は最大18秒になります。
フェイルオーバーポリシー
”フェイルオーバーポリシー" 設定は、設定した全ての RADIUS サーバーが到達できない場合の認証要求パケットの処理を決定します。
もしポリシーが "アクセスを拒否" ならば、一つ以上の RADIUS サーバーが再び利用可能になるまで新規に接続するユーザーはネットワークに接続できません。(既存のセッションを持つユーザーは、そのセッションが終了するまでネットワークを使用できます）。デフォルトではこちらが設定されています。
ポリシーが「アクセスを許可」の場合、RADIUS サーバーに接続できない場合、ユーザーはネットワークでの 1 時間の特別セッションで接続できます。
フェイルオーバーポリシーは Splas ページで RADIUS 認証を設定している場合のみ設定できます。
RADIUS アカウンティング
RADIUSアカウンティング・サーバーが設定されている場合、RADIUS認証リクエストの再試行について前述したのと同じ動作が、RADIUSアカウンティング・メッセージの再試行にも適用されます。唯一の違いは、「フェイルオーバーポリシー」設定がRADIUSアカウンティングに適用されないことです（アカウンティングサーバーの可用性が、ネットワーク上でクライアントが許可されるかどうかに影響することはありません）。