「Avamar：セッション セキュリティ

セッション セキュリティとは

セッション セキュリティ：製品セキュリティ ガイド

Avamar Clientは、セッション セキュリティを使用して、Avamar ServerとAvamar Clientソフトウェア間のすべての通信を保護できます。Avamar ServerはAvamar Clientに認証を提供し、Avamar ClientはAvamar Serverに認証を提供します。

セッション セキュリティの機能には、Avamarシステム プロセス間の通信に対するセキュリティ強化が含まれます。

Avamarは、セッション チケットを使用して、Avamarシステム プロセス間のすべての通信を保護します。Avamarプロセスが別のAvamarプロセスからの送信を受け入れるには、有効なセッション チケットが必要です。

セッション チケットには、次の一般的な特性があります。

• セッション チケットは暗号化および署名され、変更から保護されます。
• セッション チケットは短時間有効です。
• 各セッション チケットには一意の署名が含まれ、1つのAvamarプロセスにのみ割り当てられます。
• セッション チケットの整合性は、暗号化によって保護されます。
• 各Avamarシステム ノードは、セッション チケットの署名を個別に検証します。
• 必要に応じて、セッション チケットの有効期間を超えてセッションを延長できます。

Avamarは、プライベート認証局として機能し、Avamarシステム用に一意のサーバー証明書を生成します。

Avamarシステムは、Avamar Serverに登録されているすべてのAvamar Clientにサーバー証明書の公開キーをインストールします。Avamar Clientは、公開キーを使用してAvamarシステムからの送信を認証します。

現在登録されているクライアントの場合、サーバー証明書の公開キーとその他の必要な証明書ファイルは、インストールから1時間以内にクライアントに伝搬されます。

また、Avamarシステムは、Avamar Server証明書をAvamarストレージ ノードと自動的に共有します。証明書を共有すると、ユーティリティー ノードとストレージ ノードで同じ証明書を認証に使用できるようになります。

クライアント証明書は、Avamar ServerにAvamar Clientを登録するときに生成されます。

クライアント証明書を生成した後、AvamarシステムはAvamar Clientとの暗号化された接続を使用して、クライアントに証明書をインストールします。Avamarシステムには、クライアント証明書の公開キーも格納されます。公開キーは、後続のすべての通信でクライアントを認証するために使用されます。


セッション セキュリティの仕組み

セッション セキュリティをAvamar Serverで有効にすると、クライアント、プロキシ、Data Domainシステムは、Avamarで特別な証明書登録プロセスを実行します。

WindowsまたはLinuxのクライアントおよびプロキシでは、登録時に、Avamar Serverでセッション セキュリティが有効になっているか確認します。Avamarは、内部ルートCAをクライアント(chain.pem)に送信し、クライアントがそれを保存して信頼できるようにします。クライアントは証明書署名要求(CSR)を生成します。CSR (avclient.csr)がクライアントからAvamar ServerのMCSプロセスに送信されると、CSRに署名し、証明書キーペア（key.pemとcert.pem）をクライアントに返します。

Data Domainでは、Data DomainをAvamarに接続するか、SSL通信が更新されると、AvamarはData Domainにそれ自体または別の検証済みAvamarからの署名済み証明書(imported-host ddboost)がないことを確認します。Avamarは、Data Domainのsshプライベート キーを使用してData Domainにログインし、Data Dominシェル(ddsh)を介してsshコマンドを実行します。AvamarはSCPを介してData Domain証明書署名要求(CSR)を取得し、Avamar内部ルートCAを使用してCSRに署名します。Data DomainがAvamarからの署名済み証明書(imported-host ddboost)を取得すると、Avamarは証明書に署名したルートCAをインポートします（chain.pemをimported-ca ddboost/login-authとして）。

