この記事は自動的に翻訳されています。翻訳には不正確な表現が含まれる場合があります。
英語の原文はこちらをご覧ください。
Ctrlk
linkedinx-twitter
For the complete documentation index, see llms.txt. This page is also available as Markdown.

サーバー設定

サーバー設定は https://YOURNAME.radius-as-a-service.com/settings/server で利用できます

ポートと IP アドレス

概要

RADIUSaaS は、ユーザーに安全なクラウドベースの認証を提供するために RadSec サービスを運用しています。さらに、ハードウェアやソフトウェアの制約などにより、自社のネットワーク環境で RadSec を利用できないお客様向けに、RADIUSaaS は RADIUS プロキシを提供し、RADIUS から RadSec へのプロトコル変換を処理します。

RadSec サービスと RADIUS サービスのどちらも、パブリック IP アドレスを提供しており、これによりネットワーク機器やサービスはインターネット経由でどこからでも当社サービスと通信できます。これらのサービスは、それぞれ独自の登録ポートで動作します。

RadSec / TCP

RadSec DNS

RadSec サービスに到達できる DNS エントリです。

サーバー IP アドレス

これは RadSec サービスのパブリック IP アドレスです。

RadSec ポート

これは RadSec の登録ポートです: 2083

フェイルオーバーと冗長性

より高い冗長性が必要なお客様には、複数の RadSec エンドポイントをインスタンス用に設定し、追加の IP アドレスを提供できます。このサービスには追加費用がかかることにご注意ください。

重要な点として、RADIUSaaS は フェイルオーバーを提供しません RadSec エンドポイント間ではフェイルオーバーを提供しません。代わりに、このフェイルオーバーは通常、以下の Meraki を使用した例に示すように、お客様のネットワーク機器側で実装されます。

可視性を高め、追加サービス（DNS）への依存を減らすため、DNS ではなく IP アドレスを使用してフェイルオーバー シナリオを構成することを推奨します。

この構成では、2 つの RadSec IP アドレスが優先順に一覧表示されます。Meraki がいずれかの IP アドレスに到達できない場合、通常はさらに 2 回試行して次の IP アドレスに移ります。Meraki（または他の）システムのフェイルオーバー機能については、各自の資料を参照してください。

優先順位順に複数の RadSec サーバーを表示しています（Meraki）。

RadSec 設定

最大 TLS バージョン

この設定は、あなたの RadSec インターフェースで使用される最大 TLS バージョンを制御します。最小バージョンは 1.2 に固定され、デフォルトの最大値は 1.3 に設定されています。

TLS 1.3 は、ハンドシェイク後認証メカニズムを含め、1.2 に比べていくつかの利点があります。これにより、ハンドシェイク完了前に追加の資格情報を要求できます。これは、次に説明する RadSec 証明書の確認設定にとって重要です。

最大 EAP TLS バージョン

この設定は、エンドポイントが証明書（EAP-TLS）または ユーザー名/パスワードの資格情報を使用して RADIUSaaS インスタンスに対して認証する際に、EAP で使用される最大 TLS バージョンを制御します.

すべての最新のオペレーティング システムでは、 TLS 1.3 が推奨されるデフォルトです。ただし、いくつかの（古い）Windows 10/11 ビルドでは、規格に準拠していない実装で EAP-TLS の TLS 1.3 対応を宣伝していました。影響を受けるビルドの Windows クライアントで接続の問題が発生する場合は、より広い互換性のためにネゴシエートされるプロトコル バージョンを TLS 1.2 に制限してください。

RadSec 証明書の失効チェック

この設定は、すべての RadSec 接続に対して失効チェックを実行するかどうかを決定します。失効チェックの検証方法は、クライアント認証証明書に使用されるものとは少し異なります。

RadSec を正しく動作させるために、Access Point、Switch、VPN サーバーなどのネットワーク機器は、TLS で保護された接続を RadSec サーバーに確立します。RadSec の導入では通常、双方が TLS ハンドシェイク中に X.509 証明書を使用して相互に認証する相互 TLS（mTLS）が使われます。RADIUSaaS の実装では mTLS が強制されます。

