Avamar: sicurezza delle sessioni
Summary: Questo articolo descrive che cosa è la sicurezza delle sessioni su Avamar, come funziona e come gestirla.
Instructions
Sicurezza delle sessioni: guida alla sicurezza del prodotto
Gli Avamar Client possono utilizzare le funzioni di sicurezza delle sessioni per proteggere tutte le comunicazioni tra l'Avamar Server e il software Avamar Client. L'Avamar Server fornisce l'autenticazione all'Avamar Client e l'Avamar Client fornisce l'autenticazione all'Avamar Server.
Le funzioni di sicurezza delle sessioni includono miglioramenti della sicurezza per le comunicazioni tra i processi del sistema Avamar.
Avamar protegge tutte le comunicazioni tra i processi del sistema Avamar tramite ticket di sessione. È necessario un ticket di sessione valido prima che un processo Avamar accetti una trasmissione da un altro processo Avamar.
I ticket di sessione presentano le seguenti caratteristiche generali:
- Il ticket di sessione è crittografato e firmato per protezione contro eventuali modifiche
- Il ticket di sessione è valido per un breve periodo di tempo
- Ogni ticket di sessione contiene una firma univoca ed è assegnato a un solo processo Avamar
- L'integrità di un ticket di sessione è protetta mediante crittografia
- Ogni nodo del sistema Avamar verifica separatamente la firma del ticket di sessione
- Se necessario, una sessione può essere estesa oltre la durata del ticket di sessione
Il sistema Avamar installa la chiave pubblica per il certificato server su ogni Avamar Client registrato con l'Avamar Server. Gli Avamar Client utilizzano la chiave pubblica per autenticare le trasmissioni provenienti dal sistema Avamar.
Per i client attualmente registrati, la chiave pubblica per il certificato server e gli altri file di certificato richiesti vengono propagati al client entro un'ora dall'installazione.
Il sistema Avamar condivide automaticamente il certificato dell'Avamar Server con gli storage node Avamar. La condivisione del certificato consente all'utility node e agli storage node di fornire lo stesso certificato per l'autenticazione.
Un certificato client viene generato quando l'Avamar Server registra un Avamar Client.
Dopo aver generato un certificato client, il sistema Avamar utilizza una connessione crittografata con l'Avamar Client per installare il certificato sul client. Il sistema Avamar archivia inoltre la chiave pubblica per il certificato client. La chiave pubblica viene utilizzata per autenticare il client in tutte le comunicazioni successive.
Come funziona la sicurezza delle sessioni?
La sicurezza delle sessioni è abilitata sull'Avamar Server. Se abilitata, i client, i proxy e i sistemi Data Domain vengono sottoposti a uno speciale processo di registrazione dei certificati con Avamar.
In un proxy e un client Windows o Linux, al momento della registrazione viene rilevata l'abilitazione della sicurezza delle sessioni sull'Avamar Server. Avamar invia la propria CA root interna al client (chain.pem) in modo che il client possa archiviarla e considerarla attendibile. Il client genera una richiesta di firma del certificato (CSR). La CSR (avclient.csr) viene inviata dal client al processo MCS dell'Avamar Server che firma la CSR e restituisce una coppia di chiavi del certificato al client (key.pem e cert.pem).
In Data Domain, quando si collega Data Domain ad Avamar o quando la comunicazione SSL viene aggiornata, Avamar rileva che Data Domain non dispone di un certificato firmato da se stesso o da un altro Avamar convalidato (imported-host ddboost host). Avamar utilizza la chiave privata SSH di Data Domain per accedere a Data Domain ed eseguire i comandi ssh sulla shell di Data Domain (ddsh). Avamar estrae la richiesta di firma del certificato (CSR) di Data Domain su SCP e firma la CSR con la CA root interna di Avamar. Una volta che Data Domain dispone del certificato firmato da Avamar (imported-host ddboost), Avamar importa la CA root che ha firmato il certificato (chain.pem come imported-ca ddboost/login-auth).
Ora che un client/proxy è registrato e dispone dei certificati lato client necessari per eseguire l'autenticazione con l'Avamar MCS, viene tentato un backup. Avamar invia un'ordine di lavoro al listener avagent del client o del proxy, che preleva l'ordine di lavoro. Il client o il proxy convalida e verifica quindi la catena di certificati dell'Avamar Server utilizzando la CA root di Avamar che Avamar ha importato nel client al momento della registrazione. Allo stesso modo, Avamar autentica il client o il proxy. Fino a questo momento non è stato trasmesso alcun dato.
Dopo l'esito positivo dell'autenticazione, l'ordine di lavoro viene avviato e il relativo stato cambia da "Waiting-Client" a "Running".
Ora, i client e i proxy possono spostare i dati in Avamar e Data Domain utilizzando il binario avtar installato su di essi. Il file binario avtar passa alcuni flag che controllano come e quali i dati vengono spostati.
Quando avtar su un client o un proxy si connette ad Avamar GSAN, deve sapere se verifypeer è abilitato. L'impostazione verifypeer è un'impostazione del server GSAN nell'ambito della configurazione della sicurezza delle sessioni che controlla il socket SSL di GSAN sulla porta 29000 indicando se richiedere o meno i certificati client per ogni connessione in ingresso. Fortunatamente, è implementato il protocollo TLS 1.2 che gestisce automaticamente il modo in cui un client o un proxy presentano i propri certificati client a gsan durante l'handshake TLS.
Di seguito è riportata una dimostrazione dell'handshake TLS reciproco/bidirezionale quando verifypeer è abilitato.
Dal punto di vista del client o del proxy, una freccia che punta a destra indica una connessione all'Avamar Server. Una freccia rivolta verso sinistra indica una connessione proveniente dall'Avamar Server e diretta al 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 verifypeer è disabilitato, il client non è tenuto a inviare un certificato client a 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
L'importante è che il client o il proxy abbiano ottenuto i certificati lato client necessari per poter eseguire un handshake TLS reciproco, se richiesto da GSAN.
Ciò significa che, se la CA root interna di Avamar cambia, il client, il proxy o Data Domain deve ottenere la nuova CA root per firmare i certificati.
Dopo essersi connesso correttamente a GSAN, il client o il proxy tenta di connettersi a Data Domain.
Il seguente registro mostra un proxy che si connette a Data Domain con avtar. L'impostazione verifypeer è disabilitata, ma la sicurezza delle sessioni è abilitata (modalità 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
Poiché verifypeer è un'impostazione dell'Avamar GSAN Server, non influisce sul modo in cui avtar si connette direttamente a Data Domain se la sicurezza delle sessioni è abilitata. Ciò significa che si verifica un handshake TLS reciproco tra il client o il proxy e Data Domain.
Il client o il proxy può convalidare la catena di certificati Data Domain perché condivide la stessa CA root interna di Avamar che è stata importata da Avamar al momento della registrazione del client (o al momento della modifica o del collegamento di 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
Dopo la convalida del certificato, l'handshake viene completato e i dati di backup vengono spostati dal client a Data Domain e Avamar sulla rete.
Gestione delle impostazioni di sicurezza delle sessioni
Per gestire le impostazioni di sicurezza delle sessioni dalla riga di comando o dal servizio web Avinstaller, è possibile utilizzare i due articoli seguenti:
000222234 | Avamar: gestione delle impostazioni di sicurezza delle sessioni dalla CLI (in inglese)
000222279 | Avamar: gestione delle impostazioni di sicurezza delle sessioni con AVP (Avinstaller Installation Package) (in inglese)
Le configurazioni supportate disponibili sono quattro:
- Disabled
- Mixed-Single
- Authenticated-Single
- Authenticated-Dual
Disabled
Impostazioni:
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 la sicurezza delle sessioni è disabilitata, i client si connettono al servizio avagent di Avamar sulla porta 28001 e sono in ascolto sulla porta avagent 28002 per le richieste provenienti da Avamar.
Un proxy è in ascolto sulla porta 28009.
La porta 28001 è un socket TCP normale e non esegue handshake TLS.
Il client si connette ad Avamar GSAN sulla porta 29000 ed esegue un handshake TLS unidirezionale. Ciò significa che anche se la sicurezza delle sessioni è disabilitata, quando i dati di backup vengono trasferiti tra il client e Avamar, vengono comunque crittografati in esecuzione.
I certificati per l'autenticazione con il software Avamar non vengono scambiati tra Avamar, proxy, client e Data Domain.
Mixed-Single
Impostazioni:
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"
La modalità Mixed-Single era maggiormente utilizzata al momento dell'introduzione iniziale della sicurezza delle sessioni in Avamar 7.3, consentendo in particolare ai client la cui versione era diversa dalla 7.3 o successive di registrarsi ed eseguire il backup su Avamar. Al momento della stesura di questo articolo, la versione più recente di Avamar è la 19.10 e la modalità Mixed-Single è essenzialmente uguale alla modalità successiva di cui tratteremo, ovvero Authenticated-Single.
Authenticated-Single
Impostazioni:
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"
In questa modalità, la sicurezza delle sessioni è abilitata e i certificati vengono trasferiti tra Avamar, client, proxy e Data Domain per l'autenticazione prima di un backup.
I client sono in ascolto sulla porta 30002 per le richieste di ordine di lavoro avagent provenienti da Avamar, mentre i proxy sono in ascolto sulla porta 30009. Avamar è in ascolto sulle porte 30001 e 30003 per le richieste di connessione provenienti da client e proxy. Si tratta di socket SSL che eseguono handshake TLS.
La modalità Authenticated-Single obbliga tutti i client a registrarsi utilizzando metodi di sicurezza delle sessioni, a differenza della modalità Mixed-Single.
Questa modalità disabilita l'impostazione verifypeer su Avamar GSAN, il che significa che GSAN non richiederà certificati client da una connessione avtar in entrata.
Authenticated-Dual
Impostazioni:
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 è uguale ad Authenticated-Single, tranne per il fatto che abilita l'impostazione verifypeer sul servizio Avamar GSAN.
Authenticated-Dual è considerata l'impostazione più avanzata da applicare a un Avamar Server ed è la selezione predefinita durante i deployment di Avamar.
Panoramica: CA root autofirmata interna di Avamar
La CA root interna di Avamar è una CA internamente attendibile per Avamar e per i client, i proxy e i Data Domain che Avamar importa al loro interno.
Avamar è la CA interna per se stesso poiché emette i certificati per le richieste di firma dei certificati (CSR).
Quando Avamar utilizza la propria CA root per firmare i certificati per GSAN, questi vengono archiviati nella seguente posizione:
/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 uno scanner di sicurezza analizza la porta 29000 su Avamar, rileva la presenza di certificati autofirmati su tale porta che elabora i backup su GSAN.
In alcuni ambienti, questa condizione potrebbe non essere accettabile e si consiglia di consultare il seguente articolo della Knowledge Base per ulteriori informazioni sulla sostituzione della CA root interna di Avamar con una CA root interna fornita dall'utente.
KB 000204629 | Avamar: installazione/sostituzione della CA Avamar con una CA fornita dall'utente (in inglese)
La procedura descrive in dettaglio come utilizzare lo script importcert.sh per installare una CA fornita dall'utente interna all'azienda. La CA fornita dall'utente è probabilmente gestita dal team addetto alla sicurezza, in quanto nessuna CA pubblica cederà la chiave privata per la propria CA, essendo questo il modo in cui realizza profitti firmando certificati per altri e mantenendo una catena di attendibilità.
Un esempio di CA interna potrebbe essere Servizi certificati Active Directory di Microsoft.
Informazioni su Servizi certificati Active Directory | Microsoft Learn
Un esempio di CA pubblica potrebbe essere DigiCert.
La sostituzione della CA root interna di Avamar opera sostituendo la coppia di chiavi root nell'archivio chiavi Avamar con la coppia di chiavi della CA fornita dall'utente. Quindi GSAN genera una CSR e una chiave privata, ottiene la CSR firmata dalla nuova coppia di chiavi della CA e i file menzionati in precedenza in questa sezione vengono sostituiti. GSAN ricarica il socket SSL sulla porta 29000 e i nuovi client che si connettono a GSAN fanno riferimento alla CA fornita dall'utente.
Gli scanner di sicurezza mostrano ora i certificati firmati sulla porta e i client, i proxy e Data Domain dovranno ri-registrarsi per ottenere la nuova CA.
Limitazioni
Le funzioni di sicurezza delle sessioni di Avamar sono soggette ad alcune limitazioni:
- Client
- Le funzioni di sicurezza delle sessioni non possono essere utilizzate con i seguenti Avamar Client:
- Avamar Cluster Client per Solaris su Veritas Cluster Server
- Avamar Client per Solaris in cluster Solaris
- Le funzioni di sicurezza delle sessioni non possono essere utilizzate con i seguenti Avamar Client:
- Altri prodotti
- Si consiglia l'utilizzo della sincronizzazione dell'ora NTP dell'Avamar Server, degli Avamar Client e del sistema Data Domain (se applicabile). Se l'ora non è sincronizzata, potrebbe verificarsi un errore di registrazione e di backup/ripristino a causa dei tempi di validità e di scadenza dei certificati. La modifica del fuso orario su un host potrebbe avere un impatto simile e richiedere la rigenerazione del certificato.
- Token protetto
- L'autenticazione con token protetto non funziona nelle seguenti condizioni:
- Il computer client è protetto da un dispositivo firewall NAT (Network Address Translation)
- Il nome host del client è un nome virtuale diverso dal nome FQDN risolto dal relativo indirizzo IP
- Il computer client dispone di più interfacce IP e ognuna viene risolta in un nome FQDN diverso. Per ulteriori informazioni, consultare il seguente articolo della Knowledge Base: KB 000056252 | Avamar: backup su Data Domain non riuscito con messaggio "DDR_GET_AUTH_TOKEN" a causa di un numero eccessivo di indirizzi IP (in inglese)
- L'autenticazione con token protetto non funziona nelle seguenti condizioni:
Pianificazione delle modifiche alla sicurezza delle sessioni
Prima di apportare modifiche alle impostazioni di sicurezza delle sessioni, è possibile effettuare le seguenti operazioni per avere la possibilità di ripristinare la configurazione o i certificati precedenti alle modifiche.
Tenere presente che, se la CA root interna di Avamar viene modificata, i client, i proxy e Data Domain devono registrarsi nuovamente. A seconda delle dimensioni dell'ambiente (numero di client, proxy e Data Domain) questa operazione può essere complessa e durare alcuni giorni.
Il caso d'uso potrebbe essere se i certificati vengono rigenerati e ora sono presenti errori di registrazione e backup.
Se i certificati non sono scaduti o non stanno per scadere e vengono rigenerati magari per errore, i seguenti passaggi offrono alcune indicazioni su come evitare di trovarsi in una situazione di perdita o non disponibilità dei dati.
Ottenere le impostazioni correnti di sicurezza delle sessioni e annotarle:
enable_secure_config.sh --showconfig
Creare una copia dell'archivio chiavi Avamar:
cp -p /usr/local/avamar/lib/avamar_keystore /usr/local/avamar/lib/x-avamar_keystore-original
Si supponga che i certificati vengano ora rigenerati utilizzando i metodi CLI o AVP di sicurezza delle sessioni.
Ciò significa che l'archivio chiavi Avamar è cambiato e che i certificati GSAN sono stati nuovamente firmati.
L'archivio chiavi Avamar originale può essere semplicemente riportato in posizione:
cp -p /usr/local/avamar/lib/x-avamar_keystore-original /usr/local/avamar/lib/avamar_keystore
Rigenerare i certificati GSAN:
enable_secure_config.sh --certs
Riavviare MCS e Backup Scheduler:
mcserver.sh --restart --force dpnctl start sched
In questo modo viene ripristinata la CA root interna di Avamar originale che client, proxy e Data Domain già consideravano attendibili.
Risoluzione dei problemi
Nella maggior parte dei casi, la modifica delle impostazioni di sicurezza delle sessioni o la rigenerazione dei certificati è abbastanza semplice.
Questa sezione ha lo scopo di spiegare come ripristinare il funzionamento generale dopo la rigenerazione dei certificati o la modifica delle impostazioni.
Flush locali
Se verifypeer è abilitato, quando vengono rigenerati tutti i certificati Avamar, i certificati client utilizzati da avtar e avmgr dell'Avamar Server non vengono aggiornati immediatamente.
Di conseguenza, quando MCS esegue un flush pianificato (backup della configurazione MCS in GSAN), l'operazione avrà esito negativo a causa di un errore di handshake TLS. Ciò è dovuto al fatto che i certificati client per avtar in esecuzione sull'Avamar Server non hanno ancora ottenuto la CA root interna di Avamar aggiornata e un nuovo set di certificati client firmati.
Per ulteriori informazioni, consultare il seguente articolo della Knowledge Base:
000214340 | Avamar: avtar non è in grado di connettersi al servizio Avamar GSAN: "Fatal server connection problem, aborting initialization. Verify correct server address and login credentials" (in inglese).
Replica
Se verifypeer è abilitato sulla destinazione di replica e i certificati vengono rigenerati sulla destinazione, è necessario adottare un approccio simile a quello della precedente sezione "Flush locali".
In primo luogo, assicurarsi che avagent nella destinazione di replica sia registrato, in modo tale da poter accettare ordini di lavoro di replica.
Sulla destinazione, controllare il registro avagent nella seguente posizione:
/usr/local/avamar/var/client/avagent.log
Un registro senza errori potrebbe essere simile al seguente:
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
Risalendo più indietro nel registro, potrebbe essere ci potrebbe essere una ri-registrazione recente con esito positivo:
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
Un registro con errori con problemi di registrazione causati da modifiche ai certificati potrebbe essere simile al seguente:
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.
In questo caso, per forzare nuovamente la ri-registrazione immediata di avagent con MCS, è necessario effettuare le seguenti operazioni:
Ottenere il nome dell'account MC_SYSTEM, che probabilmente sarà il nome FQDN 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
Disattivare l'account MC_SYSTEM:
mccli client edit --name=/MC_SYSTEM/<avamar_fqdn> --activated=false example: mccli client edit --name=/MC_SYSTEM/avamar.lab --activated=false
Registrare nuovamente l'account MC_SYSTEM:
/etc/init.d/avagent register <avamar_fqdn> /MC_SYSTEM example: /etc/init.d/avagent register avamar.lab /MC_SYSTEM
Una volta completata la registrazione, avagent può accettare la replica sulla destinazione.
Ora, sull'Avamar di origine, se verifypeer è abilitato sull'Avamar di destinazione della replica, è necessario rigenerare i certificati client utilizzati per connettersi all'Avamar di destinazione.
Come in precedenza, consultare l'articolo della Knowledge Base 000214340 | Avamar: avtar non è in grado di connettersi al servizio Avamar GSAN: "Fatal server connection problem, aborting initialization. Verify correct server address and login credentials" (in inglese).
Rimuovere la cartella dei certificati esistente dell'Avamar di destinazione dalla sessione SSH dell'Avamar di origine:
rm -r /usr/local/avamar/etc/<destination_avamar_ip_address> rm -r /usr/local/avamar/etc/client/<destination_avamar_ip_address>
Rigenerare i certificati 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
La comunicazione con l'Avamar di destinazione può essere testata dalla riga di comando SSH dell'Avamar di origine:
avmgr logn --id=repluser --ap=<destination_repluser_password> --hfsaddr=<destination_avamar_ip_address> --debug --x19=1024 --x30=8192
Registrazione client
È possibile tentare l'esecuzione di backup dopo la modifica delle impostazioni di sicurezza delle sessioni o la rigenerazione dei certificati.
Questa operazione potrebbe individuare numerosi client basati su agent in stato "Waiting-Client" fino all'errore di backup con "Timed-Out Start".
Dopo la rigenerazione dei nuovi certificati, dovrebbero essere necessarie circa 23 ore affinché il client tenti automaticamente di ripetere la registrazione.
È possibile utilizzare il comando seguente sull'Avamar Server per inviare un invito ai client basati su agent a registrarsi nuovamente con Avamar MCS.
mccli client re-register-all
L'esecuzione del comando potrebbe richiedere del tempo a seconda del numero di client, poiché viene inviato un invito a ciascuno di essi in ordine sequenziale. Considerare l'esecuzione del comando in background nel caso in cui si verifichi il timeout della sessione SSH.
nohup mccli client re-register-all &
Si noti che questa operazione potrebbe non funzionare per ri-registrare tutti i client basati su agent e per alcuni potrebbe essere necessario eseguire la ri-registrazione manualmente.
Il processo manuale di ri-registrazione di un client in Windows è il seguente:
- Rimuovere il contenuto della seguente directory contenente i precedenti certificati client:
-
"C:\Program Files\avs\etc"
-
- Riavviare il servizio "Backup Agent"
- Rimuovere il contenuto della seguente directory contenente i precedenti certificati client:
-
/usr/local/avamar/etc
-
- Riavviare il servizio avagent:
-
service avagent restart
-
Per tentare di attivare una ri-registrazione completa, è anche possibile riavviare il computer client.
Si noti che la risoluzione dei nomi svolge un ruolo importante nella registrazione dei client quando la sicurezza delle sessioni è abilitata; assicurarsi che i client possano eseguire una ricerca DNS diretta e inversa dell'Avamar Server e viceversa. Questa operazione può essere eseguita configurando i record A DNS o le voci host sul client.
Avamar non fornisce alcun tipo di script in grado di raggiungere ogni client collegato per eseguire una ri-registrazione manuale; il comando mccli menzionato in precedenza è quello che si avvicina maggiormente a questo scopo.
Registrazione proxy
Le macchine virtuali di cui è stato eseguito il backup su Avamar tramite proxy sono in qualche modo avvantaggiate quando si tratta di modifiche successive alla sicurezza delle sessioni, in quanto in genere i proxy sono molto di meno rispetto ai client basati su agent.
I proxy dovrebbero anche tentare una ri-registrazione automatica entro 23 ore, ma potrebbe essere più facile e veloce ri-registrarli immediatamente.
Sono disponibili alcune opzioni per provare a forzare una ri-registrazione sui proxy.
La prima opzione consiste nel riavviare i proxy con il seguente comando:
mccli mcs reboot-proxy --all
La seconda opzione consiste nell'utilizzare lo strumento Goav per gestire i proxy.
Impostare la password dei proxy per lo strumento Goav in modo che possa accedere ai proxy ogni volta che è necessario. Il seguente comando non modifica la password per il sistema operativo del proxy, ma memorizza semplicemente la password crittografata in modo che lo strumento Goav possa utilizzarla per accedere al proxy ogni volta che deve tramite SSH.
./goav proxy set-password
Eseguire un riavvio di avagent su tutti i proxy collegati:
./goav proxy exec "service avagent restart"
Per controllare l'accesso di avagent al proxy e verificare se la ri-registrazione è riuscita, utilizzare il seguente comando:
./goav proxy exec "grep -i registration /usr/local/avamarclient/var/avagent.log"
L'output di esito positivo potrebbe essere simile a quello riportato di seguito:
============== 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.
La terza opzione consiste nell'accedere tramite SSH al proxy ed eseguire lo script di inizializzazione:
/usr/local/avamarclient/etc/initproxyappliance.sh start
Sincronizzazione di Data Domain
Dopo la modifica delle impostazioni di sicurezza delle sessioni o la rigenerazione dei certificati su Avamar, sarà necessario ri-sincronizzare Data Domain o ristabilire la connessione SSL.
Il seguente articolo della Knowledge Base illustra questo scenario e spiega come scambiare i nuovi certificati con Data Domain.
000197106 | Integrazione di Avamar e Data Domain: DD viene visualizzato in rosso nel percorso di risoluzione di Avamar AUI o dell'interfaccia utente.
Si consiglia di gestire la risoluzione dei problemi SSL di Avamar e Data Domain con lo strumento Goav.
Con Goav la connessione SSL di Data Domain con Avamar può essere sottoposta a diagnosi e risolta automaticamente. Per ulteriori informazioni, consultare il seguente articolo della Knowledge Base:
000215679 | Avamar: informazioni sulla funzione Goav dd check-ssl (in inglese)
Utilizzare il seguente comando per correggere automaticamente i certificati Avamar e Data Domain:
./goav dd check-ssl --fix