クライアント/プロキシが登録され、AvamarのMCSでの認証に必要なクライアント側の証明書が取得されたため、バックアップが試行されます。Avamarは、クライアントまたはプロキシのAvagentリスナーに作業オーダーを送信し、そのリスナーが作業オーダーを受け取ります。次に、クライアントまたはプロキシは、登録時にAvamarがクライアントにインポートしたAvamarルートCAを使用して、Avamar Serverの証明書チェーンを検証および検証します。同様に、Avamarはそのクライアントまたはプロキシを認証します。この時点では、データは渡されていません。

認証が成功すると、作業オーダーが開始し、作業オーダーのステータスが「Waiting-Client」から「Running」に変わります。

最終的に、クライアントとプロキシは、AvamarとData Domainにインストールされているavtarバイナリーを使用してデータを移動します。avtarバイナリーは、データの移動方法と移動されるデータの詳細を制御するいくつかのフラグを渡します。

クライアントまたはプロキシ上のavtarがAvamarのGSANに接続する際に、verifypeerが有効になっているかどうかを確認する必要があります。verifypeer設定は、セッション セキュリティ構成の一部であるGSANサーバー設定に含まれ、すべての着信接続にクライアント証明書を要求するかどうかを指示することによって、ポート29000でGSANのSSLソケットを制御します。TLS 1.2プロトコルが実装されているため、TLSハンドシェイク中にクライアントまたはプロキシがクライアント証明書をgsanに提示する方法を自動的に処理します。

次に、verifypeerが有効な場合のTLS相互/双方向ハンドシェイクのデモを示します。
クライアントまたはプロキシの観点から、右向きの矢印はAvamar Serverへの接続です。また、左向きの矢印は、Avamar Serverからクライアントへの接続です。
 

