Avamar: Session Security
Summary: Este artigo descreve o que é o Session Security no Avamar, como ele funciona e como gerenciá-lo.
Instructions
Session Security: Guia de segurança do produto
Os Avamar Clients podem usar o Session Security para proteger todas as comunicações entre o Avamar Server e o software Avamar Client. O Avamar Server oferece autenticação no Avamar Client, e o Avamar Client oferece autenticação no Avamar Server.
Os recursos do Session Security incluem melhorias de segurança nas comunicações entre os processos do sistema Avamar.
O Avamar protege todas as comunicações entre os processos do sistema Avamar usando tíquetes de sessão. Para que um processo do Avamar aceite uma transmissão de outro processo do Avamar, é necessário ter um tíquete de sessão válido.
Os tíquetes de sessão têm as seguintes características gerais:
- O tíquete de sessão é criptografado e assinado para oferecer proteção contra modificações
- O tíquete de sessão é válido por um curto período
- Cada tíquete de sessão contém uma assinatura exclusiva e é atribuído a apenas um processo do Avamar
- A integridade de um tíquete de sessão é protegida por criptografia
- Cada nó do sistema Avamar verifica separadamente a assinatura do tíquete de sessão
- Quando necessário, é possível estender uma sessão para além da vida útil do tíquete de sessão
O sistema Avamar instala a chave pública do certificado do servidor em cada Avamar Client registrado no Avamar Server. Os Avamar Clients usam a chave pública para autenticar transmissões do sistema Avamar.
Para clientes que estão registrados no momento, a chave pública do certificado do servidor e outros arquivos de certificado necessários são propagados para o client em até uma hora após a instalação.
O sistema Avamar também compartilha automaticamente o certificado do Avamar Server com os nós de armazenamento do Avamar. O compartilhamento do certificado permite que o nó do utilitário e os nós de armazenamento ofereçam o mesmo certificado para autenticação.
Um certificado de client é gerado quando o Avamar Server registra um Avamar Client.
Depois de gerar um certificado de client, o sistema Avamar usa uma conexão criptografada com o Avamar Client para instalar o certificado no client. O sistema Avamar também armazena a chave pública do certificado do client. A chave pública é usada para autenticar o client em todas as comunicações subsequentes.
Como funciona o Session Security?
O Session Security é ativado no Avamar Server. Quando ele está ativado, os clients, os proxies e os sistemas Data Domain passam por um processo especial de registro de certificado com o Avamar.
Em um client e proxy Windows ou Linux, no momento do registro, eles verão que o Avamar Server tem o Session Security ativado. O Avamar envia sua CA raiz interna ao client (chain.pem) para que o client possa armazená-la e confiar nela. O client gera uma solicitação de assinatura de certificado (CSR). A CSR (avclient.csr) será enviada do client para o processo MCS do Avamar Server, que assinará a CSR e devolverá um par de chaves de certificado ao client (key.pem e cert.pem).
Em um Data Domain, ao conectar o Data Domain ao Avamar ou quando a comunicação SSL for atualizada, o Avamar verá que o Data Domain não tem um certificado assinado por si mesmo nem de outro Avamar validado (imported-host ddboost). O Avamar usará a chave privada SSH do Data Domain para fazer log-in no Data Domain e executar comandos SSH no shell do Data Domain (ddsh). O Avamar obterá a solicitação de assinatura de certificado (CSR) do Data Domain pelo SCP e assinará a CSR com a CA raiz interna do Avamar. Depois que o Data Domain tiver o certificado assinado do Avamar (imported-host ddboost), o Avamar importará a CA raiz que assinou o certificado (chain.pem como imported-ca ddboost/login-auth).
Agora que um client/proxy está registrado e tem os certificados do lado do client necessários para se autenticar no MCS do Avamar, é feita uma tentativa de backup. O Avamar envia uma ordem de trabalho para a escuta Avagent do client ou do proxy, que assume a ordem de trabalho. Em seguida, o client ou o proxy valida e verifica a cadeia de certificados do Avamar Server usando a CA raiz do Avamar que o Avamar importou no client no momento do registro. Da mesma forma, o Avamar autentica o client ou o proxy. Nenhum dado foi transmitido até o momento.
Depois que a autenticação for bem-sucedida, a ordem de trabalho será iniciada e o status dela mudará de "Waiting-Client" para "Running".
Agora, os clients e os proxies finalmente moverão dados para o Avamar e o Data Domain usando o binário avtar instalado neles. O binário avtar transmitirá alguns indicadores que controlam os detalhes de como os dados são movidos e quais dados são movidos.
Quando o avtar de um client ou um proxy se conecta ao GSAN do Avamar, ele deve saber se a verifypeer está ativada. A configuração verifypeer é uma configuração do servidor do GSAN como parte da configuração do Session Security que controla o soquete SSL do GSAN na porta 29000, informando se ele deve ou não exigir certificados de client para cada conexão de entrada. Felizmente, o protocolo TLS 1.2 é implementado, lidando automaticamente com a forma como um client ou um proxy deve apresentar seus certificados de client ao GSAN durante o handshake TLS.
Abaixo, há uma demonstração do handshake TLS mútuo/bidirecional quando a verifypeer está ativada.
Do ponto de vista do client ou do proxy, uma seta apontando para a direita é uma conexão com o Avamar Server. Já uma seta apontando para a esquerda é uma conexão proveniente do Avamar Server para o client.
[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
Quando a verifypeer está desativada, o client não precisa enviar um certificado de client para o 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
A parte importante é que o client ou o proxy obteve os certificados do lado do client necessários para poder realizar um handshake TLS mútuo, se exigido pelo GSAN.
Isso significa que, se a CA raiz interna do Avamar for alterada, o client, o proxy ou o Data Domain deverá fazer com que a nova CA raiz assine certificados para ele.
Depois que o client ou o proxy se conecta ao GSAN com sucesso, ele tenta se conectar ao Data Domain.
O log abaixo mostra um proxy que se conecta ao Data Domain com o avtar. A configuração verifypeer está desativada, mas o Session Security está ativado (modo 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
Como a verifypeer é uma configuração de servidor do GSAN do Avamar, ela não afeta a forma como o avtar se conecta diretamente ao Data Domain se o Session Security está ativado. Isso significa que ocorre um handshake TLS mútuo entre o client ou o proxy e o Data Domain.
O client ou o proxy pode validar a cadeia de certificados do Data Domain porque ele compartilha a mesma CA raiz interna do Avamar que foi importada pelo Avamar no momento do registro do client (ou no momento de edição ou anexo do DD).
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
Após a validação do certificado, o handshake é concluído e os dados de backup são movidos do client para o Data Domain e o Avamar na rede.
Gerenciando configurações do Session Security
Os dois artigos abaixo são usados para gerenciar as configurações do Session Security a partir da linha de comando ou do serviço Web Avinstaller.
000222234 | Avamar: Gerenciar configurações do Session Security a partir da CLI
000222279 | Avamar: Gerencie as configurações do Session Security com o Avinstaller Installation Package (AVP)
Há quatro configurações compatíveis possíveis:
- Disabled
- Mixed-Single
- Authenticated-Single
- Authenticated-Dual
Configurações 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"
Quando o Session Security está desativado, os clients só se conectam ao serviço Avagent do Avamar na porta 28001, e os clients monitoram a porta 28002 do Avagent em busca das solicitações do Avamar.
Um proxy monitora a porta 28009.
A porta 28001 é um soquete TCP simples e não realiza handshakes TLS.
O client se conecta ao GSAN do Avamar na porta 29000 e realiza um handshake TLS unidirecional. Isso significa que, mesmo quando o Session Security está desativado, quando os dados de backup são transferidos entre o client e o Avamar, eles ainda são criptografados em trânsito.
Os certificados para autenticação no software Avamar não são trocados entre o Avamar, os proxies, os clients e o Data Domain.
ConfiguraçõesMixed-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"
O modo Mixed-Single foi mais usado quando o Session Security foi introduzido pela primeira vez no Avamar 7.3, permitindo especificamente que os clients cuja versão não fosse 7.3 ou posterior se registrassem e fizessem backup no Avamar. No momento em que este artigo foi escrito, o Avamar 19.10 é a versão mais recente e, basicamente, o modo Mixed-Single será igual ao próximo modo a ser discutido: Authenticated-Single.
ConfiguraçõesAuthenticated-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"
Nesse modo, o Session Security é ativado e os certificados são transmitidos entre o Avamar, os clients, os proxies e o Data Domain para autenticação antes de um backup.
Agora, os clients monitoram a porta 30002 em busca de solicitações de ordem de trabalho do Avagent do Avamar, e os proxies monitoram a porta 30009. O Avamar monitora as portas 30001 e 30003 em busca de solicitações de conexão de clients e proxies. Esses são soquetes SSL que realizam handshakes TLS.
O modo Authenticated-Single força todos os clients a se registrar usando métodos do Session Security, ao contrário do modo Mixed-Single.
Esse modo define a verifypeer no GSAN do Avamar como desativada, o que significa que o GSAN não exigirá certificados de client de uma conexão avtar de entrada.
ConfiguraçõesAuthenticated-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 é igual ao Authenticated-Single, com a exceção de que ativa a configuração verifypeer no serviço GSAN do Avamar.
O modo Authenticated-Dual é considerado a configuração mais sólida a ser aplicada a um Avamar Server e é a seleção padrão durante as implementações do Avamar.
Visão geral: CA raiz autoassinada interna do Avamar
A CA raiz interna do Avamar é uma autoridade de certificação internamente confiável para o Avamar e os clients, proxies e Data Domains que o Avamar importa nela.
O Avamar é a CA interna de si mesmo, pois emite certificados para solicitações de assinatura de certificado (CSRs).
Quando o Avamar usa sua CA raiz para assinar certificados para o GSAN, eles são armazenados na seguinte localização:
/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
Se um scanner de segurança verificar a porta 29000 do Avamar, ele relatará certificados autoassinados nessa porta que processa backups para o GSAN.
Em alguns ambientes, isso pode não ser aceitável, e a recomendação é consultar o artigo abaixo da KB para obter mais informações sobre como substituir a CA raiz interna do Avamar por uma CA raiz interna fornecida pelo usuário.
KB 000204629 | Avamar: Instalar/substituir a autoridade de certificação (CA) do Avamar pela autoridade de certificação (CA) fornecida pelo usuário
O processo detalha como usar o script importcert.sh para instalar uma autoridade de certificação fornecida pelo usuário e interna da empresa dele. A autoridade de certificação fornecida pelo usuário provavelmente é gerenciada pela equipe de segurança, já que nenhuma autoridade de certificação pública informará a chave privada de sua CA, pois é assim que ela ganha dinheiro: assinando certificados para terceiros e mantendo uma cadeia de confiança.
Um exemplo de uma CA interna seria os Serviços de Certificados do Microsoft Active Directory.
O que são os Serviços de Certificados do Active Directory? | Microsoft Learn
Um exemplo de CA pública seria a DigiCert.
A substituição da CA raiz interna do Avamar funciona substituindo o par de chaves raiz do repositório de chaves do Avamar pelo par de chaves da CA fornecido pelo usuário. Em seguida, o GSAN gera uma CSR e uma chave privada, recebe a CSR assinada pelo novo par de chaves da CA, e os arquivos mencionados anteriormente nesta seção são substituídos. O GSAN recarrega o soquete SSL na porta 29000 e os novos clients que se conectam ao GSAN veem a CA fornecida pelo usuário.
Agora, os scanners de segurança mostrarão certificados assinados na porta, e os clients, os proxies e o Data Domain terão que se registrar novamente para obter a nova CA.
Limitações
Os recursos do Session Security do Avamar estão sujeitos a algumas limitações:
- Clients
- Não é possível usar os recursos do Session Security com nenhum dos seguintes Avamar Clients:
- Client de cluster do Avamar para Solaris no Veritas Cluster Server
- Avamar Client para Solaris em clusters do Solaris
- Não é possível usar os recursos do Session Security com nenhum dos seguintes Avamar Clients:
- Outros produtos
- Incentiva-se o uso da sincronização de horário do NTP do Avamar Server, dos Avamar Clients e do sistema Data Domain (se aplicável). Se o horário não estiver sincronizado, poderá ocorrer falha no registro e no backup/restauração devido à validade do certificado e aos períodos de vencimento. A alteração do fuso horário em um host pode ter um impacto semelhante e pode exigir uma nova geração do certificado.
- Token seguro
- A autenticação de token seguro não funciona nas seguintes condições:
- A máquina client está atrás de um dispositivo de firewall de Network Address Translation (NAT)
- O nome de host do client é um nome virtual diferente do FQDN resolvido a partir de seu endereço IP
- A máquina client tem várias interfaces IP, e cada uma é resolvida como um nome de domínio completo (FQDN). Consulte o seguinte artigo da KB para obter mais informações: KB 000056252 | Avamar: Falha no backup do Data Domain com a mensagem "DDR_GET_AUTH_TOKEN" devido a muitos endereços IP (em inglês)
- A autenticação de token seguro não funciona nas seguintes condições:
Planejamento de alterações do Session Security
Antes de fazer uma alteração nas configurações do Session Security, é possível seguir as etapas abaixo para ter a oportunidade de restaurar a configuração ou os certificados anteriores.
Lembre-se de que, se a CA raiz interna do Avamar for alterada, os clients, os proxies e o Data Domain deverão se registrar novamente. Dependendo do tamanho do ambiente (número de clients, proxies e Data Domains), essa tarefa pode ser complicada e se estender por alguns dias.
O caso de uso seria se os certificados fossem gerados novamente e, agora, houvesse falhas de registro e backup.
Com a suposição de que os certificados não venceram nem estão prestes a vencer, e que eles foram gerados novamente talvez por acidente, as seguintes etapas oferecem algumas orientações sobre como evitar uma situação de perda ou indisponibilidade de dados.
Obtenha as configurações atuais do Session Security e as anote:
enable_secure_config.sh --showconfig
Faça uma cópia do repositório de chaves do Avamar:
cp -p /usr/local/avamar/lib/avamar_keystore /usr/local/avamar/lib/x-avamar_keystore-original
Suponha que, agora, os certificados foram gerados novamente usando os métodos AVP ou CLI do Session Security.
Isso significa que o repositório de chaves do Avamar foi alterado e que os certificados do GSAN foram assinados novamente.
O repositório de chaves original do Avamar pode simplesmente ser movido de volta:
cp -p /usr/local/avamar/lib/x-avamar_keystore-original /usr/local/avamar/lib/avamar_keystore
Gere novamente os certificados do GSAN:
enable_secure_config.sh --certs
Reinicie o MCS e o agendador de backup:
mcserver.sh --restart --force dpnctl start sched
Isso restabelece a CA raiz interna original do Avamar, na qual os clients, os proxies e o Data Domain já confiavam.
Solução de problemas
Na maioria das vezes, alterar as configurações do Session Security ou gerar certificados novamente é algo simples.
Esta seção tem como objetivo abordar como fazer com que tudo funcione novamente depois que os certificados são gerados novamente ou as configurações são alteradas.
Atualizações locais
No cenário em que a verifypeer está ativada, quando todos os certificados do Avamar são gerados novamente, os certificados de client usados pelo avtar e pelo avmgr do Avamar Server não são atualizados imediatamente.
Isso significa que, quando o MCS executa uma atualização agendada (backup da configuração do MCS no GSAN), o processo apresenta falha devido a um erro de handshake TLS. Isso ocorre porque os certificados de client do avtar em execução no Avamar Server ainda não receberam a CA raiz interna do Avamar atualizada e o novo conjunto de certificados de client assinados.
Consulte o seguinte artigo da KB para obter mais informações:
000214340 | Avamar: O avtar não consegue se conectar ao serviço GSAN do Avamar: "Fatal server connection problem, aborting initialization. Verify correct server address and login credentials" (em inglês)
Replicação
No cenário em que a verifypeer está ativada no destino de replicação e os certificados são gerados novamente no destino, é necessário adotar uma abordagem semelhante à da seção "Atualizações locais" acima.
Primeiramente, certifique-se de que o Avagent do destino de replicação esteja registrado para que possa aceitar ordens de trabalho de replicação.
No destino, verifique o log do Avagent na seguinte localização:
/usr/local/avamar/var/client/avagent.log
Um log íntegro pode ter esta aparência:
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
Ao analisar o final do log, pode haver um novo registro bem-sucedido recente:
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
Um log não íntegro com problemas de registro causados por alterações de certificado pode ter esta aparência:
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.
Nesse caso, para forçar o novo registro do Avagent no MCS imediatamente, é necessário seguir estas etapas:
Obter o nome da conta MC_SYSTEM, que provavelmente será o FQDN do Avamar:
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
Desativar a conta MC_SYSTEM:
mccli client edit --name=/MC_SYSTEM/<avamar_fqdn> --activated=false example: mccli client edit --name=/MC_SYSTEM/avamar.lab --activated=false
Registrar novamente a conta MC_SYSTEM:
/etc/init.d/avagent register <avamar_fqdn> /MC_SYSTEM example: /etc/init.d/avagent register avamar.lab /MC_SYSTEM
Depois que o registro for bem-sucedido, o Avagent poderá aceitar a replicação no destino.
Agora, no Avamar de origem, se a verifypeer estiver ativada no Avamar que é destino da replicação, nós deveremos gerar novamente os certificados de client usados para se conectar ao Avamar de destino.
Semelhante ao artigo da KB 000214340 | Avamar: O avtar não consegue se conectar ao serviço GSAN do Avamar: "Fatal server connection problem, aborting initialization. Verify correct server address and login credentials" (em inglês).
Remova a pasta existente de certificados do Avamar de destino da sessão SSH do Avamar de origem:
rm -r /usr/local/avamar/etc/<destination_avamar_ip_address> rm -r /usr/local/avamar/etc/client/<destination_avamar_ip_address>
Gere novamente os certificados de client:
/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
É possível testar a comunicação com o Avamar de destino a partir da linha de comando SSH do Avamar de origem:
avmgr logn --id=repluser --ap=<destination_repluser_password> --hfsaddr=<destination_avamar_ip_address> --debug --x19=1024 --x30=8192
Registro do client
É possível tentar fazer backups depois de alterar as configurações do Session Security ou gerar novamente os certificados.
Isso pode levar à localização de muitos clients baseados em agente no status "Waiting-Client" até que não seja possível fazer backup com o erro "Timed-Out Start".
Após a geração dos novos certificados, deve levar cerca de 23 horas para que o client tente se registrar novamente automaticamente.
É possível usar o comando abaixo no Avamar Server para enviar um convite para que clients baseados em agente se registrem novamente no Avamar MCS.
mccli client re-register-all
O comando pode levar algum tempo, dependendo do número de clients, pois envia um convite para cada um deles em ordem sequencial. Considere executar o comando em segundo plano caso a sessão SSH atinja o tempo de espera excedido.
nohup mccli client re-register-all &
Observe que isso pode não funcionar para registrar novamente todos os clients baseados em agente, e alguns talvez precisem ser registrados novamente manualmente.
O processo manual para registrar um client novamente no Windows seria:
- Remover o conteúdo do seguinte diretório, que contém os certificados de client antigos:
-
"C:\Program Files\avs\etc"
-
- Reiniciar o serviço "Backup Agent":
- Remover o conteúdo do seguinte diretório, que contém os certificados de client antigos:
-
/usr/local/avamar/etc
-
- Reiniciar o serviço Avagent:
-
service avagent restart
-
Também é possível reinicializar a máquina client para tentar acionar um novo registro completo.
Observe que a resolução de nomes desempenha um papel importante no registro de clients quando o Session Security está ativado. Certifique-se de que os clients possam realizar uma pesquisa direta e inversa de DNS do Avamar Server e vice-versa. É possível fazer isso configurando entradas de host ou registros de DNS A no client.
O Avamar não oferece qualquer tipo de script que possa entrar em contato com todos os clients conectados para realizar um novo registro manual; o comando mccli mencionado anteriormente é o que chega o mais perto de fazer isso.
Registro de proxy
As máquinas virtuais que são submetidas a backup no Avamar usando proxies têm um certa vantagem quando se trata de alterações de segurança pós-sessão, pois geralmente há muito menos proxies do que clients baseados em agente.
Os proxies também devem tentar um novo registro automático dentro de 23 horas, mas pode ser mais fácil e rápido registrá-los novamente imediatamente.
Há algumas opções disponíveis para tentar forçar um novo registro nos proxies.
A primeira opção pode ser reinicializar os proxies com o seguinte comando:
mccli mcs reboot-proxy --all
A segunda opção seria usar a ferramenta Goav para gerenciar os proxies.
Defina a senha do proxy para a ferramenta Goav para que ela possa fazer log-in nos proxies sempre que precisar. O comando abaixo não altera a senha do SO do proxy; ele simplesmente armazena a senha criptografada para que a ferramenta Goav possa usá-la para fazer log-in no proxy sempre que precisar via SSH.
./goav proxy set-password
Reinicie o Avagent em todos os proxies conectados:
./goav proxy exec "service avagent restart"
Para verificar o log do Avagent no proxy e ver se ocorreu um novo registro bem-sucedido, execute o seguinte comando:
./goav proxy exec "grep -i registration /usr/local/avamarclient/var/avagent.log"
O resultado bem-sucedido pode ser semelhante ao seguinte:
============== 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.
A terceira opção é abrir uma sessão SSH no proxy e executar o script de inicialização:
/usr/local/avamarclient/etc/initproxyappliance.sh start
Sincronização do Data Domain
Após a alteração das configurações do Session Security ou a nova geração de certificados no Avamar, será necessário ressincronizar o Data Domain ou restabelecer a conexão SSL.
O artigo abaixo da KB aborda esse cenário e como trocar os novos certificados com o Data Domain.
000197106 | Integração entre Avamar e Data Domain: DD exibido em vermelho na AUI do Avamar e/ou no caminho de resolução da interface do usuário
É altamente recomendável lidar com a solução de problemas de SSL do Avamar e do Data Domain com a ferramenta Goav.
Com a Goav, é possível diagnosticar e resolver automaticamente a conexão SSL do Data Domain com o Avamar. Consulte o seguinte artigo da KB com mais informações:
000215679 | Avamar: Informações sobre o recurso Goav dd check-ssl
Execute o seguinte comando para corrigir automaticamente os certificados do Avamar e do Data Domain:
./goav dd check-ssl --fix