Avamar: 세션 보안

세션 보안이란 무엇입니까?

세션 보안: 제품 보안 가이드

Avamar Client는 세션 보안을 사용하여 Avamar Server와 Avamar Client 소프트웨어 간의 모든 통신을 보호할 수 있습니다. Avamar Server는 Avamar Client에 인증을 제공하고 Avamar Client는 Avamar Server에 인증을 제공합니다.

세션 보안 기능에는 Avamar 시스템 프로세스 간의 통신에 대한 보안 개선 사항이 포함됩니다.

Avamar는 세션 티켓을 사용하여 Avamar 시스템 프로세스 간의 모든 통신을 보호합니다. Avamar 프로세스에서 다른 Avamar 프로세스로부터의 전송을 수락하려면 유효한 세션 티켓이 필요합니다.

세션 티켓에는 다음과 같은 일반적인 특성이 있습니다.

• 세션 티켓은 수정을 방지하기 위해 암호화되고 서명됩니다.
• 세션 티켓의 유효 기간은 짧습니다.
• 각 세션 티켓에는 고유한 서명이 포함되어 있으며 하나의 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(Certificate Signing Request)을 생성합니다. CSR(avclient.CSR)은 클라이언트에서 Avamar Server의 MCS 프로세스로 전송되며, 이 프로세스는 CSR에 서명하고 인증서 키 쌍을 클라이언트(key.pem 및 cert.pem)에 제공합니다.

Data Domain에서는 Data Domain을 Avamar에 연결하거나 SSL 통신을 새로 고치면, Avamar는 Data Domain 자체 서명된 인증서 또는 다른 검증된 Avamar(가져온 호스트 ddBoost)의 서명된 인증서가 없음을 확인합니다. Avamar는 Data Domain ssh 개인 키를 사용하여 Data Domain에 로그인해 ddsh(Data Domin Shell)를 통해 SSH 명령을 실행합니다. Avamar는 SCP를 통해 Data Domain CSR(Certificate Signing Request)을 가져오고 Avamar 내부 루트 CA로 CSR에 서명합니다. Data Domain에 Avamar(가져온 호스트 ddBoost)에서 서명된 인증서가 있으면, Avamar는 인증서에 서명한 루트 CA(imported-ca ddboost/login-auth인 chain.pem)를 가져옵니다.

이제 클라이언트/프록시가 등록되고 Avamar의 MCS를 인증하는 데 필요한 클라이언트 측 인증서를 보유하고 있으며 백업을 시도합니다. Avamar는 작업 오더를 클라이언트 또는 작업 오더를 선택하는 프록시의 Avagent 수신기에 전송합니다. 그런 다음 클라이언트 또는 프록시는 등록 시 Avamar가 클라이언트로 가져온 Avamar 루트 CA를 사용하여 Avamar Server의 인증서 체인을 검증하고 확인합니다. 마찬가지로 Avamar는 클라이언트 또는 프록시를 인증합니다. 이 시점에 전달된 데이터는 없습니다.

인증에 성공하면 작업 오더가 시작되고 작업 오더의 상태가 'Waiting-Client'에서 'Running'으로 변경됩니다.

이제 클라이언트 및 프록시는 설치된 avtar 바이너리를 사용하여 Avamar 및 Data Domain으로 데이터를 이동합니다. Avtar 바이너리는 데이터 이동 방법과 이동하는 데이터의 세부 정보를 제어하는 일부 플래그를 전달합니다.

클라이언트 또는 프록시의 avtar가 Avamar의 GSAN에 접속하려면 verifypeer가 활성화되었는지 여부를 알아야 합니다. Verifypeer 설정은 들어오는 모든 연결에 대해 클라이언트 인증서가 필요한지 여부를 알려주어 포트 29000에서 GSAN의 SSL 소켓을 제어하는 세션 보안 구성의 일부인 GSAN 서버 설정입니다. 다행히도 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로 네트워크에서 이동합니다.


세션 보안 설정 관리

다음 두 문서는 명령줄 또는 Avinstaller 웹 서비스에서 세션 보안 설정을 관리하는 데 사용됩니다.

000222234| Avamar: CLI에서 세션 보안 설정 관리
000222279 | Avamar: AVP(Avinstaller Installation Package)를 사용하여 세션 보안 설정 관리
 

다음과 같은 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 서비스에만 연결되고, 클라이언트는 avagent 포트 28002에서 Avamar의 요청을 수신 대기합니다.

프록시는 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"

Mixed-Single 모드는 세션 보안이 Avamar 7.3에 처음 도입되었을 때 더 많이 사용되었으며, 특히 버전이 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 간에 인증서가 전달됩니다.

이제 클라이언트는 포트 30002에서 Avamar의 avagent 작업 오더 요청을 수신 대기하고, 프록시는 포트 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은 Avamar의 GSAN 서비스에서 verifypeer 설정을 사용할 수 있다는 점을 제외하고는 Authenticated-Single과 동일합니다.