RadSec クライアント証明書の有効性と失効状態を判断するには、TLS 認証プロセスの一部として証明書をクライアントが提示する必要があります。証明書を受信して初めて、失効チェック（たとえば CRL や OCSP による）を実行できます。

TLS 1.2

TLS 1.2 は、初期ハンドシェイク中に次のメッセージを使用して相互 TLS 認証をサポートします CertificateRequest, Certificate、および CertificateVerify メッセージを使用します。クライアント認証が必要で適切に強制されている場合、RadSec クライアント証明書は提示され、検証され、TLS セッションが確立される前および RADIUS トラフィックが交換される前に失効確認が行われます。

ただし、TLS 1.2 ではオプションのクライアント認証も許可され、再ネゴシエーションもサポートされます。その結果、一部の RadSec クライアント実装では、クライアント証明書を提示せずに初期ハンドシェイクを完了する場合があります。この動作は 実装依存であり、TLS 1.2 プロトコルの制限ではありません。

上記の動作を軽減するため、 RadSec 証明書の失効チェック 最大 TLS バージョンが 1.2 に設定されている場合、この設定は無効になります。後で手動で再度有効化できることにご注意ください。

TLS 1.3

TLS 1.3 は、相互 TLS 認証のための、より決定的で簡素化されたモデルを提供します。クライアント認証が要求されると、RadSec クライアント証明書は初期ハンドシェイクの一部として交換され、TLS 接続が確立される前に検証されます。 これにより、RadSec サーバーは証明書の失効状態を含めクライアント証明書を直ちに検証でき、証明書が無効または失効している場合にはハンドシェイクを失敗させることができます。その結果、TLS 1.3 は RadSec 接続に対する相互 TLS 認証をより厳密かつ予測可能に強制できます。

この RadSec 証明書の失効チェック 設定は、最大 TLS バージョンが 1.3 に設定されると自動的に有効になります。

RADIUS / UDP

このセクションは、少なくとも 1 つ RADIUS プロキシを構成している場合に利用できます。各プロキシごとに個別のパブリック IP アドレスが利用可能です。このセクションのパブリック IP アドレスは RADIUS プロトコルのみをサポートし、そのため 1812/1813 ポートで待ち受けます。

サーバー IP アドレスと場所

これらの IP アドレスは次でのみ待ち受けます RADIUS を UDP ポート 1812/1813 で。

RADIUS プロキシの地理的位置および各パブリック IP アドレスの地理的位置です。

共有シークレット

それぞれの RADIUS プロキシの共有シークレットです。デフォルトでは、すべての RADIUS プロキシは同じ共有シークレットで初期化されます。

プロキシごとに共有シークレットを変更している様子を表示

ポート

このセクションには、RADIUS 認証（1812）および RADIUS アカウンティング（1813）サービスの標準ポートが表示されます。

フェイルオーバーと冗長性

プロキシ冗長性

単一の RADIUSaaS プロキシでは冗長性は提供されないことにご注意ください。冗長性を確保するには、以下に説明するように複数の RADIUSaaS プロキシをセットアップしてください こちら.

プロキシ向けの RadSec サービス冗長性

複数の RadSec インスタンスで RADIUSaaS を使用する場合、プロキシは利用可能なすべての RadSec インスタンスに接続するよう自動的に設定されます。RADIUSaaS プロキシは、最も近い地域の RadSec サービスへの接続を優先します。そのサービスが利用できない場合は、別の利用可能な RadSec サービスに切り替えます。

サーバー証明書

Customer-CA

デフォルトでは、RADIUSaaS は RADIUS サーバー証明書 を生成します。これは、当社サービス上にこの目的のためだけに用意された認証局（CA）によって署名されます。これを Customer-CAと呼んでいます。Customer-CA はお客様ごとに固有です。

