Avamar: Istunnon turvallisuus
Summary: Tässä artikkelissa kuvataan, mikä Avamarin istunnon suojaus on, miten se toimii ja miten sitä hallitaan.
Instructions
Istunnon turvallisuus: Tuotesuojausopas
Avamar-asiakkaat voivat käyttää istunnon suojausta kaiken Avamar-palvelimen ja Avamar Client -ohjelmiston välisen tietoliikenteen turvaamiseen. Avamar-palvelin mahdollistaa todennuksen Avamar-asiakasohjelmassa ja Avamar-asiakasohjelma Avamar-palvelimessa.
Istunnon suojausominaisuuksiin kuuluu tietoturvaparannuksia Avamar-järjestelmän prosessien väliseen viestintään.
Avamar suojaa kaiken Avamar-järjestelmän prosessien välisen tietoliikenteen istuntopyynnöillä. Kelvollinen istuntolippu vaaditaan, ennen kuin Avamar-prosessi hyväksyy lähetyksen toisesta Avamar-prosessista.
Istuntolipuilla on seuraavat yleiset ominaisuudet:
- Istuntolippu salataan ja allekirjoitetaan muokkausten estämiseksi.
- Istuntolippu on voimassa lyhyen aikaa
- Jokainen istuntolippu sisältää yksilöllisen allekirjoituksen, ja se liitetään vain yhteen Avamar-prosessiin
- Istuntolipun eheys on suojattu salauksella
- Jokainen Avamar-järjestelmäsolmu vahvistaa istuntolipun allekirjoituksen erikseen
- Tarvittaessa istuntoa voidaan jatkaa istuntolipun käyttöiän jälkeen
Avamar-järjestelmä asentaa palvelimen varmenteen julkisen avaimen jokaiseen Avamar-asiakkaaseen, joka on rekisteröity Avamar-palvelimeen. Avamar-asiakkaat todentavat Avamar-järjestelmästä lähetetyt lähetykset julkisen avaimen avulla.
Rekisteröityjen asiakkaiden tapauksessa palvelinvarmenteen julkinen avain ja muut vaaditut varmennetiedostot välitetään asiakkaalle tunnin kuluessa asennuksesta.
Lisäksi Avamar-järjestelmä jakaa automaattisesti Avamar-palvelinvarmenteen Avamar-tallennussolmujen kanssa. Kun varmenne jaetaan, apusolmu ja tallennussolmut voivat tarjota saman varmenteen todennusta varten.
Asiakasvarmenne luodaan, kun Avamar-palvelin rekisteröi Avamar-asiakasohjelman.
Kun asiakasvarmenne on luotu, Avamar-järjestelmä asentaa varmenteen asiakkaalle salatulla yhteydellä Avamar-asiakasohjelmaan. Avamar-järjestelmä tallentaa myös asiakasvarmenteen julkisen avaimen. Julkista avainta käytetään asiakkaan todentamiseen kaikessa myöhemmässä viestinnässä.
Miten istuntosuojaus toimii?
Istunnon suojaus on käytössä Avamar-palvelimessa. Kun asetus on käytössä, asiakkaat, välityspalvelimet ja Data Domain -järjestelmät käyvät läpi erityisen varmenteen rekisteröintiprosessin Avamarilla.
Windows- tai Linux-asiakasohjelmassa ja välityspalvelimessa näkyy rekisteröinnin yhteydessä, että Avamar-palvelimessa on käytössä istunnon suojaus. Avamar lähettää asiakkaalle sisäisen varmenteen myöntäjän (chain.pem), jotta asiakas voi tallentaa sen ja luottaa siihen. Asiakas luo varmenteen allekirjoituspyynnön (CSR). CSR (avclient.csr) lähetetään asiakkaalta Avamar-palvelimen MCS-prosessiin, joka allekirjoittaa CSR:n ja palauttaa varmenteen avainparin asiakkaalle (key.pem > cert.pem).
Kun Data Domain liitetään Data Domainiin tai SSL-yhteys päivitetään, Avamar näkee, että Data Domainilla ei ole sen allekirjoittamaa varmennetta eikä jonkin toisen vahvistetun Avamarin (imported-host ddboost) varmennetta. Avamar kirjautuu Data Domainiin Data Domainiin yksityisellä Data Domainin ssh-avaimella ja suorittaa ssh-komentoja Data Domin -komentotulkin (ddsh) kautta. Avamar vetää Data Domain -varmenteen allekirjoituspyynnön (CSR) SCP:n yli ja allekirjoittaa CSR:n Avamarin sisäisen päämyöntäjän kanssa. Kun Data Domainilla on allekirjoitettu varmenne Avamarilta (imported-host ddboost), Avamar tuo varmenteen allekirjoittaneen päävarmenteen myöntäjän (chain.pem muodossa imported-ca ddboost/login-auth).
Nyt kun asiakas/välityspalvelin on rekisteröity ja sillä on Avamarin MCS-todennukseen tarvittavat asiakaspuolen varmenteet, varmuuskopiointia yritetään tehdä. Avamar lähettää työtilauksen asiakkaalle tai välityspalvelimen Avagent-kuuntelijalle, joka noutaa työtilauksen. Tämän jälkeen asiakas tai välityspalvelin vahvistaa ja vahvistaa Avamar-palvelimen varmenneketjun käyttämällä Avamarin päävarmenteiden myöntäjää, jonka Avamar oli tuonut asiakkaalle rekisteröinnin yhteydessä. Samoin Avamar todentaa asiakkaan tai välityspalvelimen. Tietoja ei ole vielä välitetty.
Kun todennus on onnistunut, työtilaus käynnistyy ja työtilauksen tila muuttuu arvosta Waiting-Client tilaksi Running.
Nyt asiakkaat ja välityspalvelimet siirtävät lopulta tietoja Avamariin ja Data Domainiin niihin asennetun avtar-binaaritiedoston avulla. Avtar-binaari välittää joitakin lippuja, jotka ohjaavat tietojen siirtämisen ja siirrettävien tietojen yksityiskohtia.
Kun asiakkaan tai välityspalvelimen Avtar muodostaa yhteyden Avamarin GSANIIN, sen on tiedettävä, onko verifypeer käytössä. Verifypeer-asetus on GSAN-palvelinasetus osana istunnon suojausmääritystä, joka hallitsee GSANin SSL-kantaa portissa 29000 kertomalla sille, vaaditaanko asiakasvarmenteita jokaiselle saapuvalle yhteydelle. Onneksi TLS 1.2 -protokolla on otettu käyttöön, joka käsittelee automaattisesti, kuinka asiakas tai välityspalvelin esittää asiakasvarmenteensa gsanille TLS-kättelyn aikana.
Seuraavassa on esittely TLS:n keskinäisestä/kaksisuuntaisesta kättelystä, kun verifypeer on käytössä.
Asiakkaan tai välityspalvelimen näkökulmasta oikealle osoittava nuoli muodostaa yhteyden Avamar-palvelimeen. Vasemmalle osoittava nuoli on Avamar-palvelimesta työasemaan tuleva yhteys.
[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
Kun verifypeer on poistettu käytöstä, asiakkaan ei tarvitse lähettää asiakasvarmennetta GSANille.
[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
Tärkeää on, että asiakas tai välityspalvelin sai tarvittavat asiakaspuolen varmenteet voidakseen suorittaa keskinäisen TLS-kättelyn GSANin niin vaatiessa.
Tämä tarkoittaa sitä, että jos Avamarin sisäinen päävarmenteiden myöntäjä muuttuu, asiakkaan, välityspalvelimen tai Data Domainin on hankittava uusi päävarmenteiden myöntäjä, jotta se voi allekirjoittaa varmenteet puolestaan.
Kun asiakas tai välityspalvelin muodostaa yhteyden GSANIIN, se yrittää muodostaa yhteyden Data Domainiin.
Seuraavassa lokissa näkyy välityspalvelin, joka muodostaa yhteyden Data Domainiin avtarin avulla. VerifyPeer-asetus on poistettu käytöstä, mutta istunnon suojaus on käytössä (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
Koska verifypeer on Avamar GSAN -palvelinasetus, istunnon suojauksen käyttöönotto ei vaikuta siihen, miten avtar muodostaa yhteyden suoraan Data Domainiin. Tämä tarkoittaa, että asiakkaan tai välityspalvelimen ja Data Domainin välillä tapahtuu molemminpuolinen TLS-kättely.
Asiakas tai välityspalvelin voi vahvistaa Data Domain -varmenneketjun, koska sillä on sama Avamarin sisäinen päävarmenteiden myöntäjä, jonka Avamar toi asiakkaan rekisteröinnin yhteydessä (tai DD:n muokkaus- tai liiteaikana).
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
Varmenteen vahvistuksen jälkeen kättely päättyy ja varmuuskopiotiedot siirretään asiakkaasta verkon Data Domainiin ja Avamariin.
Istunnon suojausasetusten
hallintaSeuraavia kahta artikkelia käytetään istunnon suojausasetusten hallintaan joko komentoriviltä tai Avinstaller-verkkopalvelusta.
000222234 | Avamar: Istunnon suojausasetusten hallinta komentoriviliittymässä
000222279 | Avamar: Hallitse istunnon suojausasetuksia Avinstaller-asennuspaketin (AVP) avulla
Tuettuja kokoonpanoja on neljä:
- Ei käytössä
- Sekalainen sinkku
- Todennettu yksittäinen
- Todennettu – kaksi
Poistettu käytöstä
Asetukset:
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"
Kun istunnon suojaus on poistettu käytöstä, asiakkaat muodostavat yhteyden vain Avamarin Avagent-palveluun portin 28001 kautta, ja asiakkaat kuuntelevat Avamarin pyyntöjä Avagent-portissa 28002.
Välityspalvelin kuuntelee numeroa 28009.
Portti 28001 on tavallinen TCP-kanta eikä suorita TLS-kättelyjä.
Asiakas muodostaa yhteyden Avamar GSAN -porttiin 29000 ja suorittaa yksisuuntaisen TLS-kättelyn. Tämä tarkoittaa sitä, että vaikka Session Security olisi poistettu käytöstä, kun varmuuskopiotietoja siirretään asiakkaan ja Avamarin välillä, tiedot salataan lennon aikana.
Avamar-ohjelmiston todennusvarmenteita ei vaihdeta Avamarin, välityspalvelinten, asiakkaiden ja Data Domainin välillä.
Sekalainen sinkku
Asetukset:
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"
Yhdistelmäsingletilaa käytettiin enemmän, kun istunnon suojaus otettiin ensimmäisen kerran käyttöön Avamar 7.3 -versiossa. Sen avulla erityisesti ne asiakkaat, joiden versio ei ollut 7.3 tai uudempi, voivat rekisteröityä ja varmuuskopioida Avamariin. Tätä artikkelia kirjoitettaessa Avamar 19.10 on uusin versio ja Mixed-Single on käytännössä sama kuin seuraava keskusteltava tila. Todennettu yksittäinen.
Todennettu yksittäinen
Asetukset:
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"
Tässä tilassa istunnon suojaus on käytössä ja varmenteet siirretään Avamarin, asiakkaiden, välityspalvelinten ja Data Domainin välillä todennusta varten ennen varmuuskopiointia.
Asiakkaat kuuntelevat nyt portissa 30002 Avamarin Avagent-työtilauspyyntöjä, ja välityspalvelimet kuuntelevat portissa 30009. Avamar kuuntelee porteissa 30001 ja 30003 asiakkaiden ja välityspalvelinten yhteyspyyntöjä. Nämä ovat SSL-pistokkeita, jotka suorittavat TLS-kättelyjä.
Todennettu yksittäinen tila pakottaa kaikki asiakkaat rekisteröitymään istunnon suojausmenetelmillä, toisin kuin yksittäinen yhdistelmätila.
Tämä asetus poistaa Avamarin GSANin verifypeerin käytöstä, mikä tarkoittaa, että GSAN ei tarvitse asiakasvarmenteita saapuvasta avtar-yhteydestä.
Todennettu – kaksi
Asetukset:
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 on sama kuin Authenticated-Single, paitsi että se mahdollistaa verifypeer-asetuksen Avamarin GSAN-palvelussa.
Authenticated-Dualia pidetään vahvimpana Avamar-palvelimessa käytettävänä asetuksena, ja se on oletusvalinta Avamar-käyttöönottojen aikana.
Yleiskatsaus: Avamarin sisäinen itse allekirjoitettu päämyöntäjä
Avamarin sisäinen päävarmenteiden myöntäjä on sisäisesti luotettu varmenteiden myöntäjä Avamarille ja niille asiakkaille, välityspalvelimille ja Data Domaineille, joita Avamar tuo niihin.
Avamar on oma sisäinen varmenteiden myöntäjä, koska se myöntää varmenteita varmenteiden allekirjoituspyynnöille (CSR).
Kun Avamar käyttää päämyöntäjäänsä GSAN-varmenteiden allekirjoittamiseen, ne tallennetaan seuraavaan sijaintiin:
/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
Jos tietoturvatarkistus skannaa Avamarin portin 29000, se ilmoittaa kyseisen portin itse allekirjoitetut varmenteet GSANille.
Joissakin ympäristöissä tämä ei välttämättä ole hyväksyttävää, ja suosittelemme lukemaan seuraavasta tietämyskannan artikkelista lisätietoja Avamarin sisäisen päävarmenteen myöntäjän korvaamisesta käyttäjän toimittamalla sisäisellä päämyöntäjällä.
Tietämyskannan 000204629 | Avamar: Avamar Certificate Authorityn (CA) asentaminen tai korvaaminen käyttäjän toimittamalla varmenteiden myöntäjällä (CA)
Prosessissa kerrotaan, miten yrityksen sisäinen importcert.sh-varmenteiden myöntäjä asennetaan komentosarjan avulla. Käyttäjän toimittamaa varmenteen myöntäjää hallinnoi todennäköisesti tietoturvatiimi, koska mikään julkinen varmenteiden myöntäjä ei luovuta varmentajansa yksityistä avainta, koska se on syy, miksi he ansaitsevat rahaa allekirjoittamalla varmenteita muille ja ylläpitämällä luottamusketjua.
Esimerkki sisäisestä varmenteiden myöntäjästä on Microsoft Active Directory -varmennepalvelut.
Mikä on Active Directory -varmennepalvelut? | Microsoft Learn
Esimerkki julkisesta varmenteiden myöntäjästä on DigiCert.
Avamarin sisäisen varmenteiden myöntäjän korvaaminen tapahtuu korvaamalla Avamar-avainsäilön pääavainpari käyttäjän toimittamalla CA-avainparilla. Sitten GSAN luo CSR: n ja yksityisen avaimen, saa CSR: n allekirjoitetuksi uudella CA-avainparilla ja aiemmin tässä osassa mainitut tiedostot korvataan. GSAN lataa SSL-kannan uudelleen portissa 29000, ja uudet asiakkaat, jotka muodostavat yhteyden GSANIIN, katso käyttäjän antama CA.
Security Scanners näyttää nyt allekirjoitetut varmenteet portissa, ja asiakkaiden, välityspalvelinten ja Data Domainin on rekisteröidyttävä uudelleen saadakseen uuden varmenteen.
Rajoitukset
Avamar-istunnon suojausominaisuuksiin liittyy joitakin rajoituksia:
- Asiakkaat
- Istunnon suojausominaisuuksia ei voi käyttää seuraavien Avamar-työasemien kanssa:
- Avamar-klusteriasiakas Solarikselle Veritas-klusteripalvelimessa
- Avamar client Solarikselle Solaris-klustereissa
- Istunnon suojausominaisuuksia ei voi käyttää seuraavien Avamar-työasemien kanssa:
- Muut tuotteet
- Avamar-palvelimen, Avamar Clientien ja Data Domain -järjestelmän NTP-aikasynkronoinnin käyttö (jos sovellettavissa) on suositeltavaa. Jos aikaa ei synkronoida, seurauksena voi olla rekisteröinti ja varmuuskopiointi-/palautusvirhe varmenteen voimassaolon ja vanhentumisaikojen vuoksi. Isännän aikavyöhykkeen muuttamisella voi olla samanlainen vaikutus, ja se voi edellyttää varmenteen uudelleenluomista.
- Suojattu tunnus
- Suojattu tunnustodennus ei toimi seuraavissa olosuhteissa:
- Asiakastietokone on NAT (Network Address Translation) -palomuurilaitteen takana
- Asiakkaan isäntänimi on virtuaalinen nimi, joka ei ole sama kuin sen IP-osoitteesta ratkaistu täydellinen toimialuenimi
- Asiakaskoneessa on useita IP-rajapintoja, joista jokainen päätyy eri täydelliseen toimialuenimeen (FQDN). Lisätietoja on seuraavassa tietämyskannan artikkelissa: KB 000056252 | Avamar: Varmuuskopiointi Data Domainiin epäonnistui sanomalla DDR_GET_AUTH_TOKEN, koska IP-osoitteita oli liikaa
- Suojattu tunnustodennus ei toimi seuraavissa olosuhteissa:
Istunnon suojauksen muutoksen suunnittelu
Ennen kuin teet muutoksia istunnon suojausasetuksiin, voit palauttaa aiemmat määritykset tai varmenteet ennen muutosten tekemistä seuraavasti.
Muista, että jos Avamarin sisäistä päävarmenteiden myöntäjää muutetaan, asiakkaiden, välityspalvelinten ja Data Domainin on rekisteröidyttävä uudelleen. Ympäristön koosta (asiakkaiden, välityspalvelinten ja Data Domainien määrä) riippuen tämä voi olla hankala, muutaman päivän mittainen tehtävä.
Käyttötapaus olisi, jos varmenteet luodaan uudelleen, ja nyt rekisteröinti ja varmuuskopiointi epäonnistuivat.
Olettaen, että varmenteet eivät vanhene tai ole vanhenemassa ja ne luodaan uudelleen ehkä vahingossa, seuraavat vaiheet tarjoavat joitain ohjeita siitä, miten estää tietojen menetys tai tietojen käytettävyystilanne.
Hae nykyiset istunnon suojausasetukset ja kirjoita ne muistiin:
enable_secure_config.sh --showconfig
Tee kopio Avamar-avainsäilöstä:
cp -p /usr/local/avamar/lib/avamar_keystore /usr/local/avamar/lib/x-avamar_keystore-original
Oletetaan, että varmenteet luodaan nyt uudelleen joko Session Security AVP- tai CLI-menetelmillä.
Tämä tarkoittaa, että Avamar-avainsäilö on muuttunut ja GSAN-varmenteet on allekirjoitettu uudelleen.
Alkuperäisen Avamar-avainsäilön voi siirtää takaisin paikalleen:
cp -p /usr/local/avamar/lib/x-avamar_keystore-original /usr/local/avamar/lib/avamar_keystore
Luo GSAN-varmenteet uudelleen:
enable_secure_config.sh --certs
Käynnistä MCS ja varmuuskopiointiajoitus uudelleen:
mcserver.sh --restart --force dpnctl start sched
Tämä palauttaa alkuperäisen Avamarin sisäisen päävarmenteiden myöntäjän, johon asiakkaat, välityspalvelimet ja Data Domain jo luottivat.
Vianmääritys
Useimmiten istunnon suojausasetusten muuttaminen tai varmenteiden luominen uudelleen on yksinkertaista.
Tässä osiossa kerrotaan, miten kaikki saadaan toimimaan uudelleen varmenteiden luomisen tai asetusten muuttamisen jälkeen.
Paikalliset huuhtelut
Kun verifypeer on käytössä ja kaikki Avamar-varmenteet luodaan uudelleen, Avamar-palvelimen avtar- ja avmgr-käytössä olevat asiakasvarmenteet eivät päivity välittömästi.
Tämä tarkoittaa sitä, että kun MCS suorittaa ajoitetun tyhjennyksen (MCS-kokoonpanon varmuuskopiointi GSANiin), se epäonnistuu TLS-kättelyvirheen vuoksi. Tämä johtuu siitä, että Avamar-palvelimessa käynnissä olevien avtar-asiakasvarmenteiden varmenteet eivät ole vielä saaneet päivitettyä Avamarin sisäistä päävarmenteiden myöntäjää ja uusia allekirjoitettuja asiakasvarmenteita.
Lisätietoja on seuraavassa tietämyskannan artikkelissa:
000214340 | Avamar: Avtar ei saa yhteyttä Avamarin GSAN-palveluun. "Fatal server connection problem, suspending initialization. Tarkista oikea palvelimen osoite ja kirjautumistiedot."
Replikointi
Skenaariossa, jossa verifypeer on käytössä replikointikohteessa ja varmenteet luodaan uudelleen kohteessa, on käytettävä samanlaista lähestymistapaa yllä olevasta Paikalliset huuhtelut -osiosta.
Varmista ensin, että replikointikohde Avagent on rekisteröity, jotta se voi hyväksyä replikoinnin työtilauksia.
Tarkista Avagent-loki määränpäässä seuraavasta sijainnista:
/usr/local/avamar/var/client/avagent.log
Terve loki voi näyttää tältä:
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
Kun palaat taaksepäin lokissa, uudelleenrekisteröinti saattaa olla äskettäin onnistunut:
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
Epäterveellinen loki, jossa on varmenteen muutosten aiheuttamia rekisteröintiongelmia, voi näyttää tältä:
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.
Jotta Avagent voidaan rekisteröidä välittömästi uudelleen MCS:ään, toimi seuraavasti:
Hanki MC_SYSTEM-tilin nimi, joka on todennäköisesti 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
Poista MC_SYSTEM tili käytöstä:
mccli client edit --name=/MC_SYSTEM/<avamar_fqdn> --activated=false example: mccli client edit --name=/MC_SYSTEM/avamar.lab --activated=false
Rekisteröi MC_SYSTEM tili uudelleen:
/etc/init.d/avagent register <avamar_fqdn> /MC_SYSTEM example: /etc/init.d/avagent register avamar.lab /MC_SYSTEM
Kun rekisteröinti on onnistunut, Avagent voi hyväksyä replikoinnin kohteessa.
Jos verifypeer on käytössä replikointikohde Avamarissa, meidän on nyt luotava uudelleen asiakasvarmenteet, joilla muodostetaan yhteys kohde-Avamariin.
Muistuttavat naapurustoa KB 000214340 | Avamar: Avtar ei saa yhteyttä Avamarin GSAN-palveluun. "Fatal server connection problem, suspending initialization. Tarkista oikea palvelimen osoite ja kirjautumistiedot."
Poista nykyinen Avamar-varmenteiden kohdekansio Avamar ssh -lähdeistunnosta:
rm -r /usr/local/avamar/etc/<destination_avamar_ip_address> rm -r /usr/local/avamar/etc/client/<destination_avamar_ip_address>
Luo asiakasvarmenteet uudelleen:
/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
Tiedonsiirto kohteeseen Avamar voidaan testata Lähde-Avamar ssh -komentoriviltä:
avmgr logn --id=repluser --ap=<destination_repluser_password> --hfsaddr=<destination_avamar_ip_address> --debug --x19=1024 --x30=8192
Asiakkaan rekisteröinti
Varmuuskopiointia voidaan yrittää sen jälkeen, kun istunnon suojausasetuksia on muutettu tai varmenteet on luotu uudelleen.
Tämä voi johtaa siihen, että löydät monia agenttipohjaisia asiakkaita odottavan asiakkaan tilassa, kunnes varmuuskopiointi ei onnistu aikakatkaisun käynnistyksellä.
Kun uudet varmenteet on luotu uudelleen, kestää noin 23 tuntia, ennen kuin asiakas yrittää automaattisesti rekisteröityä uudelleen.
Avamar-palvelimessa voidaan lähettää seuraava komento asiakaspalvelijoille kutsu rekisteröityä uudelleen Avamarin MCS:ään.
mccli client re-register-all
Komennon suorittaminen voi kestää jonkin aikaa asiakkaiden määrän mukaan, koska se lähettää kutsun kullekin asiakkaalle järjestyksessä. Harkitse komennon suorittamista taustalla siltä varalta, että ssh-istunto aikakatkaistaan.
nohup mccli client re-register-all &
Huomaa, että tämä ei välttämättä toimi kaikkien agenttipohjaisten asiakkaiden uudelleenrekisteröinnissä, ja jotkut on ehkä rekisteröitävä uudelleen manuaalisesti.
Manuaalinen prosessi asiakkaan rekisteröimiseksi uudelleen Windowsissa olisi:
- Poista seuraavan hakemiston sisältö, joka sisältää vanhat asiakasvarmenteet:
-
"C:\Program Files\avs\etc"
-
- Käynnistä Backup Agent -palvelu uudelleen
- Poista seuraavan hakemiston sisältö, joka sisältää vanhat asiakasvarmenteet:
-
/usr/local/avamar/etc
-
- Käynnistä Avagent-palvelu uudelleen:
-
service avagent restart
-
Asiakaskoneen uudelleenkäynnistys voidaan myös tehdä täydellisen uudelleenrekisteröinnin käynnistämiseksi.
Huomaa, että nimenselvitys on tärkeässä asemassa asiakkaiden rekisteröinnissä. Kun istunnon suojaus on käytössä, varmista, että asiakkaat voivat tehdä Avamar-palvelimesta DNS-haun eteen- ja taaksepäin ja päinvastoin. Tämä voidaan saavuttaa joko määrittämällä DNS A -tietueet tai isäntämerkinnät asiakkaassa.
Avamar ei tarjoa minkäänlaista komentosarjaa, joka ottaisi yhteyttä jokaiseen liitettyyn asiakkaaseen manuaalista uudelleenrekisteröintiä varten. Aiemmin mainittu mccli-komento on lähimpänä sitä.
Välityspalvelimen rekisteröinti
Virtuaalikoneet, jotka varmuuskopioidaan Avamariin välityspalvelimilla, ovat jossain määrin etulyöntiasemassa istunnon jälkeisissä tietoturvamuutoksissa, koska välityspalvelimia on yleensä paljon vähemmän kuin agenttipohjaisia asiakkaita.
Valtakirjojen tulisi myös yrittää automaattista uudelleenrekisteröintiä 23 tunnin kuluessa, mutta voi olla helpompaa ja nopeampaa rekisteröidä ne uudelleen välittömästi.
Käytettävissä on muutamia vaihtoehtoja yrittää pakottaa uudelleenrekisteröinti välityspalvelimiin.
Ensimmäinen vaihtoehto voi olla käynnistää välityspalvelimet uudelleen seuraavalla komennolla:
mccli mcs reboot-proxy --all
Toinen vaihtoehto olisi käyttää Goav-työkalua välityspalvelimien hallintaan.
Aseta välityspalvelimen salasana Goav-työkalulle, jotta se voi kirjautua välityspalvelimiin milloin tahansa. Seuraava komento ei muuta välityspalvelimen käyttöjärjestelmän salasanaa, se vain tallentaa salasanan salattuna, jotta Goav-työkalu voi käyttää sitä kirjautuakseen välityspalvelimeen aina, kun sen on oltava ssh: n kautta.
./goav proxy set-password
Käynnistä Avagent uudelleen kaikissa liitetyissä välityspalvelimissa:
./goav proxy exec "service avagent restart"
Voit tarkistaa välityspalvelimen Avagent-lokista, onnistuiko uudelleenrekisteröinti, suorittamalla seuraavan komennon:
./goav proxy exec "grep -i registration /usr/local/avamarclient/var/avagent.log"
Onnistunut tulos voi näyttää tältä:
============== 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.
Kolmas vaihtoehto on muodostaa ssh-yhteys välityspalvelimeen ja suorittaa alustuskomentosarja:
/usr/local/avamarclient/etc/initproxyappliance.sh start
Data Domain -synkronointi
Kun istunnon suojausasetuksia muutetaan tai varmenteet luodaan uudelleen Avamarissa, Data Domain on synkronoitava uudelleen tai SSL-yhteys muodostettava uudelleen.
Seuraavassa tietämyskannan artikkelissa käsitellään tätä tilannetta ja uusien varmenteiden vaihtamista Data Domainiin.
000197106 | Avamar- ja Data Domain -integrointi: DD näkyy punaisena Avamar AUI:ssa ja/tai käyttöliittymässä Ratkaisupolku
On erittäin suositeltavaa hoitaa Avamarin ja Data Domainin SSL-vianmääritys Goav-työkalulla.
Goavin avulla Data Domainin SSL-yhteys Avamariin voidaan diagnosoida ja ratkaista automaattisesti. Lisätietoja on seuraavassa tietämyskannan artikkelissa:
000215679 | Avamar: Tietoja Goav dd check-ssl -ominaisuudesta
Korjaa Avamar- ja Data Domain -varmenteet automaattisesti suorittamalla seuraava komento:
./goav dd check-ssl --fix