Avamar: Sessionssäkerhet
Summary: I den här artikeln beskrivs vad sessionssäkerhet är på Avamar, hur det fungerar och hur du hanterar det.
Instructions
Sessionssäkerhet: Produktsäkerhetsmanual
Avamar-klienter kan använda sessionssäkerhet för att skydda all kommunikation mellan Avamar-servern och Avamar-klientprogramvaran. Avamar-servern tillhandahåller autentisering till Avamar-klienten och Avamar-klienten tillhandahåller autentisering till Avamar-servern.
Sessionssäkerhetsfunktionerna omfattar säkerhetsförbättringar för kommunikation mellan Avamar-systemprocesser.
Avamar skyddar all kommunikation mellan Avamar-systemprocesser med hjälp av sessionsbiljetter. En giltig sessionsbiljett krävs innan en Avamar-process accepterar en överföring från en annan Avamar-process.
Sessionsbiljetterna har följande allmänna egenskaper:
- Sessionsbiljetten är krypterad och signerad för att skydda mot ändringar
- Sessionsbiljetten är giltig under en kort tid
- Varje sessionsärende innehåller en unik signatur och tilldelas endast en Avamar-process
- Integriteten för en sessionsbiljett skyddas av kryptering
- Varje Avamar-systemnod verifierar separat signaturen för sessionsbiljetten
- Vid behov kan en session förlängas utöver sessionsbiljettens livslängd
Avamar-systemet installerar den offentliga nyckeln för servercertifikatet på varje Avamar-klient som är registrerad på Avamar-servern. Avamar-klienter använder den offentliga nyckeln för att autentisera överföringar från Avamar-systemet.
För klienter som för närvarande är registrerade sprids den offentliga nyckeln för servercertifikatet och andra nödvändiga certifikatfiler till klienten inom en timme efter installationen.
Avamar-systemet delar också automatiskt Avamar-servercertifikatet med Avamar-lagringsnoderna. Genom att dela certifikatet kan verktygsnoden och lagringsnoderna tillhandahålla samma certifikat för autentisering.
Ett klientcertifikat genereras när Avamar-servern registrerar en Avamar-klient.
När ett klientcertifikat har genererats använder Avamar-systemet en krypterad anslutning till Avamar-klienten för att installera certifikatet på klienten. Avamar-systemet lagrar också den offentliga nyckeln för klientcertifikatet. Den offentliga nyckeln används för att autentisera klienten i all efterföljande kommunikation.
Hur fungerar sessionssäkerhet?
Sessionssäkerhet är aktiverat på Avamar-servern. När det här alternativet är aktiverat genomgår klienter, proxyservrar och Data Domain-system en särskild certifikatregistreringsprocess med Avamar.
På en Windows- eller Linux-klient och proxyserver ser den vid registreringen att Avamar-servern har sessionssäkerhet aktiverat. Avamar skickar sin interna rotcertifikatutfärdare till klienten (chain.pem) så att klienten kan lagra och lita på den. Klienten genererar en begäran om certifikatsignering (CSR). CSR (avclient.csr) skickas från klienten till Avamar-serverns MCS-process som signerar CSR och ger tillbaka ett certifikatnyckelpar till klienten (key.pem och cert.pem).
När Data Domain ansluts till Avamar eller när SSL-kommunikationen uppdateras på en Data Domain kommer Avamar att se att Data Domain inte har något signerat certifikat från sig själv eller någon annan validerad Avamar (imported-host ddboost). Avamar använder den privata ssh-nyckeln för Data Domain för att logga in på Data Domain för att köra ssh-kommandon över Data Domin-gränssnittet (ddsh). Avamar hämtar sin begäran om signering av Data Domain-certifikat (CSR) via SCP och signerar CSR med Avamars interna rotcertifikatutfärdare. När Data Domain har det signerade certifikatet från Avamar (imported-host ddboost) importerar Avamar rotcertifikatutfärdaren som signerade certifikatet (chain.pem som imported-ca ddboost/login-auth).
Nu när en klient/proxy är registrerad och har de certifikat på klientsidan som krävs för att autentisera med Avamars MCS görs ett säkerhetskopieringsförsök. Avamar skickar en arbetsorder till klientens eller proxyns Avagent-lyssnare, som hämtar arbetsordern. Klienten eller proxyn validerar och verifierar sedan Avamar-serverns certifikatkedja med hjälp av Avamar-rotcertifikatutfärdaren som Avamar hade importerat till klienten vid registreringen. På samma sätt autentiserar Avamar klienten eller proxyn. Inga data har skickats vid denna tidpunkt.
När autentiseringen har slutförts startar arbetsordern och arbetsorderns status ändras från "Waiting-Client" till "Running".
Nu flyttar klienter och proxyservrar så småningom data till Avamar och Data Domain med hjälp av den avtar-binärfil som är installerad på dem. Den avtar-binära filen skickar några flaggor som styr informationen om hur data flyttas och vilka data som flyttas.
När avtar på en klient eller proxy ska ansluta till Avamars GSAN måste den veta om verifypeer är aktiverat. Inställningen verifypeer är en GSAN-serverinställning som en del av sessionssäkerhetskonfigurationen som styr GSAN:s SSL-socket på port 29000 genom att tala om för den om klientcertifikat ska krävas för varje inkommande anslutning eller inte. Lyckligtvis implementeras TLS 1.2-protokollet som automatiskt hanterar hur en klient eller proxy ska presentera sina klientcertifikat för gsan under TLS-handskakningen.
Följande är en demonstration av TLS ömsesidigt/dubbelriktat handskakande när verifypeer är aktiverat.
Från klient- eller proxysynpunkt är en pil som pekar åt höger en anslutning till Avamar-servern. En pil som pekar åt vänster är en anslutning som kommer från Avamar-servern till 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 är avaktiverat behöver klienten inte skicka ett klientcertifikat till 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
Det viktiga är att klienten eller proxyn har de nödvändiga certifikaten på klientsidan för att kunna utföra en ömsesidig TLS-handskakning om GSAN så kräver.
Det innebär att om Avamars interna rotcertifikatutfärdare ändras måste klienten, proxyn eller Data Domain hämta den nya rotcertifikatutfärdaren för att signera certifikat åt dem.
När klienten eller proxyn har anslutit till GSAN försöker den ansluta till Data Domain.
Följande logg visar en proxy som ansluter till Data Domain med avtar. Inställningen verifypeer är inaktiverad, men sessionssäkerhet är aktiverat (autentiserat-enkelt läge).
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
Eftersom verifypeer är en Avamar GSAN-serverinställning påverkar det inte hur Avtar ansluter direkt till Data Domain om sessionssäkerhet är aktiverat. Det innebär att en ömsesidig TLS-handskakning sker mellan klienten eller proxyn och Data Domain.
Klienten eller proxyn kan validera Data Domain-certifikatkedjan eftersom den delar samma interna Avamar-rotcertifikatutfärdare som importerades av Avamar vid klientregistreringen (eller vid DD-redigering eller bilaga).
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
Efter certifikatvalidering slutförs handskakningen och säkerhetskopierade data flyttas från klienten till Data Domain och Avamar i nätverket.
Hantera säkerhetsinställningar
för sessionerFöljande två artiklar används för att hantera sessionssäkerhetsinställningarna, antingen från kommandoraden eller Avinstaller-webbtjänsten.
000222234 | Avamar: Hantera sessionssäkerhetsinställningar från CLI
000222279 | Avamar: Hantera säkerhetsinställningar för sessioner med Avinstaller Installation Package (AVP)
Det finns fyra möjliga konfigurationer som stöds:
- Disabled (avaktiverad)
- Blandad-singel
- Autentiserad-enkel
- Autentiserad – dubbel
Inaktiverad
Inställningar:
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 sessionssäkerhet är inaktiverat ansluter klienter endast till Avamars Avagent-tjänst på port 28001 och klienterna lyssnar på Avagent-port 28002 efter begäranden från Avamar.
En proxy lyssnar på 28009.
Port 28001 är en vanlig TCP-socket och utför inte TLS-handskakningar.
Klienten ansluter till Avamar GSAN på port 29000 och utför en enkelriktad TLS-handskakning. Det innebär att även när sessionssäkerhet är inaktiverat krypteras säkerhetskopieringsdata fortfarande under flygning när de överförs mellan klienten och Avamar.
Certifikat för autentisering med Avamar-mjukvaran utbyts inte mellan Avamar, proxyservrar, klienter och Data Domain.
Blandad-singel
Inställningar:
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"
Blandat-enskilt läge användes mer när sessionssäkerhet först introducerades i Avamar 7.3, vilket specifikt gjorde det möjligt för klienter vars version inte var 7.3 eller senare att registrera sig och säkerhetskopiera till Avamar. I skrivande stund är Avamar 19.10 den senaste versionen och Mixed-Single kommer i princip att vara samma som nästa läge att diskutera; Autentiserad-enkel.
Autentiserad-enkel
Inställningar:
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 det här läget är sessionssäkerhet aktiverat och certifikat skickas mellan Avamar, klienter, proxyservrar och Data Domain för autentisering före en säkerhetskopiering.
Klienter lyssnar nu på port 30002 efter Avagent-arbetsorderbegäranden från Avamar och proxyservrarna lyssnar på port 30009. Avamar lyssnar på portarna 30001 och 30003 efter anslutningsbegäranden från klienter och proxyservrar. Dessa är SSL-sockets som utför TLS-handskakningar.
Autentiserat-enkelt läge tvingar alla klienter att registrera sig med sessionssäkerhetsmetoder till skillnad från blandat-enkelt läge.
I det här läget ställs verifypeer på Avamars GSAN in på inaktiverat, vilket innebär att GSAN inte kräver klientcertifikat från en inkommande avtar-anslutning.
Autentiserad – dubbel
Inställningar:
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 är samma som Authenticated-Single förutom att det aktiverar verifypeer-inställningen i Avamars GSAN-tjänst.
Authenticated-Dual anses vara den starkaste inställningen att tillämpa på en Avamar-server och är standardvalet under Avamar-distributioner.
Översikt: Avamar intern självsignerad rotcertifikatutfärdare
Avamars interna rotcertifikatutfärdare är en internt betrodd certifikatutfärdare för Avamar och de klienter, proxyservrar och Data Domains som Avamar importerar till dem.
Avamar är den interna certifikatutfärdaren eftersom den utfärdar certifikat för begäranden om certifikatsignering (CSR).
När Avamar använder sin rotcertifikatutfärdare för att signera certifikat för GSAN lagras de på följande plats:
/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
Om en säkerhetsskanner skannar port 29000 på Avamar rapporterar den självsignerade certifikat på den porten som bearbetar säkerhetskopieringar till GSAN.
I vissa miljöer kanske detta inte är acceptabelt, och vi rekommenderar att du läser följande KB-artikel för mer information om hur du ersätter den interna rotcertifikatutfärdaren Avamar med en intern rotcertifikatutfärdare som tillhandahålls av användaren.
KB 000204629 | Avamar: Installera/ersätt Avamar Certificate Authority (CA) med User Provided Certificate Authority (CA)
Processen beskriver hur du använder importcert.sh-skriptet för att installera en intern certifikatutfärdare som tillhandahålls av användaren i företaget. Den certifikatutfärdare som tillhandahålls av användaren hanteras sannolikt av säkerhetsteamet, eftersom ingen offentlig certifikatutfärdare kommer att ge bort den privata nyckeln för sin certifikatutfärdare eftersom det är anledningen till att de tjänar pengar genom att signera certifikat för andra och upprätthålla en förtroendekedja.
Ett exempel på en intern certifikatutfärdare är Microsoft Active Directory Certificate Services.
Vad är Active Directory-certifikattjänster? | Microsoft Learn
Ett exempel på en offentlig certifikatutfärdare är DigiCert.
Du kan byta ut Avamars interna rotcertifikatutfärdare genom att ersätta rotnyckelparet i Avamar-nyckellagret med det nyckelpar som användaren har angett. GSAN genererar sedan en CSR och en privat nyckel, får CSR signerad av det nya CA-nyckelparet och de filer som nämnts tidigare i det här avsnittet ersätts. GSAN läser in SSL-socketen på nytt på port 29000 och nya klienter som ansluter till GSAN ser certifikatutfärdaren som användaren har angett.
Säkerhetsskannrar visar nu signerade certifikat på porten och klienter, proxyservrar och Data Domain måste registrera sig på nytt för att få den nya certifikatutfärdaren.
Begränsningar
Säkerhetsfunktionerna för Avamar-sessioner har vissa begränsningar:
- Klienter
- Sessionssäkerhetsfunktioner kan inte användas med någon av följande Avamar-klienter:
- Avamar-klusterklient för Solaris på Veritas-klusterserver
- Avamar-klient för Solaris i Solaris-kluster
- Sessionssäkerhetsfunktioner kan inte användas med någon av följande Avamar-klienter:
- Övriga produkter
- Användning av NTP-tidssynkronisering av Avamar-servern, Avamar-klienterna och Data Domain-systemet (om tillämpligt) uppmuntras. Om tiden inte synkroniseras kan det leda till registrerings- och säkerhetskopierings-/återställningsfel på grund av certifikatets giltighet och förfallotider. Att ändra tidszonen på en värd kan ha en liknande inverkan och kan kräva återskapande av certifikat.
- Säker token
- Säker tokenautentisering fungerar inte under följande förhållanden:
- Klientdatorn finns bakom en NAT-brandväggsenhet (Network Address Translation)
- Klientens värdnamn är ett virtuellt namn som skiljer sig från det FQDN som matchas från dess IP-adress
- Klientdatorn har flera IP-gränssnitt och var och en matchas till ett annat fullständigt kvalificerat domännamn (FQDN). Mer information finns i följande kunskapsdatabas: KB 000056252 | Avamar: Säkerhetskopiering till Data Domain misslyckades med meddelandet "DDR_GET_AUTH_TOKEN" på grund av för många IP-adresser
- Säker tokenautentisering fungerar inte under följande förhållanden:
Ändringsplanering för
sessionssäkerhetInnan du ändrar inställningarna för sessionssäkerhet kan du utföra följande steg för att återställa den tidigare konfigurationen eller certifikaten innan du gör några ändringar.
Kom ihåg att klienter, proxyservrar och Data Domain måste registreras på nytt om Avamars interna rotcertifikatutfärdare ändras. Beroende på miljöns storlek (antal klienter, proxyservrar och Data Domains) kan detta vara en besvärlig uppgift som sträcker sig över några dagar.
Användningsfallet skulle vara om certifikat återskapas och nu finns det registrerings- och säkerhetskopieringsfel.
Med antagandet att certifikat inte har upphört att gälla eller är på väg att göra det, och att de kanske återskapas av misstag, ger följande steg vägledning om hur du förhindrar att du hamnar i en situation med dataförlust eller dataotillgänglighet.
Hämta de aktuella sessionssäkerhetsinställningarna och anteckna dem:
enable_secure_config.sh --showconfig
Gör en kopia av Avamar-nyckelbehållaren:
cp -p /usr/local/avamar/lib/avamar_keystore /usr/local/avamar/lib/x-avamar_keystore-original
Anta att certifikat nu återskapas, antingen med hjälp av AVP- eller CLI-metoderna Sessionssäkerhet.
Det innebär att Avamar-nyckelbehållaren har ändrats och att GSAN-certifikaten har signerats om.
Den ursprungliga Avamar-nyckelbehållaren kan enkelt flyttas tillbaka till följande plats:
cp -p /usr/local/avamar/lib/x-avamar_keystore-original /usr/local/avamar/lib/avamar_keystore
Återskapa GSAN-certifikaten:
enable_secure_config.sh --certs
Starta om MCS och Schemaläggaren för säkerhetskopiering:
mcserver.sh --restart --force dpnctl start sched
Detta återställer den ursprungliga interna Avamar-rotcertifikatutfärdaren som klienter, proxyservrar och Data Domain redan litade på.
Felsökning
För det mesta är det enkelt att ändra inställningarna för sessionssäkerhet eller återskapa certifikat.
Det här avsnittet syftar till att ta itu med hur du får allt att fungera igen när certifikat har återskapats eller inställningarna har ändrats.
Lokala spolningar
I scenariot där verifypeer är aktiverat, när alla Avamar-certifikat återskapas, uppdateras inte de klientcertifikat som Avamar-serverns avtar- och avmgr-användning använder omedelbart.
Det innebär att när MCS kör en schemalagd tömning (säkerhetskopiering av MCS-konfigurationen till GSAN) misslyckas den på grund av ett TLS-handskakningsfel. Det beror på att klientcertifikaten för Avtar som körs på Avamar-servern ännu inte har fått den uppdaterade interna Avamar-rotcertifikatutfärdaren och en ny uppsättning signerade klientcertifikat.
Mer information finns i följande KB:
000214340 | Avamar: Avtar kan inte ansluta till Avamars GSAN-tjänst, "Allvarligt problem med serveranslutning, avbryter initieringen. Kontrollera att du har rätt serveradress och inloggningsuppgifter."
Replikering
I scenariot där verifypeer är aktiverat på replikeringsmålet och certifikat återskapas på målet måste en liknande metod från avsnittet "Lokala tömningar" ovan användas.
Kontrollera först att replikeringsdestinationen Avagent är registrerad så att den kan acceptera replikeringsarbetsorder.
Kontrollera Avagent-loggen på följande plats på målet:
/usr/local/avamar/var/client/avagent.log
En felfri logg kan se ut så här:
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ängre bak i loggen kan det finnas en nyligen lyckad omregistrering:
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 logg med feltillstånd med registreringsproblem som orsakas av certifikatändringar kan se ut så här:
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 det här fallet måste följande åtgärder vidtas för att avagent omedelbart ska kunna omregistreras med MCS:
Hämta det MC_SYSTEM kontonamnet, som troligen är 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
Inaktivera det MC_SYSTEM kontot:
mccli client edit --name=/MC_SYSTEM/<avamar_fqdn> --activated=false example: mccli client edit --name=/MC_SYSTEM/avamar.lab --activated=false
Registrera om MC_SYSTEM kontot:
/etc/init.d/avagent register <avamar_fqdn> /MC_SYSTEM example: /etc/init.d/avagent register avamar.lab /MC_SYSTEM
När registreringen har slutförts kan Avagent acceptera replikering på målet.
På källan Avamar om verifypeer är aktiverat på replikeringsmålet Avamar måste vi återskapa klientcertifikaten som används för att ansluta till Avamar-målet.
Liknar KB 000214340 | Avamar: Avtar kan inte ansluta till Avamars GSAN-tjänst, "Allvarligt problem med serveranslutning, avbryter initieringen. Kontrollera att du har rätt serveradress och inloggningsuppgifter."
Ta bort den befintliga Avamar-målcertifikatmappen från Avamar ssh-källsessionen:
rm -r /usr/local/avamar/etc/<destination_avamar_ip_address> rm -r /usr/local/avamar/etc/client/<destination_avamar_ip_address>
Återskapa klientcertifikaten:
/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 till Avamar-målet kan testas från kommandoraden för Avamar-käll-ssh:
avmgr logn --id=repluser --ap=<destination_repluser_password> --hfsaddr=<destination_avamar_ip_address> --debug --x19=1024 --x30=8192
Klientregistrering
Säkerhetskopieringar kan göras efter att säkerhetsinställningarna för sessionen har ändrats eller certifikaten har återskapats.
Detta kan leda till att många agentbaserade klienter hittar statusen "Waiting-Client" tills det inte går att säkerhetskopiera med "Timed-Out Start".
När de nya certifikaten har återskapats bör det ta cirka 23 timmar innan klienten automatiskt försöker registrera sig på nytt.
Följande kommando kan användas på Avamar-servern för att skicka en inbjudan till agentbaserade klienter att omregistrera sig hos Avamar MCS.
mccli client re-register-all
Kommandot kan ta lite tid beroende på antalet klienter, eftersom det skickar en inbjudan till var och en i sekventiell ordning. Överväg att köra kommandot i bakgrunden om ssh-sessionen överskrider tidsgränsen.
nohup mccli client re-register-all &
Observera att detta kanske inte fungerar för att omregistrera alla agentbaserade klienter, och vissa kan behöva omregistreras manuellt.
Den manuella processen för att omregistrera en klient i Windows är att:
- Ta bort innehållet i följande katalog som innehåller de gamla klientcertifikaten:
-
"C:\Program Files\avs\etc"
-
- Starta om tjänsten "Backup Agent"
- Ta bort innehållet i följande katalog som innehåller de gamla klientcertifikaten:
-
/usr/local/avamar/etc
-
- Starta om Avagent-tjänsten:
-
service avagent restart
-
Du kan också starta om klientdatorn för att försöka utlösa en fullständig omregistrering.
Observera att namnmatchning spelar en viktig roll när du registrerar klienter när sessionssäkerhet är aktiverat. Se till att klienterna kan utföra en DNS-sökning framåt och bakåt på Avamar-servern och vice versa. Detta kan uppnås antingen genom att konfigurera DNS A-poster eller värdposter på klienten.
Avamar tillhandahåller inte någon form av skript som kan nå ut till varje ansluten klient för att utföra en manuell omregistrering, det tidigare nämnda mccli-kommandot är det närmaste det.
Fullmaktsregistrering
Virtuella maskiner som säkerhetskopieras till Avamar med proxyservrar har en viss fördel när det gäller säkerhetsändringar efter sessioner, eftersom det vanligtvis finns många färre proxyservrar än agentbaserade klienter.
Fullmakter bör också försöka göra en automatisk omregistrering inom 23 timmar, men det kan vara enklare och snabbare att omregistrera dem omedelbart.
Det finns några alternativ tillgängliga för att prova en tvinga fram en omregistrering på proxyservrarna.
Det första alternativet kan vara att starta om proxyservrarna med följande kommando:
mccli mcs reboot-proxy --all
Det andra alternativet skulle vara att använda Goav-verktyget för att hantera proxyservrarna.
Ställ in proxylösenordet för Goav-verktyget så att det kan logga in på proxyservrarna när det måste. Följande kommando ändrar inte OS-lösenordet för proxyn, det lagrar helt enkelt lösenordet krypterat så att Goav-verktyget kan använda det för att logga in på proxyn när det måste över ssh.
./goav proxy set-password
Utför en Avagent-omstart på alla anslutna proxyservrar:
./goav proxy exec "service avagent restart"
Om du vill kontrollera Avagent-loggen i proxyn för att se om en lyckad omregistrering har skett kör du följande kommando:
./goav proxy exec "grep -i registration /usr/local/avamarclient/var/avagent.log"
Lyckade utdata kan se ut så här:
============== 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.
Det tredje alternativet är att ssh till proxyn och köra initieringsskriptet:
/usr/local/avamarclient/etc/initproxyappliance.sh start
Data Domain-synkronisering
När sessionssäkerhetsinställningarna har ändrats eller certifikat återskapats på Avamar måste Data Domain synkroniseras om eller SSL-anslutningen återupprättas.
Följande KB-artikel beskriver det här scenariot och hur du utbyter de nya certifikaten med Data Domain.
000197106 | Avamar- och Data Domain-integrering: DD visas rött i Avamar AUI och/eller användargränssnitt Sökväg
för upplösning Vi rekommenderar starkt att du hanterar felsökning av Avamar och Data Domain SSL med Goav-verktyget.
Med Goav kan Data Domain SSL-anslutningen med Avamar diagnostiseras och lösas automatiskt, se följande KB för mer information:
000215679 | Avamar: Information om Goav dd check-ssl-funktionen Kör
följande kommando för att automatiskt åtgärda Avamar- och Data Domain-certifikat:
./goav dd check-ssl --fix