Avamar: Sessionssikkerhed

Hvad er sessionssikkerhed?

Sessionssikkerhed: Vejledning

til produktsikkerhedAvamar-klienter kan bruge sessionssikkerhed til at sikre al kommunikation mellem Avamar-serveren og Avamar-klientsoftwaren. Avamar-serveren leverer godkendelse til Avamar-klienten, og Avamar-klienten leverer godkendelse til Avamar-serveren.

Sessionssikkerhedsfunktioner omfatter sikkerhedsforbedringer for kommunikation mellem Avamar-systemprocesser.

Avamar sikrer al kommunikation mellem Avamar-systemprocesserne ved hjælp af sessionsbilletter. Der kræves en gyldig sessionsbillet, før en Avamar-proces accepterer en overførsel fra en anden Avamar-proces.

Sessionsbilletterne har følgende generelle egenskaber:

• Sessionsbilletten krypteres og signeres for at beskytte mod ændringer
• Sessionsbilletten er gyldig i kort tid
• Hver sessionsbillet indeholder en unik signatur og tildeles kun én Avamar-proces
• Integriteten af en sessionsbillet er beskyttet af kryptering
• Hver Avamar-systemnode bekræfter sessionsbilletsignaturen separat
• Når det er nødvendigt, kan en session forlænges ud over sessionsbillettens levetid

Avamar fungerer som et privat nøglecenter og genererer et unikt servercertifikat til Avamar-systemet.

Avamar-systemet installerer den offentlige nøgle til servercertifikatet på alle Avamar-klienter, der er registreret på Avamar-serveren. Avamar-klienter bruger den offentlige nøgle til at godkende overførsler fra Avamar-systemet.

For klienter, der aktuelt er registreret, overføres den offentlige nøgle til servercertifikatet og andre påkrævede certifikatfiler til klienten inden for en time efter installationen.

Avamar-systemet deler også automatisk Avamar-servercertifikatet med Avamar-lagernoderne. Deling af certifikatet gør det muligt for hjælpeprogramnoden og lagernoderne at levere det samme certifikat til godkendelse.

Der genereres et klientcertifikat, når Avamar-serveren registrerer en Avamar-klient.

Efter generering af et klientcertifikat bruger Avamar-systemet en krypteret forbindelse med Avamar-klienten til at installere certifikatet på klienten. Avamar-systemet gemmer også den offentlige nøgle til klientcertifikatet. Den offentlige nøgle bruges til at godkende klienten i al efterfølgende kommunikation.


Hvordan fungerer sessionssikkerhed?

Sessionssikkerhed er aktiveret på Avamar-serveren. Når denne indstilling er aktiveret, gennemgår klienter, proxyer og Data Domain-systemer en særlig certifikatregistreringsproces med Avamar.

På en Windows- eller Linux-klient og proxy ser den på registreringstidspunktet, at Avamar-serveren har Sessionssikkerhed aktiveret. Avamar sender sit interne rodnøglecenter til klienten (chain.pem), så klienten kan gemme og have tillid til den. Klienten genererer en anmodning om certifikatsignering (CSR). CSR (avclient.csr) sendes fra klienten til Avamar-serverens MCS-proces, som underskriver CSR'en og giver klienten et certifikatnøglepar tilbage (key.pem & cert.pem).

Når Data Domain knyttes til Avamar på et Data Domain, eller når SSL-kommunikationen opdateres, kan Data Domain se, at Data Domain ikke har et signeret certifikat fra sig selv eller en anden valideret Avamar (DDDboost med importeret vært). Avamar bruger den private Data Domain ssh-nøgle til at logge på Data Domain for at køre ssh-kommandoer over Data Domin shell (ddsh). Avamar trækker CSR (Data Domain Certificate Signing Request) over SCP og signerer CSR'en med Avamars interne rodnøglecenter. Når Data Domain har det signerede certifikat fra Avamar (imported-host ddboost), importerer Avamar rodnøglecenteret, som signerede certifikatet (chain.pem som importeret-ca ddboost/login-auth).

