Avamar: Безпека сесії

Що таке безпека сесії?

Безпека сесій: Посібник з

безпеки продукту Клієнти Avamar можуть використовувати безпеку сесій для захисту всіх комунікацій між сервером Avamar і клієнтським програмним забезпеченням Avamar. Сервер Avamar надає автентифікацію клієнту Avamar, а клієнт Avamar — для сервера

Avamar.Функції безпеки сесій включають покращення безпеки для комунікації між процесами системи Avamar.
Avamar забезпечує всі комунікації між процесами системи Avamar за допомогою сесійних квитків. Потрібен дійсний квиток на сесію, перш ніж процес Avamar приймає передачу від іншого процесу Avamar.

Квитки на сесію мають такі загальні характеристики:

• Квиток сесії зашифрований і підписаний для захисту від модифікації
• Сесійний квиток дійсний на короткий час
• Кожен сесійний квиток містить унікальний підпис і призначений лише одному процесу Avamar
• Цілісність сесійного квитка захищена шифруванням
• Кожен вузол системи Avamar окремо перевіряє підпис сесійного квитка
• За потреби сесію можна продовжити понад термін дії квитка сесії

Avamar виступає приватним органом сертифікації та генерує унікальний серверний сертифікат для системи Avamar.

Система Avamar встановлює публічний ключ до сертифіката сервера на кожному клієнті Avamar, зареєстрованому на сервері Avamar. Клієнти Avamar використовують публічний ключ для автентифікації передач із системи Avamar.

Для клієнтів, які вже зареєстровані, публічний ключ для серверного сертифіката та інших необхідних файлів сертифікатів передавається клієнту протягом години після встановлення

.Система Avamar також автоматично ділиться сертифікатом сервера Avamar з вузлами зберігання Avamar. Спільне використання сертифіката дозволяє утилітальному вузлу та вузлам зберігання надавати однаковий сертифікат для автентифікації.

Клієнтський сертифікат генерується, коли сервер Avamar реєструє клієнта

Avamar.Після створення сертифіката клієнта система Avamar використовує зашифроване з'єднання з клієнтом Avamar для встановлення сертифіката на клієнт. Система Avamar також зберігає публічний ключ для сертифіката клієнта. Публічний ключ використовується для автентифікації клієнта у всіх наступних комунікаціях.

Як працює Security Session Security?

Сесійна безпека увімкнена на сервері Avamar. При увімкненні клієнти, проксі та системи домену даних проходять спеціальний процес реєстрації сертифікатів у Avamar

.На Windows або Linux клієнті та проксі під час реєстрації видно, що сервер Avamar має увімкнену Session Security. Avamar надсилає свій внутрішній кореневий CA клієнту (chain.pem), щоб клієнт міг зберігати і довіряти її. Клієнт генерує запит на підписання сертифікатів (CSR). CSR (avclient.csr) надсилається від клієнта до MCS-процесу сервера Avamar, який підписує CSR і повертає клієнту пару ключів сертифіката (key.pem та cert.pem).

У домені даних, при прикріпленні домену даних до Avamar або при оновленні SSL-комунікації, Avamar бачить, що домен даних не має підписаного сертифіката від нього або іншого перевіреного Avamar (imported-host DDBoost). Avamar використовує домен даних SSH приватний ключ для входу в домен даних для запуску SSH" командує над оболонкою Data Domin (DDSH). Avamar витягує запит на підписання сертифіката домену даних (CSR) через SCP і підписує CSR внутрішнім кореневим CA Avamar. Після того, як домен даних отримає підписаний сертифікат від Avamar (imported-host DDBoost), Avamar імпортує кореневий CA, який підписав сертифікат (chain.pem as imported-CA DDBoost/login-auth).

Тепер, коли клієнт/проксі зареєстровано і має клієнтські сертифікати, необхідні для автентифікації за допомогою MCS Avamar, намагається зробити резервне копіювання. Avamar надсилає робоче замовлення слухачу Avagent клієнта або проксі, який отримує робочий наказ. Клієнт або проксі потім перевіряє та перевіряє ланцюг сертифікатів сервера Avamar, використовуючи кореневий CA Avamar, який Avamar імпортував клієнту під час реєстрації. Так само Avamar автентифікує клієнта або проксі. Наразі жодних даних не було передано.

Після успішної автентифікації починається робочий наказ, і його статус змінюється з «Очікування клієнта» на «Запущений».