[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, ClientHello
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, ServerHello
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, Certificate
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, ServerKeyExchange
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, CertificateRequest
[avtar]  <-- TLS 1.2 Handshake, ServerHelloDone
[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, Certificate
[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, ClientKeyExchange
[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, CertificateVerify
[avtar]  --> SSL
[avtar]  --> TLS 1.2 ChangeCipherSpec
[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, Finished
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 ChangeCipherSpec
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, Finished

verifypeerが無効になっている場合、クライアントはクライアント証明書をGSANに送信する必要はありません。
 

[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, ClientHello
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, ServerHello
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, Certificate
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, ServerKeyExchange
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, ServerHelloDone
[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, ClientKeyExchange
[avtar]  --> SSL
[avtar]  --> TLS 1.2 ChangeCipherSpec
[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, Finished
[avtar]  <-- SSL 
[avtar]  <-- TLS 1.2 ChangeCipherSpec
[avtar]  <-- SSL 
[avtar]  <-- TLS 1.2 Handshake, Finished

重要なのは、クライアントまたはプロキシが、GSANによって要求された場合に相互TLSハンドシェイクを実行できるように、必要なクライアント側の証明書を取得していることです。

つまり、Avamar内部ルートCAが変更された場合、クライアント、プロキシ、またはData Domainは、証明書に署名するために新しいルートCAを取得する必要があります。

クライアントまたはプロキシは、GSANに正常に接続した後、Data Domainへの接続を試みます。

次のログは、avtarを使用してData Domainに接続するプロキシを示しています。verifypeer設定は無効ですが、セッション セキュリティは有効になっています（Authenticated-Singleモード）。 
 

2024-02-22 17:37:32 avtar Info <40058>: - Client connecting to the Avamar Server using authentication, client connecting to the Data Domain system using two-way authentication
2024-02-22 17:37:33 avtar Info <44068>: - Data Domain Engine Set FIPS OFF
2024-02-22 17:37:33 avtar Info <16684>: - Data Domain Engine (7.11.0.0 build 1033042)
2024-02-22 17:37:33 avtar Info <40174>: Multi-stream restore via cloning is enabled.
2024-02-22 17:37:33 avtar Info <10632>: Using Client-ID='6bf19b025be80a12da2e7b932da60079709906ae'
2024-02-22 17:37:33 avtar Info <40062>: GSAN connected via: IPv4, retrieved Data Domain IPv4 hostname = lab.dd.com
2024-02-22 17:37:33 avtar Info <10539>: Connecting to Data Domain Server "lab.dd.com"(1)  (LSU: avamar-1704339590) with auth token
2024-02-22 17:37:33 avtar Info <10540>: - Resolved Data Domain Server name "lab.dd.com" to the IP address "10.x.x.x"
2024-02-22 17:37:33 avtar Info <41236>: - Connecting to Data Domain Server name "lab.dd.com" with token:e2602cc64ce8c4782ca877cabe355191042d0fb4
2024-02-22 17:37:33 avtar Info <0000>: - Connecting to:
DataDomain:           lab.dd.com
encryption strength:  2
auth_mode:            2
client_cert           /usr/local/avamarclient/etc/cert.pem
client_key:           /usr/local/avamarclient/etc/key.pem
server_cert:          /tmp/.tmp_avamar/MOD-1708623043157#1_65d7865c_68ce32dc.pem
chain_cert:           /usr/local/avamarclient/etc/chain.pem

verifypeerはAvamar GSANサーバー設定に含まれるため、セッション セキュリティが有効になっている場合、avtarがData Domainに直接接続する方法には影響しません。これは、クライアントまたはプロキシとData Domainの間で相互TLSハンドシェイクが発生することを意味します。

クライアントまたはプロキシは、クライアント登録時（またはDDの編集時または接続時）にAvamarによってインポートされた同じAvamar内部ルートCAを共有しているため、Data Domain証明書チェーンを検証できます。
 

Proxy
------
Avamar internal root CA
/usr/local/avamarclient/etc/chain.pem


Data Domain
--------------
Avamar internal root CA
run command to view certificate list on DD: adminaccess certificate show
imported-ca ddboost


/usr/local/avamarclient/etc/chain.pem == imported-ca ddboost

証明書の検証後、ハンドシェイクが完了し、バックアップ データがクライアントからネットワーク上のData DomainおよびAvamarに移動します。


セッション セキュリティ設定の管理

次の2つの記事では、コマンド ラインまたはAvinstaller Webサービスからセッション セキュリティ設定を管理する方法について説明しています。

000222234 - 「Avamar：CLIからのセッション セキュリティ設定の管理」
000222279 - 「Avamar：Avinstallerインストール パッケージ(AVP)を使用したセッション セキュリティ設定の管理」
 

次の4つの構成がサポートされます。

1. Disabled
2. Mixed-Single
3. Authenticated-Single
4. Authenticated-Dual

Disabled

設定：

Current Session Security Settings
----------------------------------
"encrypt_server_authenticate"                           ="false"
"secure_agent_feature_on"                               ="false"
"session_ticket_feature_on"                             ="false"
"secure_agents_mode"                                    ="unsecure_only"
"secure_st_mode"                                        ="unsecure_only"
"secure_dd_feature_on"                                  ="false"
"verifypeer"                                            ="no"

セッション セキュリティが無効になっている場合、クライアントはポート28001でのみAvamarのAvagentサービスに接続し、クライアントはAvamarからのリクエストをAvagentポート28002でリスンします。

プロキシは28009でリスンします。

ポート28001はプレーンTCPソケットで、TLSハンドシェイクは実行しません。

クライアントはポート29000でAvamar GSANに接続し、一方向のTLSハンドシェイクを実行します。つまり、セッション セキュリティが無効になっている場合でも、バックアップ データがクライアントとAvamar間で転送されると、転送中に暗号化されます。

Avamarソフトウェアを使用した認証用の証明書は、Avamar、プロキシ、クライアント、Data Domainの間では交換されません。


Mixed-Single

設定：

Current Session Security Settings
----------------------------------
"encrypt_server_authenticate"                           ="true"
"secure_agent_feature_on"                               ="true"
"session_ticket_feature_on"                             ="true"
"secure_agents_mode"                                    ="mixed"
"secure_st_mode"                                        ="mixed"
"secure_dd_feature_on"                                  ="true"
"verifypeer"                                            ="no"

Avamar 7.3でセッション セキュリティが導入された当初は、Mixed-Singleモードが多く使用されていました。具体的には、バージョン7.3以降ではないクライアントでAvamarへの登録とバックアップが可能でした。この記事の執筆時点では、Avamar 19.10が最新バージョンであり、Mixed-Singleは基本的に次に説明するモードAuthenticated-Singleと同じです。


Authenticated-Single

設定：

Current Session Security Settings
----------------------------------
"encrypt_server_authenticate"                           ="true"
"secure_agent_feature_on"                               ="true"
"session_ticket_feature_on"                             ="true"
"secure_agents_mode"                                    ="secure_only"
"secure_st_mode"                                        ="secure_only"
"secure_dd_feature_on"                                  ="true"
"verifypeer"                                            ="no"

このモードでは、セッション セキュリティが有効になっており、バックアップ前の認証のために、Avamar、クライアント、プロキシ、Data Domainの間で証明書が渡されます。

これでクライアントは、AvamarからのAvagent作業オーダー要求をポート30002でリスンし、プロキシはポート30009でリスンできるようになります。Avamarは、クライアントおよびプロキシからの接続要求をポート30001および30003でリスンします。これらは、TLSハンドシェイクを実行するSSLソケットです。

Authenticated-Singleモードでは、Mixed-Singleモードとは異なり、すべてのクライアントがセッション セキュリティ方式を使用して登録するように強制されます。

このモードでは、AvamarのGSANでverifypeerが無効に設定されます。つまり、GSANはインバウンドavtar接続からのクライアント証明書を必要としません。


Authenticated-Dual

設定：

Current Session Security Settings
----------------------------------
"encrypt_server_authenticate"                           ="true"
"secure_agent_feature_on"                               ="true"
"session_ticket_feature_on"                             ="true"
"secure_agents_mode"                                    ="secure_only"
"secure_st_mode"                                        ="secure_only"
"secure_dd_feature_on"                                  ="true"
"verifypeer"                                            ="yes"

Authenticated-DualはAuthenticated-Singleと同じですが、AvamarのGSANサービスでverifypeer設定が有効になる点が異なります。

Authenticated-Dualは、Avamar Serverに適用する最も強力な設定と見なされており、Avamar導入時のデフォルトの選択です。


概要：Avamar内部自己署名ルートCA

Avamar内部ルートCAは、Avamarと、Avamarがインポートするクライアント、プロキシ、Data Domainに対して、内部的に信頼できる認証局です。

Avamarは証明書署名要求(CSR)の証明書を発行するため、それ自体が内部CAです。

AvamarがそのルートCAを使用してGSANの証明書に署名する場合、証明書は次の場所に保存されます。
 

/home/admin/chain.pem
/home/admin/cert.pem
/home/admin/key.pem

/usr/local/avamar/etc/chain.pem
/usr/local/avamar/etc/cert.pem
/usr/local/avamar/etc/key.pem

セキュリティ スキャナーがAvamarのポート29000をスキャンすると、バックアップを処理するポート上の自己署名証明書がGSANに報告されます。

一部の環境では、これが受け入れられない場合があります。Avamar内部ルートCAをユーザー指定の内部ルートCAに置き換える方法の詳細については、次のKB記事を参照することをお勧めします。

KB 000204629 - 「Avamar：Avamar認証局(CA)をユーザー指定の認証局(CA)に交換する方法（英語）」

このプロセスでは、importcert.shスクリプトを使用して、社内にユーザー指定の認証局をインストールする方法について詳しく説明します。ユーザーが指定した認証局は、セキュリティ チームによって管理されている可能性が高くなります。これは、パブリック認証局がそのCAのプライベート キーを配布しないためです（他のユーザーの証明書に署名し、信頼チェーンを維持することで収益を得るため）。

内部CAの例としては、Microsoft Active Directory証明書サービスがあります。
『Active Directory 証明書サービスとは| Microsoft Learn』

パブリックCAの例としては、DigiCertがあります。

Avamar内部ルートCAの交換は、Avamarキーストアのルート キーペアをユーザーが指定したCAキーペアに置き換えることで機能します。次に、GSANはCSRとプライベート キーを生成し、新しいCAキーペアによって署名されたCSRを取得し、このセクションで前述したファイルが置き換えられます。GSANは、ポート29000でSSLソケットを再ロードし、GSANに接続する新しいクライアントにはユーザー指定のCAが提示されます。

これで、セキュリティ スキャナーにポート上の署名済み証明書が表示されるため、クライアント、プロキシ、Data Domainを再登録して新しいCAを取得する必要があります。


制限

Avamarセッション セキュリティ機能には、次のような制限があります。

• クライアント
  • セッション セキュリティ機能は、次のAvamarクライアントでは使用できません。
    • Veritas Cluster Server上のSolaris向けAvamarクラスター クライアント
    • Solarisクラスター内のSolaris向けAvamar Client
• その他の製品
  • Avamar Server、Avamar Client、Data Domainシステム（該当する場合）のNTPによる時刻同期の使用が推奨されます。時刻が同期されていないと、証明書の有効性と有効期限が原因で、登録とバックアップ/リストアが失敗する可能性があります。ホストのタイム ゾーンを変更しても同様の影響があり、証明書の再生成が必要になる場合があります。
• セキュア トークン
  • セキュア トークン認証は、次の条件下では機能しません。
    • クライアント マシンは、Network Address Translation (NAT)ファイアウォール デバイスの背後にあります
    • クライアントのホスト名は、IPアドレスから解決されたFQDNとは異なる仮想名です。
    • クライアント マシンには複数のIPインターフェイスがあり、それぞれが異なる完全修飾ドメイン名(FQDN)に解決されます。詳細については、次のKBを参照してください：KB 000056252 - 「Avamar：IPアドレスが多すぎるため、Data Domainへのバックアップがメッセージ「DDR_GET_AUTH_TOKEN」で失敗する（英語）」

セッション セキュリティ変更計画

セッション セキュリティ設定を変更する前に、次の手順を実行して、変更を行う前に以前の構成または証明書を復元することができます。

Avamar内部ルートCAが変更された場合は、クライアント、プロキシ、Data Domainを再登録する必要があることに注意してください。環境のサイズ（クライアント、プロキシ、Data Domainの数）によっては、このタスクが煩雑になり、数日に及ぶこともあります。

このユース ケースは、証明書が再生成され、登録とバックアップに失敗した場合に適用されます。

証明書の有効期限が切れていない、または期限切れ間近でなく、偶然に再生成されたことを前提として、次の手順では、データ ロスやデータ欠損の状況を防ぐ方法についてのガイダンスを提供します。

現在のセッション セキュリティ設定を取得し、メモします。

enable_secure_config.sh --showconfig

Avamarキーストアのコピーを作成します。

cp -p /usr/local/avamar/lib/avamar_keystore /usr/local/avamar/lib/x-avamar_keystore-original 

セッション セキュリティのAVPまたはCLIメソッドを使用して、証明書が再生成されたとします。

これは、Avamarキーストアが変更され、GSAN証明書が再署名されたことを意味します。

元のAvamarキーストアは、次のように簡単に元に戻すことができます。

cp -p /usr/local/avamar/lib/x-avamar_keystore-original /usr/local/avamar/lib/avamar_keystore

GSAN証明書を再生成します。

enable_secure_config.sh --certs

MCSとバックアップ スケジューラーを再起動します。

mcserver.sh --restart --force
dpnctl start sched

これにより、クライアント、プロキシ、Data Domainがすでに信頼していた元のAvamar内部ルートCAが復元されます。


トラブルシューティング

ほとんどの場合、セッション セキュリティ設定の変更や証明書の再生成は簡単です。

このセクションでは、証明書が再生成された後、または設定が変更された後に、すべてを再び機能させる方法について説明します。

ローカル フラッシュ

verifypeerが有効になっているシナリオでは、すべてのAvamar証明書が再生成されると、Avamar Serverのavtarとavmgrが使用するクライアント証明書はすぐには更新されません。

つまり、MCSがスケジュールされたフラッシュ（GSANへのMCS構成のバックアップ）を実行すると、TLSハンドシェイクの失敗が原因で失敗します。これは、Avamar Serverで実行されているavtarのクライアント証明書が、更新されたAvamar内部ルートCAと署名済みクライアント証明書の新しいセットをまだ取得していないためです。

詳細については、次のKBを参照してください。

000214340 - 「Avamar：AvtarがAvamarのGSANサービスに接続できない - 「Fatal server connection problem, aborting initialization.Verify correct server address and login credentials」エラー（英語）」

レプリケーション

レプリケーション ターゲットでverifypeerが有効になっていて、ターゲットで証明書が再生成されたシナリオでは、前述の「ローカル フラッシュ」セクションと同様のアプローチを取る必要があります。

まず、レプリケーション作業オーダーを受け入れることができるように、レプリケーション ターゲットのAvagentが登録されていることを確認します。

ターゲットで、次の場所にあるAvagentログを確認します。

/usr/local/avamar/var/client/avagent.log

正常なログは次のようになります。

2024-02-22 15:31:57 avagent Info <5964>: Requesting work from avamar.lab
2024-02-22 15:31:57 avagent Info <5264>: Workorder received: sleep
2024-02-22 15:31:57 avagent Info <5996>: Sleeping 15 seconds
2024-02-22 15:32:12 avagent Info <40019>: Checking certificate status.
2024-02-22 15:32:12 avagent Info <43701>: agent_message::resolve_client_ip ping to MCS avamar.lab:10.x.x.x using local IP:10.x.x.x failed, timed out on receive


2024-02-22 15:32:12 avagent Info <5964>: Requesting work from avamar.lab
2024-02-22 15:32:12 avagent Info <5264>: Workorder received: sleep
2024-02-22 15:32:12 avagent Info <5996>: Sleeping 15 seconds

ログをさらに遡ると、最近成功した再登録がある可能性があります。

2024-02-22 15:09:00 avagent Info <7502>: Registration of client /MC_SYSTEM/avamar.lab with MCS avamar.lab:30001 successful.
2024-02-22 15:09:00 avagent Info <5928>: Registration of plugin 1008 Replicate successful.
2024-02-22 15:09:00 avagent Info <5928>: Registration of plugin 1038 vmir successful.
2024-02-22 15:09:00 avagent Info <5928>: Registration of plugin 1046 Migrate successful.
2024-02-22 15:09:00 avagent Info <5928>: Registration of plugin 1051 Tiering successful.
2024-02-22 15:09:00 avagent Info <5619>: Registration of client and plugins complete.
2024-02-22 15:09:00 avagent Info <5996>: Sleeping 60 seconds

証明書の変更が原因で発生した登録の問題を含む異常なログは、次のようになります。

2024-02-22 15:04:57 avagent Error <40012>: Avamar server certificate verification error 7 at depth 0: certificate signature failure
2024-02-22 15:04:57 avagent Error <5365>: Cannot connect to 10.x.x.x:30001.
2024-02-22 15:04:57 avagent Info <5059>: unable to connect, sleep(60) then retrying
2024-02-22 15:05:57 avagent Error <40012>: Avamar server certificate verification error 7 at depth 0: certificate signature failure
2024-02-22 15:05:57 avagent Error <5365>: Cannot connect to 10.x.x.x:30001.
2024-02-22 15:05:57 avagent Info <5059>: unable to connect, sleep(60) then retrying
2024-02-22 15:06:57 avagent Error <40012>: Avamar server certificate verification error 7 at depth 0: certificate signature failure
2024-02-22 15:06:57 avagent Error <5365>: Cannot connect to 10.x.x.x:30001.

このインスタンスで、AvagentをMCSに直ちに強制的に再登録するには、次の手順を実行する必要があります。

MC_SYSTEMアカウント名を取得します。これは、Avamar FQDNである可能性が高いです。

mccli client show --domain=/MC_SYSTEM | grep MC_SYSTEM | awk '{print $1}'

example:
root@avamar:/usr/local/avamar/lib/#: mccli client show --domain=/MC_SYSTEM | grep MC_SYSTEM | awk '{print $1}'
avamar.lab

MC_SYSTEMアカウントを非アクティブ化します。

mccli client edit --name=/MC_SYSTEM/<avamar_fqdn> --activated=false

example:
mccli client edit --name=/MC_SYSTEM/avamar.lab --activated=false

MC_SYSTEMアカウントを再登録します。

/etc/init.d/avagent register <avamar_fqdn> /MC_SYSTEM

example:
/etc/init.d/avagent register avamar.lab /MC_SYSTEM

登録に成功すると、Avagentはターゲットでレプリケーションを受け入れることができます。

ここで、レプリケーション ターゲットのAvamarでverifypeerが有効になっている場合は、ソースAvamarで、ターゲットAvamarへの接続に使用するクライアント証明書を再生成する必要があります。

KB 000214340 - 「Avamar：AvtarがAvamarのGSANサービスに接続できない - 「Fatal server connection problem, aborting initialization.Verify correct server address and login credentials」エラー（英語）」を参照してください。

ソースAvamarのsshセッションから既存のターゲットAvamar証明書フォルダーを削除します。

rm -r /usr/local/avamar/etc/<destination_avamar_ip_address>

rm -r /usr/local/avamar/etc/client/<destination_avamar_ip_address>

クライアント証明書を再生成します。

/usr/local/avamar/bin/avagent.bin --gencerts=true --mcsaddr=<destination_avamar_ip_address>

/usr/local/avamar/bin/avagent.bin --gencerts=true --mcsaddr=<destination_avamar_ip_address> --sysdir=/usr/local/avamar/etc/client

ターゲットAvamarへの通信は、ソースAvamarのsshコマンド ラインからテストできます。

avmgr logn --id=repluser --ap=<destination_repluser_password> --hfsaddr=<destination_avamar_ip_address> --debug --x19=1024 --x30=8192

クライアント登録

セッション セキュリティ設定を変更するか、証明書を再生成した後に、バックアップが試行される場合があります。

これにより、「Timed-Out Start」でバックアップに失敗するまで、「Waiting-Client」ステータスのエージェント ベース クライアントが多数検出される可能性があります。

新しい証明書が再生成された後、クライアントが自動的に再登録を試みるまでに約23時間かかります。

Avamar Serverで次のコマンドを使用すると、エージェント ベース クライアントがAvamar MCSに再登録するための招待状を送信できます。

mccli client re-register-all

このコマンドは、各クライアントに順番に招待状を送信するため、クライアントの数に応じて時間がかかる場合があります。sshセッションがタイムアウトした場合に備えて、バックグラウンドでコマンドを実行することを検討してください。

nohup mccli client re-register-all &

これは、すべてのエージェント ベース クライアントを再登録できるとは限らず、一部のクライアントを手動で再登録する必要があることに注意してください。

Windowsでクライアントを手動で再登録するプロセスは次のとおりです。

• 古いクライアント証明書が含まれている次のディレクトリーの内容を削除します。

  • "C:\Program Files\avs\etc"

• 「Backup Agent」サービスを再起動します。

Linuxでクライアントを手動で再登録するプロセスは次のとおりです。

• 古いクライアント証明書が含まれている次のディレクトリーの内容を削除します。

  • /usr/local/avamar/etc

• Avagentサービスを再起動します。

  • service avagent restart

クライアント マシンを再起動して、完全な再登録をトリガーすることもできます。

セッション セキュリティが有効になっている場合、名前解決はクライアントの登録において重要な役割を果たします。クライアントがAvamar Serverの正引きおよび逆引きDNSルックアップを実行できることを確認してください。これは、クライアントでDNS Aレコードまたはホスト エントリーを構成することで実現できます。

Avamarには、接続されているすべてのクライアントにアクセスして手動で再登録を実行できるスクリプトはありませんが、前述のmccliコマンドがそれに最も近いコマンドです。

プロキシ登録

プロキシを使用してAvamarにバックアップされた仮想マシンは、通常エージェント ベース クライアントよりもプロキシの数がはるかに少ないため、セッション セキュリティの変更後に関しては多少有利です。

また、プロキシは23時間以内に自動再登録を試みるはずですが、すぐに再登録する方が簡単で早い場合があります。

プロキシで強制的に再登録を試みるには、いくつかのオプションがあります。

最初のオプションは、次のコマンドでプロキシを再起動することです。

mccli mcs reboot-proxy --all

2つ目のオプションは、Goavツールを使用してプロキシを管理することです。

Goavツールのプロキシ パスワードを設定して、必要なときにいつでもプロキシにログインできるようにします。次のコマンドは、プロキシのOSパスワードを変更しません。単にパスワードを暗号化して保存するため、Goavツールは、必要時にいつでもsshを介してプロキシにログインできます。

./goav proxy set-password

接続されているすべてのプロキシでAvagentの再起動を実行します。

./goav proxy exec "service avagent restart"

プロキシのAvagentログをチェックして、再登録に成功したかどうかを確認するには、次のコマンドを実行します。

./goav proxy exec "grep -i registration /usr/local/avamarclient/var/avagent.log"

成功した場合の出力は次のようになります。

============== proxy.lab.emc.com =========================
Executing grep -i registration /usr/local/avamarclient/var/avagent.log on proxy.lab.emc.com
2024-02-23 17:54:06 avagent Info <18918>: Registration: Processing secure registration with the MCS.
2024-02-23 17:54:06 avagent Info <18923>: Registration: Certificate files are present.
2024-02-23 17:54:09 avagent Info <5470>: Updating registration information with the MCS (10.x.x.x), paging enabled
2024-02-23 17:54:09 avagent Info <7501>: Client registration updated 3cbe29134da771ac547b7105743e66633ff12d40 10.x.x.x(1704339590)
2024-02-23 17:54:09 avagent Info <7502>: Registration of client /clients/proxy.lab.emc.com with MCS 10.x.x.x:30001 successful.
2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 1019 vmwfilel successful.
2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 3019 vmwfilew successful.
2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 1016 vmimagel successful.
2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 3016 vmimagew successful.
2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 1001 Unix successful.
2024-02-23 17:54:09 avagent Info <5619>: Registration of client and plugins complete.

3番目のオプションは、プロキシにssh接続し、初期化スクリプトを実行することです。

/usr/local/avamarclient/etc/initproxyappliance.sh start

Data Domainの同期

セッション セキュリティ設定が変更された後、またはAvamarで証明書が再生成された後に、Data Domainを再同期するか、SSL接続を再確立する必要があります。

次のKB記事では、このシナリオと、新しい証明書をData Domainで交換する方法について説明します。

000197106 - 「AvamarとData Domainの統合：DDがAvamar AUIまたはユーザー インターフェイスの解決パスで赤色を表示する」

AvamarおよびData Domain SSLのトラブルシューティングには、Goavツールを使用して処理することを強くお勧めします。

Goavを使用すると、Data Domain SSLとAvamarの接続を自動的に診断して解決できます。詳細については、次のKBを参照してください。

000215679 - 「Avamar：Goav dd check-ssl機能に関する情報」

次のコマンドを実行して、AvamarおよびData Domainの証明書を自動的に修正します。

./goav dd check-ssl --fix