Nu hvor en klient/proxy er registreret og har de certifikater på klientsiden, der kræves for at godkende med Avamars MCS, forsøges en sikkerhedskopiering. Avamar sender en arbejdsordre til klientens eller proxyens Avagent-lyttefunktion, som henter arbejdsordren. Klienten eller proxyen validerer og verificerer derefter Avamar-serverens certifikatkæde ved hjælp af Avamar-rodnøglecenteret, som Avamar importerede til klienten på registreringstidspunktet. På samme måde godkender Avamar klienten eller proxyen. Ingen data er blevet videregivet på nuværende tidspunkt.

Når godkendelsen er gennemført, starter arbejdsordren, og arbejdsordrens status ændres fra 'Venter-klient' til 'Kører'.

Nu flytter klienter og proxyer til sidst data til Avamar og Data Domain ved hjælp af den avtar-binære fil, der er installeret på dem. Avtar-binæren sender nogle flag, der styrer detaljerne om, hvordan dataene flyttes, og hvilke data der flyttes.

Når avtar på en klient eller proxy opretter forbindelse til Avamars GSAN, skal den vide, om verifypeer er aktiveret. Verifypeer-indstillingen er en GSAN-serverindstilling som en del af sessionssikkerhedskonfigurationen, der styrer GSAN's SSL-sokkel på port 29000 ved at fortælle den, om der skal kræves klientcertifikater for hver indgående forbindelse. Heldigvis er TLS 1.2-protokollen implementeret, som automatisk håndterer, hvordan en klient eller proxy skal præsentere deres klientcertifikater for gsan under TLS-håndtrykket.

Følgende er en demonstration af det gensidige TLS-håndtryk/tovejshåndtryk, når verifypeer er aktiveret.
Fra klient- eller proxysynspunktet er en pil, der peger mod højre, en forbindelse til Avamar-serveren. En pil, der peger til venstre, er en forbindelse, der kommer fra Avamar-serveren til klienten.
 