Authenticated-Dual은 Avamar Server에 적용할 수 있는 가장 강력한 설정으로 간주되며 Avamar 구축 시 기본 선택 항목입니다.


개요: Avamar 내부 자체 서명 루트 CA

Avamar 내부 루트 CA는 Avamar와 Avamar가 가져오는 클라이언트, 프록시 및 Data Domain에 대해 내부적으로 신뢰할 수 있는 인증 기관입니다.

Avamar는 CSR(Certificate Signing Requests)에 대한 인증서를 발급하기 때문에 자체 내부 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(Certificate Authority)를 사용자 제공 CA(Certificate Authority)로 설치/교체

프로세스에서는 importcert.sh 스크립트를 사용하여 회사 내부에 사용자 제공 인증 기관을 설치하는 방법에 대해 자세히 설명합니다. 사용자 제공 인증 기관은 다른 사람의 인증서에 서명하고 신뢰 체인을 유지하여 수익을 얻는 만큼 CA에 대한 개인 키를 제공하지 않으므로 보안 팀에서 관리할 가능성이 높습니다.

내부 CA의 사례로는 Microsoft Active Directory Certificate Services가 있습니다.
Active Directory 인증서 서비스란 무엇입니까? | Microsoft Learn

공개 CA의 사례로는 DigiCert가 있습니다.

Avamar 내부 루트 CA를 교체하려면 Avamar 키 저장소의 루트 키 쌍을 사용자가 제공한 CA 키 쌍으로 교체합니다. 그러면 GSAN은 CSR 및 개인 키를 생성하고, 새 CA 키 쌍에서 서명된 CSR을 가져오며 이 섹션의 앞부분에서 언급된 파일이 대체됩니다. GSAN은 포트 29000에서 SSL 소켓을 다시 로드하고 GSAN에 연결하는 새 클라이언트에 사용자가 제공한 CA가 표시됩니다.

이제 보안 스캐너는 포트에 서명된 인증서를 표시하고 클라이언트, 프록시 및 Data Domain을 다시 등록해야 새로운 CA를 얻을 수 있습니다.


제한 사항

Avamar 세션 보안 기능은 다음과 같은 몇 가지 제한 사항이 적용됩니다.

• 클라이언트
  • 다음 Avamar Client에는 세션 보안 기능을 사용할 수 없습니다.
    • Veritas Cluster Server 기반의 Avamar Cluster Client for Solaris
    • Solaris 클러스터의 Avamar Client for Solaris
• 기타 제품
  • Avamar Server, Avamar Client 및 Data Domain 시스템(해당하는 경우)의 NTP 시간 동기화를 사용하는 것이 좋습니다. 시간이 동기화되지 않으면 인증서 유효 기간 및 만료 시간으로 인해 등록 및 백업/복원 오류가 발생할 수 있습니다. 호스트에서 시간대를 변경하면 유사한 영향이 있을 수 있으며 인증서를 다시 생성해야 할 수도 있습니다.
• 보안 토큰
  • 다음 조건에서는 보안 토큰 인증이 작동하지 않습니다.
    • 클라이언트 컴퓨터가 NAT(Network Address Translation) 방화벽 디바이스 뒤에 있는 경우
    • 클라이언트의 호스트 이름이 IP 주소에서 확인된 FQDN과 다른 가상 이름인 경우
    • 클라이언트 컴퓨터에 여러 개의 IP 인터페이스가 있으며 각각 다른 FQDN(Fully Qualified Domain Name)으로 확인된 경우. 자세한 내용은 다음 KB를 참조하십시오. KB 000056252 | Avamar: 너무 많은 IP 주소로 인해 "DDR_GET_AUTH_TOKEN" 메시지와 함께 Data Domain에 대한 백업 실패 메시지 표시

세션 보안 변경 계획

세션 보안 설정을 변경하기 전에 다음 단계를 수행하여 변경 전에 이전 구성 또는 인증서를 복원할 수 있습니다.

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 

Session Security 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 및 Backup Scheduler를 재시작합니다.

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.

이 경우 avagent를 MCS에 강제로 즉시 다시 등록하려면 다음 단계를 수행해야 합니다.

Avamar FQDN일 가능성이 있는 MC_SYSTEM 계정 이름을 가져옵니다.

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에서 대상에 대한 복제를 승인할 수 있습니다.

이제 복제 대상에서 verifypeer가 활성화되어 있으면 소스 Avamar에서 대상 Avamar에 연결하는 데 사용되는 클라이언트 인증서를 다시 생성해야 합니다.

다음 KB 문서와 유사합니다. 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

두 번째 옵션은 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.

세 번째 옵션은 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를 사용하면 Avamar와의 Data Domain SSL 연결을 자동으로 진단하고 해결할 수 있습니다. 자세한 내용은 다음 KB 문서를 참조하십시오.

000215679 | Avamar: Goav dd check-ssl 기능에 관한 정보

다음 명령을 실행하여 Avamar 및 Data Domain 인증서를 자동으로 수정합니다.

./goav dd check-ssl --fix