Customer-CA を作成するには、次の簡単な手順に従ってください:

  1. 移動します 設定 > サーバー設定

  2. クリックします 追加

  3. 選択します RaaS に CA を作成させる

  4. をクリックします 保存

  5. 作成後、Server Certificates の下に新しい証明書が表示されます

独自の証明書を持ち込む

次の Customer CAを使用したくない場合は、独自の証明書を最大 2 つアップロードできます。

SCEPman 発行のサーバー証明書

SCEPman Certificate Master を利用して新しいサーバー証明書を生成するには、次の手順に従ってください:

  1. SCEPman Certificate Master の Web ポータルに移動します。

  2. 左側の Request Certificate を選択します

  3. 選択します （Web）サーバー を上部で

  4. 選択します フォーム

  5. 証明書を有効にするすべての Subject Alternative Name（SAN）を、カンマ、セミコロン、または改行で区切って入力します。次の説明に従ってサーバー証明書を生成し こちら 、任意の FQDN を指定してください。デフォルトのサーバー証明書の SAN を、たとえば次のように調整することを推奨します radsec-<your RADIUSaaS instance name>.radius-as-a-service.com.

  6. を設定します ダウンロード ファイル形式 を PEM

  7. 選択します 証明書チェーンを含める にして、証明書をダウンロードします。

  8. 必ず サーバー認証とクライアント認証の両方 を EKU に含めてください。

  9. 送信 して、新しいサーバー証明書のダウンロードを要求します。

重要：パスワードは Certificate Master から復元できないため、一時的に控えておいてください。

新しいサーバー証明書をアップロードします RADIUSaaS

上記の手順で作成したサーバー証明書を追加するには、次へ移動します RADIUSaaS インスタンス > 設定 > サーバー設定 > 追加し、 次に

  1. 選択します PEM または PKCS#12 でエンコードされた証明書 （手順 5 で PKCS#12 を選択した場合、これには公開鍵と秘密鍵の両方が含まれます）

  2. 証明書ファイルをドラッグ＆ドロップするか、クリックして参照します

  3. のパスワードを入力します 秘密鍵

  4. クリックします 保存

ご注意ください：デフォルトでは、SCEPman Certificate Master は 730 日間有効な証明書を発行します。これを変更したい場合は、SCEPman の ドキュメント.

証明書の有効化

サーバー証明書の有効期限を監視し、サービス中断を防ぐために期限内に更新してください。

証明書は時々期限切れになるか、使用したい証明書の選好が変わるため、サーバーが使用している証明書を管理できることが重要です。 Active 列には、サーバーが現在使用している証明書が表示されます。サーバーが使用している証明書を変更するには、選択したい証明書の行を展開し、 有効化.

ダウンロード

以下をダウンロードするには サーバー証明書 、2 つの方法があります：

  1. クリックします CA 証明書をダウンロード を上部で選択します。これにより、現在の 信頼されたルート CA の アクティブな サーバー証明書を直接ダウンロードできます。

  2. 対応する行の ダウンロード アイコンをクリックします。

オプション 2 を選ぶと、完全な証明書パスを表示するダイアログが開きます。 ルート証明書 は常に緑で表示されます。

ルート証明書を緑で表示

どちらの方法でも、ダウンロードされるルート証明書は base64（PEM）でエンコードされています。デバイス（たとえば WiFi コントローラー）がバイナリエンコード（DER）を必要とする場合は、次を使用して変換できます OpenSSL:

削除

証明書を削除するには、対応する行を展開し、 削除 をクリックして選択を確定します。

証明書の有効期限

RADIUS サーバー証明書を期限切れにしないでください。認証が失敗します。

証明書は時々期限切れになります。有効期限が切れる 5 か月前になると、ダッシュボードに警告アイコンが表示され、通知されます。

証明書の有効期限を示すスクリーンショット

アクティブな RADIUS サーバー証明書の横に三角形が表示されている場合は、次のガイドに従って更新してください：

サーバー証明書の更新

最終更新

役に立ちましたか？