サーバー設定
サーバー設定は https://YOURNAME.radius-as-a-service.com/settings/server で利用できます
ポートとIPアドレス
概要
RADIUSaaSは、ユーザー向けに安全なクラウドベースの認証を提供するためにRadSecサービスを運営しています。加えて、ハードウェアやソフトウェアの制約などによりネットワーク環境でRadSecを利用できない顧客向けに、RADIUSからRadSecへのプロトコル変換を処理するRADIUSプロキシを提供します。
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回試行してから次のアドレスに移ります。Meraki(または他の)システムのフェイルオーバー機能の詳細については、ご利用のリソースを参照してください。

RadSec設定
以下の設定は、RADIUSaaSインスタンスへのRadSec接続の特定の側面を制御します。
最大TLSバージョン
この設定はRadSecインターフェースの最大TLSバージョンを制御します。最小バージョンは1.2に固定されており、デフォルトの最大は1.3に設定されています。
TLS 1.3は1.2と比べて複数の利点を提供します。たとえばポストハンドシェイク認証メカニズムにより、ハンドシェイク完了前に追加の認証情報を要求できる点があります。これは次に説明するRadSec証明書の検証チェックに重要です。
RadSec証明書の失効チェック
この設定は、すべてのRadSec接続に対して失効チェックを実行するかどうかを決定します。失効チェックの検証方法はクライアント認証証明書で使用される方法とは若干異なります。
適切なRadSecの動作のために、アクセスポイント、スイッチ、VPNサーバーなどのネットワーク機器はRadSecサーバーへのTLS保護接続を確立します。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アドレスはUDPポート1812/1813での RADIUS のみをリッスンします。
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を作成するには、次の簡単な手順に従ってください:
に移動 設定 > サーバー設定
をクリック 追加
を選択 RaaSにCAを作成させる
をクリック 保存
作成後、サーバー証明書の下に新しい証明書が利用可能であるのが表示されます。

独自の証明書を持ち込む
Customer CAを使用したくない場合、独自の証明書を最大2つまでアップロードできます。 Customer CA、あなたは最大2つまで自身の証明書をアップロードできます。
SCEPman発行のサーバー証明書
SCEPman Certificate Masterを利用して新しいサーバー証明書を生成するには、次の手順に従ってください:
SCEPman Certificate MasterのWebポータルにアクセスしてください。
左側でRequest Certificateを選択してください。
を選択 (Web) Server を上部で
を選択 フォーム
証明書が有効であるべきすべてのサブジェクト代替名(SAN)をカンマ、セミコロン、または改行で区切って入力してください。FQDNを指定してサーバー証明書を生成します。デフォルトのサーバー証明書のSANを次のように適合させることを推奨します: ここ radsec-<your RADIUSaaS instance name>.radius-as-a-service.com
任意のFQDNを指定できます。.で ダウンロードファイル形式 を PEM
を選択 証明書チェーンを含める に設定し、証明書をダウンロードしてください。
リクエストを送信 して新しいサーバー証明書をダウンロードします。
重要: パスワードはCertificate Masterから回復できないため、一時的にメモしておいてください。

上記の手順で作成した新しいサーバー証明書を RADIUSaaS
にアップロードするには、次に移動してください: RADIUSaaSインスタンス > 設定 > サーバー設定 > 追加 その後
を選択 PEMまたはPKCS#12エンコードされた証明書 (ステップ5でPKCS#12を選択した場合、これには公開鍵と秘密鍵の両方が含まれます)
証明書ファイルをドラッグ&ドロップするか、参照して選択してください。
のパスワードを入力してください 秘密鍵
をクリック 保存

注意: デフォルトでは、SCEPman Certificate Masterは有効期間が730日の証明書を発行します。これを変更したい場合は、SCEPmanの ドキュメント.
を参照してください。
証明書の有効化
サーバー証明書の有効期限を監視し、サービス中断を防ぐために適時更新してください。 証明書は時折期限切れになりますし、どの証明書を使用するかの好みが変わることもあります。サーバーが使用する証明書を管理できることが重要です。 アクティブ 列にはサーバーが現在使用している証明書が表示されます。サーバーが使用する証明書を変更するには、選びたい証明書の行を展開し、.
有効化
をクリックしてください。 ダウンロード サーバー証明書をダウンロードするための方法は2つあります:
をクリック 上部のCA証明書をダウンロード をクリックします。これにより現在のアクティブなサーバー証明書の 信頼されたルートCA が直接ダウンロードされます。 アクティブ サーバー証明書のルートCAが直接ダウンロードされます。
対応する行の ダウンロード アイコンをクリックしてください。

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

いずれのオプションでも、ダウンロードされるルート証明書はbase64(PEM)でエンコードされています。デバイス(例:WiFiコントローラー)がバイナリ(DER)を必要とする場合は、 OpenSSL:
削除
証明書を削除するには、対応する行を展開し、 削除 をクリックして選択を確認してください。
証明書の有効期限
RADIUSサーバー証明書を期限切れにしないでください。認証が失敗します。
証明書は時折期限切れになります。証明書の有効期限の5か月前には、ダッシュボードに警告アイコンが表示されて通知されます。

アクティブなRADIUSサーバー証明書の横に三角形が表示されている場合は、次の手順に従って更新してください:
サーバー証明書の更新SCEPman接続
SCEPman接続設定は、RaaSインスタンスをSCEPmanインスタンスに直接接続するよう設計されています。この接続を構成すると、RaaSは次のタスクを実行します:
新しいサーバー証明書を作成および有効化する
このサーバー証明書の管理および更新プロセスを管理します。

この接続を確立するには、次の手順に従ってください:
表示されているAPIトークンをコピーしてください。
このガイドに従って、SCEPmanのApp Serviceに移動し、新しい環境変数を作成してください: この ガイドに従い、先ほどコピーしたトークンを値として使用して、次の名前の環境変数を作成してください。 AppConfig:RADIUSaaSValidation:Token 先ほどコピーしたTokenを値として使用してください。
設定を適用し、App Serviceを再起動してください。
SCEPmanインスタンスのURLをSCEPman URLフィールドに入力してください。

をクリック 接続を設定。この操作により現在のサーバー証明書が無効化され、新しく作成された証明書が管理可能になります。
セットアップ完了後、2つの新しいボタンが表示され、以前のボタンと置き換わります。

証明書のローテーション。このボタンは利用可能な2つのスロット間でサーバー証明書をローテートして有効化します。 Servercertificate-upload0 および Servercertificate-upload1.
接続を削除 。このボタンは以前に構成した接続を削除します。この操作は取り消せないことにご注意ください。接続を削除するとトークンも削除されます。後で接続を再設定する場合は、上記の手順を再度実行する必要があります。
最終更新
役に立ちましたか?