Avamar：工作階段安全性

什麼是工作階段安全性？

工作階段安全性：產品安全性指南

Avamar 用戶端可以使用工作階段安全性來保護 Avamar Server 和 Avamar 用戶端軟體之間的所有通訊。Avamar Server 會提供 Avamar 用戶端的驗證，Avamar 用戶端則會提供 Avamar Server 的驗證。

工作階段安全性功能包括 Avamar 系統程序之間通訊的安全性改善。

Avamar 會使用工作階段工單來保護 Avamar 系統程序之間的所有通訊。Avamar 程序接受來自其他 Avamar 程序的傳輸之前，必須具備有效的工作階段工單。

工作階段工單具有以下一般特徵：

• 工作階段工單經過加密及簽署以防止遭到修改
• 工作階段工單的有效時間很短
• 每個工作階段工單包含唯一簽名，並僅指派給一個 Avamar 程序
• 工作階段工單的完整性受到加密保護
• 每個 Avamar 系統節點會個別驗證工作階段工單簽名
• 如果需要，工作階段可以延長到工作階段工單的壽命之外

Avamar 會作為私人認證機構，並為 Avamar 系統產生唯一的伺服器憑證。

Avamar 系統會在每一個向 Avamar Server 註冊的 Avamar 用戶端上安裝伺服器憑證的公開金鑰。Avamar 用戶端使用公開金鑰來驗證來自 Avamar 系統的傳輸。

對於目前已註冊的用戶端，伺服器憑證的公開金鑰和其他必需的憑證檔案將在安裝後一小時內傳播到用戶端。

Avamar 系統也會自動與 Avamar 儲存節點共用 Avamar Server 憑證。共用憑證允許公用程式節點和儲存節點提供相同的憑證進行驗證。

當 Avamar Server 註冊 Avamar 用戶端時，會產生用戶端憑證。

產生用戶端憑證後，Avamar 系統會使用與 Avamar 用戶端的加密連線，在用戶端上安裝憑證。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 Shell (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 設定，但工作階段安全性已啟用 (驗證-單一模式)。 
 

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 交握。

用戶端或代理可以驗證 Data Domain 憑證鏈結，因為它共用 Avamar 在用戶端註冊時 (或 DD 編輯或附加時間) 匯入的相同 Avamar 內部根 CA。
 

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。


管理工作階段安全性設定

以下兩篇文章用於從命令行或 Avinstaller Web 服務管理工作階段安全性設定。

000222234 | Avamar：從 CLI
000222279 管理工作階段安全性設定 |Avamar：使用 Avinstaller 安裝套裝 (AVP) 管理工作階段安全性設定
 

有四種可能支援的組態：

1. 已停用
2. 混合-單一
3. 經過驗證-單一
4. 經過驗證-雙重

已停用

設定：

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 服務，且用戶端會在 Avagent 連接埠 28002 上接聽來自 Avamar 的要求。

代理會在 28009 上接聽。

連接埠 28001 是純 TCP 插槽，不執行 TLS 交握。

用戶端會連線至連接埠 29000 上的 Avamar GSAN，並執行單向 TLS 交握。這表示即使停用工作階段安全性，在用戶端和 Avamar 之間傳輸備份資料時，仍會對流動中備份資料進行加密。

Avamar、代理、用戶端和 Data Domain 之間不會交換用於驗證 Avamar 軟體的憑證。


混合-單一

設定：

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 中首次導入工作階段安全性時，會更常使用混合-單一模式，特別是為了允許版本不是 7.3 或更新版本的用戶端註冊並備份至 Avamar。在撰寫本文時，Avamar 19.10 是最新版本，混合-單一基本上與下一個要討論的模式相同；經過驗證-單一。


經過驗證-單一

設定：

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 之間傳遞憑證，以便在備份之前進行驗證。

用戶端現在會在連接埠 30002 上接聽來自 Avamar 的 Avagent 工作訂單要求，而代理則會在連接埠 30009 上接聽。Avamar 會在連接埠 30001 和 30003 上接聽來自用戶端和代理的連線要求。這些是執行 TLS 交握的 SSL 插槽。

與混合-單一模式不同，經過驗證-單一模式會強制所有用戶端使用工作階段安全性方法註冊。

此模式會將 Avamar 的 GSAN 上的 verifypeer 設為停用，表示 GSAN 不需要來自輸入 avtar 連線的用戶端憑證。


經過驗證-雙重

設定：

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"

經過驗證-雙重與經過驗證-單一相同，差異只在它在 Avamar 的 GSAN 服務上啟用 verifypeer 設定。

經過驗證-雙重被視為是套用至 Avamar Server 最強的設定，也是 Avamar 部署期間的預設選項。


概觀：Avamar 內部自我簽署根 CA

Avamar 內部根 CA 是 Avamar 的內部信任認證機構以及 Avamar 匯入其中的用戶端、代理和 Data Domain。

Avamar 是其自身的內部 CA，因為它會核發憑證簽署要求 (CSR) 的憑證。

當 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 備份的連接埠上的自我簽署憑證。

在某些環境中，這可能是不可接受的，建議參閱下列 KB 文章，以取得將 Avamar 內部根 CA 更換為使用者提供的內部根 CA 的詳細資訊。

KB 000204629 | Avamar：以使用者提供的認證機構 (CA) 安裝/更換 Avamar 認證機構 (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 叢集伺服器上 Solaris 的 Avamar 叢集用戶端
    • Solaris 叢集中 Solaris 的 Avamar 用戶端
• 其他產品
  • 建議使用 Avamar Server、Avamar 用戶端和 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 執行排定的排清 (將 MCS 組態備份至 GSAN) 時，將會因為 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.

在此情況下，若要立即向 MCS 強制重新註冊 Avagent，必須採取下列步驟：

取得 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 上，如果在複寫目的地 Avamar 上已啟用 verifypeer，我們必須重新產生用來連線至目的地 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 ssh 命令行測試與目的地 Avamar 的通訊：

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

用戶端註冊

變更工作階段安全性設定或重新產生憑證後，即可嘗試備份。

這可能會導致發現許多代理程式型用戶端處於「Waiting-Client」狀態，直到出現「Timed-Out Start」無法備份為止。

重新產生新憑證後，用戶端大約需要 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

第二個選項是使用 Goav 工具來管理代理。

為 Goav 工具設定代理密碼，以便它可以根據需要隨時登入代理。下列命令不會變更代理的作業系統密碼，它只是將加密的密碼儲存起來，讓 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.

第三個選項是 ssh 至代理並執行初始化指令檔：

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

Data Domain 同步

在 Avamar 上變更工作階段安全性設定或重新產生憑證後，必須重新同步 Data Domain 或重新建立 SSL 連線。

下列 KB 文章涵蓋此案例，以及如何與 Data Domain 交換新憑證。

000197106 | Avamar 和 Data Domain 整合：DD 在 Avamar AUI 和/或使用者介面解決方案路徑中顯示紅色

強烈建議使用 Goav 工具進行 Avamar 和 Data Domain SSL 故障診斷。

有了 Goav，就可以自動診斷和解決 Data Domain 與 Avamar 的 SSL 連線，請參閱下列 KB 以獲得更多資訊：

000215679 | Avamar：Goav dd check-ssl 功能的相關資訊

請執行下列命令以自動修正 Avamar 和 Data Domain 憑證：

./goav dd check-ssl --fix