Тепер клієнти та проксі зрештою передають дані до Avamar і Data Domain, використовуючи встановлений на них двійковий файл avtar. Двійковий файл avtar передає деякі прапорці, які контролюють деталі переміщення даних і того, які дані переміщуються.

Коли avtar на клієнті або проксі підключається до GSAN Avamar, він має знати, чи увімкнено verifypeer. Налаштування verifypeer — це налаштування сервера GSAN у складі конфігурації Session Security, яке керує SSL-сокетом GSAN на порті 29000, повідомляючи, чи потрібно вимагати клієнтські сертифікати для кожного вхідного з'єднання. На щастя, реалізовано протокол TLS 1.2, який автоматично обробляє, як клієнт або проксі мають представляти свої клієнтські сертифікати GSAN під час TLS-рукостискання.

Нижче наведено демонстрацію взаємного/двостороннього рукостискання TLS, коли увімкнено verifypeer.
З точки зору клієнта або проксі, стрілка, що вказує праворуч, означає підключення до сервера Avamar. Стрілка, що вказує ліворуч, — це з'єднання, що надходить від сервера Avamar до клієнта.

[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

Коли verifypeer вимкнено, клієнт не зобов'язаний надсилати клієнтський сертифікат до 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

Важливо, що клієнт або проксі отримували необхідні клієнтські сертифікати, щоб мати змогу виконувати взаємне TLS-рукостискання, якщо це вимагатиме GSAN.

Це означає, що якщо змінюється всередині кореневого CA Avamar, клієнт, проксі або домен даних повинні отримати від нового кореневого CA підписання сертифікатів для них.

Після успішного підключення клієнта або проксі до GSAN, він намагається підключитися до домену даних.

Наступний журнал показує проксі, що підключається до Data Domain за допомогою avtar. Налаштування verifypeer вимкнене, але режим Session Security увімкнено (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

Оскільки verifypeer — це налаштування сервера Avamar GSAN, це не впливає на те, як avtar безпосередньо підключається до Data Domain, якщо увімкнено Session Security. Це означає, що між клієнтом або проксі та доменом даних відбувається взаємне TLS-рукостискання.

Клієнт або проксі може валідувати ланцюг сертифікатів домену даних, оскільки він має той самий внутрішній кореневий CA Avamar, який був імпортований Avamar під час реєстрації клієнта (або під час редагування чи вкладення в DD).

Proxy
------
Avamar internal root CA
/usr/local/avamarclient/etc/chain.pem


Data Domain
--------------
Avamar internal root CA
run command to view certificate list on DD: adminaccess certificate show
imported-ca ddboost


/usr/local/avamarclient/etc/chain.pem == imported-ca ddboost

Після перевірки сертифіката рукопотискання завершується, а резервні дані переміщуються з клієнта до домену даних і Avamar у мережі.

Керування налаштуваннями безпеки сесії

Наступні дві статті використовуються для керування налаштуваннями безпеки сесії або з командного рядка, або через веб-сервіс Avinstaller.

Avamar: Керування налаштуваннями безпеки сесії з CLI
Avamar: Керування налаштуваннями безпеки сесій за допомогою пакету встановлення Avinstaller (AVP)

Існує чотири можливі підтримувані конфігурації:

1. Вимкнено
2. Мікс-сингл
3. Автентифіковано-Сингл
4. Автентифіковано-дуальна система

Вимкнено

Налаштування

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"

Коли Session Security вимкнено, клієнти підключаються лише до сервісу Avagent Avamar на порту 28001, а клієнти слухають запити від Avamar на порті Avagent 28002.

Проксі слухає на 28009.

Порт 28001 — це звичайний TCP-роз'єм, який не виконує TLS-рукостискання.

Клієнт підключається до GSAN Avamar на порту 29000 і виконує одностороннє TLS-рукостискання. Це означає, що навіть коли Session Security вимкнено, коли резервні дані передаються між клієнтом і Avamar, вони все одно зашифровані під час польоту.

Сертифікати автентифікації за допомогою програмного забезпечення Avamar не обмінюються між Avamar, проксі, клієнтами та доменом даних.

Мікс-сингл

Налаштування

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 використовувався частіше, коли в Avamar 7.3 вперше з'явилася Session Security, що дозволяло клієнтам із версією не 7.3 або вище реєструватися та робити резервні копії на Avamar. На момент написання цієї статті Avamar 19.10 є останньою версією, і Mixed-Single фактично є тим самим, що й наступний режим, про який варто говорити; Автентифіковано-Одиноко.

Автентифіковано-Сингл

Налаштування

Current Session Security Settings
----------------------------------
"encrypt_server_authenticate"                           ="true"
"secure_agent_feature_on"                               ="true"
"session_ticket_feature_on"                             ="true"
"secure_agents_mode"                                    ="secure_only"
"secure_st_mode"                                        ="secure_only"
"secure_dd_feature_on"                                  ="true"
"verifypeer"                                            ="no"

У цьому режимі активується безпека сесій, а сертифікати передаються між Avamar, клієнтами, проксі та доменом даних для автентифікації перед резервним копіюванням.

Клієнти тепер слухають на порті 30002 запити на робочі замовлення Avagent від Avamar, а проксі — на порті 30009. Avamar прослуховує на портах 30001 і 30003 запити на підключення від клієнтів і проксі. Це SSL-роз'єми, які виконують TLS-рукостискання.

Режим автентифікації з одиночкою змушує всіх клієнтів реєструватися за допомогою методів безпеки сесії, на відміну від режиму змішаного одиночного режиму.

У цьому режимі вимкнено verifypeer на GSAN-і Avamar, тобто GSAN не вимагає клієнтських сертифікатів від вхідного avtar-з'єднання.

Автентифіковано-дуальна система

Налаштування

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 — це те саме, що й Authenticated-Single, але дозволяє налаштування verifypeer на сервісі GSAN від Avamar.

Authenticated-Dual вважається найсильнішим налаштуванням для застосування на сервері Avamar і є вибором за замовчуванням під час розгортань Avamar.

Огляд: Avamar — внутрішній самопідписаний кореневий CA

Внутрішній кореневий CA Avamar є внутрішньо довіреним центром сертифікації для Avamar та клієнтів, проксі та доменів даних, які Avamar імпортує до них.

Avamar є внутрішньою CA для себе, оскільки видає сертифікати для запитів на підписання сертифікатів (CSR).

Коли Avamar використовує свій кореневий CA для підписання сертифікатів для GSAN, вони зберігаються у наступному місці:

/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

Якщо сканер безпеки сканує порт 29000 на Avamar, він повідомляє про самопідписані сертифікати на цьому порту, який обробляє резервні копії до GSAN.

У деяких середовищах це може бути неприйнятно, тому рекомендується ознайомитися з наступною статтею Dell для отримання додаткової інформації про заміну внутрішнього кореневого CA Avamar на внутрішнього кореневого CA, наданого користувачем.

Avamar: Встановити або замінити центр сертифікації Avamar (CA) на центр сертифікації, наданий користувачем (CA) 

Процес детально описує, як використовувати скрипт importcert.sh для встановлення сертифікаційного центру, який надається користувачем і знаходиться всередині їхньої компанії. Центр сертифікації, наданий користувачем, ймовірно, управляється командою безпеки, оскільки жоден публічний центр сертифікації не надає приватний ключ для свого CA, оскільки саме через це вони заробляють, підписуючи сертифікати для інших і підтримуючи ланцюжок довіри.

Прикладом внутрішнього CA є Microsoft Active Directory Certificate Services.
Що таке сертифікаційні сервіси Active Directory? | Microsoft Learn (Зовнішнє посилання) Прикладом

публічного CA є DigiCert.

Заміна внутрішньої кореневої CA Avamar працює шляхом заміни кореневої пари ключів у сховищі ключів Avamar на пару ключів CA, надану користувачем. Потім GSAN генерує CSR і приватний ключ, отримує підпис CSR новою парою ключів CA, і файли, згадані раніше в цьому розділі, замінюються. GSAN перезавантажує SSL-роз'єм на порті 29000, і нові клієнти, що підключаються до GSAN, бачать CA, наданий користувачем.

Сканери безпеки тепер показуватимуть підписані сертифікати на порту, а клієнти, проксі та домен даних мають повторно реєструватися, щоб отримати новий CA.

Обмеження

Функції безпеки сесії Avamar мають певні обмеження:

• Клієнтська система
  • Функції безпеки сесій не можуть використовуватися з жодним із наступних клієнтів Avamar:
    • Avamar cluster client for Solaris on Veritas Cluster Server
    • Avamar client for Solaris in Solaris clusters
• Інші продукти
  • Заохочується використання синхронізації часу NTP сервера Avamar, клієнтів Avamar та системи домену даних (якщо це застосовно). Якщо час не синхронізований, це може призвести до невдачі реєстрації та резервного копіювання/відновлення через терміни дії та терміну дії сертифіката. Зміна часового поясу на хості може мати подібний вплив і вимагати відновлення сертифіката.
• Secure Token
  • Захищена автентифікація токенів не працює за таких умов:
    • Клієнтська машина розташована за міжмережевим інтерфейсом (NAT) фаєрволом
    • Ім'я хоста клієнта — це віртуальне ім'я, яке відрізняється від FQDN, розв'язаного з IP-адреси
    • Клієнтська машина має кілька IP-інтерфейсів, і кожен з них розв'язується на окреме повністю кваліфіковане доменне ім'я (FQDN). Дивіться наступну статтю Dell для детальнішої інформації: Avamar: Резервне копування в Data Domain не вдалося з повідомленням "DDR_GET_AUTH_TOKEN" через надто багато IP-адрес 

Планування змін безпеки сесій

Перед зміною налаштувань безпеки сесії можна виконати наступні кроки, щоб мати можливість відновити попередню конфігурацію або сертифікати перед внесенням будь-яких змін

.Пам'ятайте, що якщо змінюється внутрішнього кореневого CA Avamar, клієнти, проксі та домен даних мають повторно зареєструватися. Залежно від розміру середовища (кількість клієнтів, проксі та доменів даних) це може бути незручним завданням, яке триває кілька днів.

Сценарій використання — якщо сертифікати будуть відновлені, а тепер виникають збої з реєстрацією та резервним копіюванням.

З урахуванням, що сертифікати не закінчені і не ось-ось закінчені, а їх відновлюють, можливо, випадково, наступні кроки дають певні рекомендації, як запобігти втраті даних або недоступності даних.

Отримайте поточні налаштування Session Security і запишіть їх:

enable_secure_config.sh --showconfig

Зробіть копію магазину ключів Avamar:

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

Припустимо, що сертифікати тепер відновлюються за допомогою методів Session Security AVP або CLI

.Це означає, що сховище ключів Avamar змінилося, а сертифікати GSAN були перепідписані.

Оригінальний магазин ключів Avamar можна просто повернути на місце:

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

Відновити сертифікати GSAN:

enable_secure_config.sh --certs

Перезапуск MCS і резервний планувальник:

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

Це відновлює оригінальний внутрішній кореневий CA Avamar, якому клієнти, проксі та домен даних вже довіряли.

Пошук і виправлення несправностей

У більшості випадків зміна налаштувань безпеки сесій або відновлення сертифікатів — це просто.

Цей розділ має на меті розглянути, як знову все запустити після відновлення сертифікатів або змін налаштувань.

Місцеві змиви

У сценарії, коли verifypeer увімкнено, коли всі сертифікати Avamar відновлені, клієнтські сертифікати, які використовують avtar і avmgr сервера Avamar, не оновлюються одразу

.Це означає, що коли MCS запускає заплановану промивку (резервне копіювання конфігурації MCS у GSAN), вона зазнає невдачі через невдачу TLS Handshake. Це пов'язано з тим, що клієнтські сертифікати для avtar, які працюють на сервері Avamar, ще не отримали оновлений вічний кореневий CA Avamar і новий набір підписаних сертифікатів


клієнта.Реплікація

У сценарії, коли verifypeer увімкнено на місці призначення реплікації, а сертифікати відновлюються на місці, тоді потрібно застосувати схожий підхід із розділу «Локальні змивання» вище.

По-перше, переконайтеся, що Avagent, призначений для реплікації, зареєстрований, щоб він міг приймати робочі накази на реплікацію.

На пункті призначення перевірте журнал Avagent у наступному місці:

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

Здоровий колода може виглядати так:

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

Якщо заглянути далі в журнал, можливо, нещодавно відбулася успішна повторна реєстрація:

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

Нездоровий журнал із проблемами реєстрації, спричиненими змінами сертифікатів, може виглядати так:

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.

У цьому випадку, щоб негайно примусово перереєструвати Avagent у MCS, необхідно виконати такі кроки:

Отримати MC_SYSTEM Ім'я рахунку, ймовірно, 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

Деактивуйте обліковий запис MC_SYSTEM:

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

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

Повторна реєстрація акаунта MC_SYSTEM:

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

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

Після успішної реєстрації Avagent може приймати реплікацію на пункті призначення

.Тепер, на вихідному Avamar, якщо verifypeer увімкнено на місці призначення реплікації Avamar, ми повинні відновити клієнтські сертифікати, які використовуються для підключення до цільового Avamar.

Видалити існуючу папку сертифікатів Avamar з вихідного Avamar SSH Сесія:

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

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

Відновити клієнтські сертифікати:

/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

Зв'язок із пунктом призначення Авамар можна перевірити з Джерела Авамару SSH Командний рядок

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

Реєстрація

клієнтаРезервне копіювання можна зробити після зміни налаштувань безпеки сесії або відновлення сертифікатів.

Це може призвести до того, що багато клієнтів на основі агентів опинилися у статусі «Клієнт очікування», поки не відмовляться від резервної копії з «Тайм-Аут Старт

».Після відновлення нових сертифікатів клієнту має знадобитися близько 23 годин, щоб автоматично спробувати повторну реєстрацію.

Наступна команда може бути використана на сервері Avamar для надсилання запрошення клієнтам на основі агентів на повторну реєстрацію в Avamar MCS.

mccli client re-register-all

Виконання команди може зайняти певний час залежно від кількості клієнтів, оскільки вона надсилає запрошення кожному з них у послідовному порядку. Розгляньте можливість запуску команди у фоновому режимі, якщо SSH Сесія закінчується.

nohup mccli client re-register-all &

Зверніть увагу, що це може не працювати для повторної реєстрації всіх клієнтів на основі агентів, і деякі можуть потребувати повторної реєстрації вручну.

Ручний процес повторної реєстрації клієнта на Windows буде таким:

• Видаліть вміст наступного каталогу, який містить старі клієнтські сертифікати:

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

• Перезапустіть сервіс «Резервний агент»

Ручний процес повторної реєстрації клієнта на Linux полягав у наступному:

• Видаліть вміст наступного каталогу, який містить старі клієнтські сертифікати:

  • /usr/local/avamar/etc

• Перезапустіть сервіс Avagent:

  • service avagent restart

Перезавантаження клієнтської машини також можна виконати, щоб спробувати повністю перереєструватися.

Зверніть увагу, що розв'язання імен відіграє важливу роль у реєстрації клієнтів, коли увімкнено Session Security, переконайтеся, що клієнти можуть виконувати прямий і зворотний DNS-пошук сервера Avamar і навпаки. Цього можна досягти або шляхом налаштування записів DNS A, або записів хостів на клієнті.

Avamar не надає жодного скрипту, який міг би зв'язатися з кожним підключеним клієнтом для ручної перереєстрації, найближче до цього є згадана команда

mccli.Реєстрація

проксіВіртуальні машини, які мають резервне копіювання в Avamar за допомогою проксі, мають певну перевагу при змінах безпеки після сесії, оскільки зазвичай проксі значно менше, ніж клієнти на основі агентів.

Проксі також повинні спробувати автоматичну повторну реєстрацію протягом 23 годин, але це може бути простіше і швидше зробити одразу.

Є кілька варіантів, щоб спробувати примусово перереєструватися на проксі

.Першим варіантом може бути перезавантаження проксі за допомогою наступної команди:

mccli mcs reboot-proxy --all

Другий варіант — використовувати інструмент GoAV для керування проксі

.Встановіть пароль проксі для інструменту GoAV, щоб він міг входити в проксі у будь-який момент, коли це потрібно. Наступна команда не змінює пароль ОС проксі, вона просто зберігає пароль зашифрованим, щоб інструмент GoAV міг використовувати його для входу в проксі у будь-який раз, коли це потрібно SSH.

./goav proxy set-password

Виконайте перезапуск Avagent на всіх підключених проксі:

./goav proxy exec "service avagent restart"

Щоб перевірити лог Avagent у проксі та побачити, чи відбулася успішна повторна реєстрація, виконайте наступну команду:

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

Успішний результат може виглядати так:

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

Третій варіант — SSH до проксі та запустіть скрипт ініціалізації:

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

Синхронізація

домену данихПісля зміни налаштувань безпеки сесії або відновлення сертифікатів на Avamar, домен даних потрібно повторно синхронізувати або встановити SSL-з'єднання.

Наступна стаття Dell розглядає цей сценарій і те, як обміняти нові сертифікати з Data Domain.
Avamar: DD показує червоний у AUI Avamar та/або інтерфейсі користувача (шлях розв'язання)

Рекомендується вирішувати усунення несправностей SSL з Avamar та Data Domain за допомогою інструменту GoAV.

З GoAV SSL-з'єднання домену даних з Avamar можна автоматично діагностувати та розв'язати; дивіться наступну статтю Dell з детальнішою інформацією:
Avamar: Інформація про функцію GoAV dd check-ssl

Виконайте наступну команду для автоматичного виправлення сертифікатів Avamar та Data Domain:

./goav dd check-ssl --fix