[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

Når verifypeer er deaktiveret, er klienten ikke forpligtet til at sende et klientcertifikat til 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

Den vigtige del er, at klienten eller proxyen har de nødvendige certifikater på klientsiden for at kunne udføre et gensidigt TLS-håndtryk, hvis det kræves af GSAN.

Det betyder, at hvis det interne nøglecenter i Avamar ændres, skal klienten, proxyen eller Data Domain hente det nye rodnøglecenter til at signere certifikater for dem.

Når klienten eller proxyen har oprettet forbindelse til GSAN, forsøger den at oprette forbindelse til Data Domain.

Følgende log viser en proxy, der opretter forbindelse til Data Domain med avtar. Indstillingen verifypeer er deaktiveret, men sessionssikkerhed er aktiveret (Authenticated-Single mode). 
 

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

Da verifypeer er en Avamar GSAN-serverindstilling, påvirker det ikke, hvordan avtar opretter forbindelse direkte til Data Domain, hvis sessionssikkerhed er aktiveret. Det betyder, at der forekommer et gensidigt TLS-håndtryk mellem klienten eller proxyen og Data Domain.

Klienten eller proxyen kan validere Data Domain-certifikatkæden, fordi den deler det samme interne Avamar-rodnøglecenter, som blev importeret af Avamar på klientregistreringstidspunktet (eller DD-redigerings- eller vedhæftningstidspunktet).
 

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

Når certifikatet er valideret, fuldføres handshaket, og sikkerhedskopieringsdata flyttes fra klienten til Data Domain og Avamar på netværket.


Administration af sessionssikkerhedsindstillinger

Følgende to artikler bruges til at administrere indstillingerne for sessionssikkerhed enten fra kommandolinjen eller Avinstaller-webtjenesten.

000222234 | Avamar: Administrer sikkerhedsindstillinger for sessioner fraCLI-000222279
| Avamar: Administrer sessionssikkerhedsindstillinger med Avinstaller Installation Package (AVP)
 

Der er fire mulige understøttede konfigurationer:

1. Disabled
2. Blandet-Single
3. Godkendt-enkelt
4. Godkendt-dobbelt

Deaktiveret

Indstillinger:

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"

Når sessionssikkerhed er deaktiveret, opretter klienter kun forbindelse til Avamars Avagent-tjeneste på port 28001, og klienterne lytter på Avagent-port 28002 for anmodninger fra Avamar.

En proxy lytter på 28009.

Port 28001 er en almindelig TCP-sokkel og udfører ikke TLS-håndtryk.

Klienten opretter forbindelse til Avamar GSAN på port 29000 og udfører et envejs TLS-håndtryk. Det betyder, at selv når sessionssikkerhed er deaktiveret, krypteres sikkerhedskopierede data stadig under overførsel, når der overføres sikkerhedskopierede data mellem klienten og Avamar. 

Certifikater til godkendelse med Avamar-softwaren udveksles ikke mellem Avamar, proxyer, klienter og Data Domain.


Blandet-Single

Indstillinger:

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-tilstand blev brugt mere, da sessionssikkerhed først blev introduceret i Avamar 7.3, hvilket specifikt tillod de klienter, hvis version ikke var 7.3 eller nyere, at registrere og sikkerhedskopiere til Avamar. På tidspunktet for skrivningen af denne artikel er Avamar 19.10 den nyeste version, og Mixed-Single vil i det væsentlige være den samme som den næste tilstand, der skal diskuteres; Godkendt-enkelt.


Godkendt-enkelt

Indstillinger:

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"

I denne tilstand aktiveres sessionssikkerhed, og certifikater sendes mellem Avamar, klienter, proxyer og Data Domain til godkendelse forud for en sikkerhedskopiering.

Klienter lytter nu på port 30002 for Avagent-arbejdsordreanmodninger fra Avamar, og proxyerne lytter på port 30009. Avamar lytter på port 30001 og 30003 for forbindelsesanmodninger fra klienter og proxyer. Dette er SSL-stik, der udfører TLS-håndtryk.

Authenticated-Single mode tvinger alle klienter til at registrere sig ved hjælp af Session Security-metoder i modsætning til Mixed-Single mode.

Denne tilstand indstiller verifypeer på Avamars GSAN til deaktiveret, hvilket betyder, at GSAN ikke kræver klientcertifikater fra en indgående avtar-forbindelse.


Godkendt-dobbelt

Indstillinger:

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 er det samme som Authenticated-Single bortset fra, at det aktiverer verifypeer-indstilling på Avamars GSAN-tjeneste.

Authenticated-Dual betragtes som den stærkeste indstilling, der kan anvendes på en Avamar-server, og er standardvalget under Avamar-implementeringer.


Oversigt over: Avamar internt, selvsigneret rod-CA

Avamars interne rodnøglecenter er en intern nøglecenter, der er tillid til, til Avamar og de klienter, proxyer og datadomæner, som Avamar importerer til dem.

Avamar er det interne nøglecenter for sig selv, fordi det udsteder certifikater til anmodninger om certifikatsignering (CSR'er).

Når Avamar bruger sit rodnøglecenter til at signere certifikater for GSAN, gemmes de på følgende placering:
 

/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

Hvis en sikkerhedsscanner scanner port 29000 på Avamar, rapporterer den selvsignerede certifikater på den port, der behandler sikkerhedskopier til GSAN.

I nogle miljøer er dette muligvis ikke acceptabelt, og anbefalingen er at se følgende KB-artikel for at få flere oplysninger om udskiftning af Avamars interne rodnøglecenter med et brugerleveret internt rodnøglecenter.

KB-000204629 | Avamar: Installere/erstatte Avamar Certificate Authority (CA) med CA (User Provided Certificate Authority)

Processen beskriver, hvordan du bruger scriptet importcert.sh til at installere et brugerleveret nøglecenter internt i virksomheden. Den brugerleverede certifikatmyndighed administreres sandsynligvis af sikkerhedsteamet, da ingen offentlig certifikatmyndighed vil give væk den private nøgle til deres CA, da det er grunden til, at de tjener penge ved at underskrive certifikater for andre og opretholde en tillidskæde.

Et eksempel på et internt nøglecenter kunne være Microsoft Active Directory Certificate Services.
Hvad er Active Directory Certificate Services? | Microsoft Learn

Et eksempel på en offentlig CA kunne være DigiCert.

Udskiftning af Avamars interne CA-rodnøglecenter fungerer ved at udskifte rodnøgleparret i Avamar-nøglelageret med det brugerleverede CA-nøglepar. Derefter genererer GSAN en CSR og privat nøgle, får CSR underskrevet af det nye CA-nøglepar, og de filer, der er nævnt tidligere i dette afsnit, udskiftes. GSAN genindlæser SSL-soklen på port 29000, og nye klienter, der opretter forbindelse til GSAN, henviser til det brugerleverede nøglecenter.

Sikkerhedsscannere vil nu vise signerede certifikater på porten, og klienter, proxyer og Data Domain skal registreres igen for at få det nye nøglecenter.


Begrænsninger

Avamar-sessionens sikkerhedsfunktioner er underlagt visse begrænsninger:

• Klienter
  • Sessionssikkerhedsfunktioner kan ikke bruges med nogen af følgende Avamar-klienter:
    • Avamar Cluster Client til Solaris på Veritas Cluster Server
    • Avamar-klient til Solaris i Solaris-klynger
• Andre produkter
  • Der opfordres til brug af NTP-tidssynkronisering af Avamar-serveren, Avamar-klienter og Data Domain-systemet (hvis relevant). Hvis tiden ikke synkroniseres, kan det resultere i fejl i registrering og sikkerhedskopiering/gendannelse på grund af certifikatets gyldighed og udløbstider. Ændring af tidszonen på en vært kan have en lignende virkning og kan kræve certifikatregenerering.
• Sikker token
  • Sikret tokengodkendelse fungerer ikke under følgende betingelser:
    • Klientmaskinen er bag en NAT-firewallenhed (Network Address Translation)
    • Klientens værtsnavn er et virtuelt navn, der adskiller sig fra det FQDN, der er løst fra dets IP-adresse
    • Klientmaskinen har flere IP-grænseflader, og hver enkelt løser et andet fuldt kvalificeret domænenavn (FQDN). Se følgende KB for at få flere oplysninger: KB-000056252 | Avamar: Sikkerhedskopiering til Data Domain mislykkedes med meddelelsen "DDR_GET_AUTH_TOKEN" på grund af for mange IP-adresser

Planlægning

af sessionssikkerhedsændringerFør du foretager en ændring af sessionssikkerhedsindstillingerne, kan du udføre følgende trin for at få mulighed for at gendanne den tidligere konfiguration eller de tidligere certifikater, før du foretager ændringer.

Husk, at hvis den interne Avamar-rod-CA ændres, skal klienter, proxyer og Data Domain registreres igen. Afhængigt af miljøets størrelse (antal klienter, proxyer og Data Domains) kan dette være en besværlig opgave, der strækker sig over nogle få dage.

Brugssagen ville være, hvis certifikater regenereres, og nu er der registrerings- og sikkerhedskopieringsfejl.

Med den antagelse, at certifikater ikke er udløbet eller ved at blive det, og de regenereres måske ved et uheld, giver følgende trin nogle retningslinjer for, hvordan du forhindrer at være i en datatabs- eller datautilgængelighedssituation.

Hent de aktuelle indstillinger for sessionssikkerhed, og noter dem:

enable_secure_config.sh --showconfig

Lav en kopi af Avamar Keystore:

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

Antag, at certifikater nu regenereres, enten ved hjælp af Session Security AVP- eller CLI-metoderne.

Det betyder, at Avamar KeyStore er ændret, og at GSAN-certifikaterne er signeret igen.

Det originale Avamar Keystore kan ganske enkelt flyttes tilbage på plads:

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

Regenerer GSAN-certifikaterne:

enable_secure_config.sh --certs

Genstart MCS og Backup Scheduler:

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

Dette genindfører den oprindelige interne Avamar CA-rod, som klienter, proxyer og Data Domain allerede havde tillid til.


Fejlfinding

Det meste af tiden er det ligetil at ændre sessionssikkerhedsindstillingerne eller regenerere certifikater.

Dette afsnit har til formål at adressere, hvordan man får alt til at fungere igen, efter at certifikater er regenereret eller indstillinger ændret.

Lokale skylninger

I det scenarie, hvor verifypeer er aktiveret, opdateres de klientcertifikater, som Avamar-serverens avtar- og avmgr-bruger til, ikke med det samme, når alle Avamar-certifikater regenereres.

Det betyder, at når MCS kører en planlagt flush (sikkerhedskopiering af MCS-konfigurationen til GSAN), vil den mislykkes på grund af en TLS-handshake-fejl. Dette skyldes, at klientcertifikaterne for avtar, der kører på Avamar-serveren, endnu ikke har fået det opdaterede interne Avamar-rodnøglecenter og et nyt sæt signerede klientcertifikater.

Se følgende KB for at få flere oplysninger:

000214340 | Avamar: Avtar kan ikke oprette forbindelse til Avamars GSAN-tjeneste, "Fatal server connection problem, afbryde initialisering. Bekræft den korrekte serveradresse og de korrekte loginoplysninger."

Replikering

I scenariet, hvor verifypeer er aktiveret på replikeringsdestinationen, og certifikater regenereres på destinationen, skal en lignende tilgang fra afsnittet 'Local Flushes' ovenfor tages.

Først skal du sørge for, at replikeringsdestinationen Avagent er registreret, så den kan acceptere replikeringsarbejdsordrer.

På destinationen skal du kontrollere Avagent-loggen på følgende placering:

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

En sund log kan se sådan ud:

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

Når du går længere tilbage i loggen, kan der være en nylig vellykket genregistrering:

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

En usund log med registreringsproblemer forårsaget af certifikatændringer kan se sådan ud:

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.

I dette tilfælde skal følgende trin udføres for at kunne tvangsregistrere Avagent med MCS med det samme:

Hent det MC_SYSTEM kontonavn, som sandsynligvis vil være 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

Deaktiver den MC_SYSTEM konto:

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

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

Registrer MC_SYSTEM kontoen igen:

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

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

Når registreringen er gennemført, kan Avagent acceptere replikering på destinationen.

Hvis verifypeer er aktiveret på replikeringsdestinationen Avamar, skal vi nu generere de klientcertifikater, der blev brugt til at oprette forbindelse til destinationen Avamar, på kilden Avamar.

Minder om KB-000214340 | Avamar: Avtar kan ikke oprette forbindelse til Avamars GSAN-tjeneste, "Fatal server connection problem, afbryde initialisering. Bekræft den korrekte serveradresse og de korrekte loginoplysninger." 

Fjern den eksisterende destinationsmappe med Avamar-certifikater fra Avamar ssh-kildesessionen:

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

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

Regenerer klientcertifikaterne:

/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

Kommunikation til destinationen Avamar kan testes fra kommandolinjen Source Avamar ssh:

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

Klientregistrering

Sikkerhedskopiering kan forsøges efter ændring af sessionens sikkerhedsindstillinger eller regenerering af certifikaterne.

Dette kan føre til, at mange agentbaserede klienter har status som "Venter-klient", indtil de ikke sikkerhedskopierer med "Timed-Out Start".

Når de nye certifikater er regenereret, bør det tage ca. 23 timer, før klienten automatisk forsøger at registrere igen.

Følgende kommando kan bruges på Avamar-serveren til at sende en invitation til agentbaserede klienter om at registrere sig igen med Avamar MCS.

mccli client re-register-all

Kommandoen kan tage lidt tid afhængigt af antallet af klienter, da den sender en invitation til hver enkelt i sekventiel rækkefølge. Overvej at køre kommandoen i baggrunden, hvis der opstår timeout for ssh-sessionen.

nohup mccli client re-register-all &

Bemærk, at dette muligvis ikke fungerer for at genregistrere alle agentbaserede klienter, og nogle skal muligvis registreres igen manuelt.

Den manuelle proces til genregistrering af en klient på Windows ville være at:

• Fjern indholdet af følgende mappe, som indeholder de gamle klientcertifikater:

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

• Genstart tjenesten "Backup Agent"

Den manuelle proces til genregistrering af en klient på Linux ville være at:

• Fjern indholdet af følgende mappe, som indeholder de gamle klientcertifikater:

  • /usr/local/avamar/etc

• Genstart Avagent-tjenesten:

  • service avagent restart

Genstart af klientmaskinen kan også gøres for at forsøge at udløse en fuld genregistrering.

Bemærk, at navnefortolkning spiller en vigtig rolle i registrering af klienter, når sessionssikkerhed er aktiveret. Sørg for, at klienterne kan foretage et fremadrettet og omvendt DNS-opslag på Avamar-serveren og omvendt. Dette kan opnås enten ved at konfigurere DNS A-poster eller være vært for poster på klienten.

Avamar leverer ikke nogen form for script, der kan nå ud til hver tilsluttet klient for at udføre en manuel genregistrering, den tidligere nævnte mccli kommando er tættest på det.

Proxyregistrering

Virtuelle maskiner, der sikkerhedskopieres til Avamar ved hjælp af proxyer, har en vis fordel, når det drejer sig om sikkerhedsændringer efter sessionen, da der normalt er mange færre proxyer end agentbaserede klienter.

Fuldmagter bør også forsøge en automatisk omregistrering inden for 23 timer, men det kan være lettere og hurtigere at omregistrere dem med det samme.

Der er et par muligheder for at prøve en kraft en genregistrering på fuldmagterne.

Den første mulighed kan være at genstarte proxyerne med følgende kommando:

mccli mcs reboot-proxy --all

Den anden mulighed ville være at bruge Goav-værktøjet til at administrere proxyerne.

Indstil proxyadgangskoden til Goav-værktøjet, så det kan logge ind på proxyerne, når det er nødvendigt. Følgende kommando ændrer ikke proxyens OS-adgangskode, den gemmer simpelthen adgangskoden krypteret, så Goav-værktøjet kan bruge det til at logge ind på proxyen, når det skal over ssh.

./goav proxy set-password

Udfør en Avagent-genstart på alle tilsluttede proxyer:

./goav proxy exec "service avagent restart"

For at kontrollere Avagent-loggen i proxyen for at se, om der er sket en genregistrering, skal du køre følgende kommando:

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

Vellykket output kan se ud som følger:

============== 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.

Den tredje mulighed er at ssh til proxyen og køre initialiseringsscriptet:

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

Data Domain-synkronisering

Når sessionssikkerhedsindstillingerne er ændret, eller certifikater er blevet regenereret på Avamar, skal Data Domain synkroniseres igen, eller SSL-forbindelsen genoprettes.

Følgende KB-artikel dækker dette scenarie, og hvordan du udveksler de nye certifikater med Data Domain.

000197106 | Avamar- og Data Domain-integration: DD viser rødt i Avamar AUI og/eller brugergrænseflade Løsningssti

Det anbefales på det kraftigste at håndtere fejlfinding af Avamar og Data Domain SSL med Goav-værktøjet.

Med Goav kan Data Domain SSL-forbindelsen med Avamar automatisk diagnosticeres og løses. Se følgende KB med flere oplysninger:

000215679 | Avamar: Oplysninger om Goav DD Check-SSL-funktion

Kør følgende kommando for automatisk at rette Avamar- og Data Domain-certifikater:

./goav dd check-ssl --fix