Авамар: Безпека сеансу

Що таке безпека сеансу?

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

безпеки продуктуКлієнти 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 також зберігає відкритий ключ для сертифіката клієнта. Публічний ключ використовується для аутентифікації клієнта у всіх подальших комунікаціях.


Як працює безпека сеансів?

Session Security увімкнено на сервері Avamar. Коли увімкнено, клієнти, проксі-сервери та системи Data Domain проходять спеціальний процес реєстрації сертифіката в Avamar.

У клієнті та проксі-сервері Windows або Linux під час реєстрації він бачить, що на сервері Avamar увімкнено Session Security. Avamar надсилає клієнту свій внутрішній кореневий ЦС (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 за допомогою внутрішнього кореневого центру сертифікації Avamar. Після того, як домен даних отримає підписаний сертифікат від Avamar (imported-host ddboost), Avamar імпортує кореневий ЦС, який підписав сертифікат (chain.pem як imported-ca ddboost/login-auth).

Тепер, коли клієнт/проксі-сервер зареєстрований і має сертифікати на стороні клієнта, необхідні для автентифікації в MCS Avamar, робиться спроба резервного копіювання. Avamar надсилає робоче замовлення клієнту або проксі-слухачеві Avagent, який забирає замовлення. Потім клієнт або проксі-сервер перевіряє та перевіряє ланцюжок сертифікатів сервера Avamar, використовуючи кореневий ЦС 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.

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

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

У наведеному нижче журналі показано проксі-сервер, який з'єднується з Data Domain за допомогою avtar. Параметр verifypeer вимкнуто, але ввімкнено Безпеку сеансу (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 з'єднується безпосередньо з доменом даних, якщо ввімкнено безпеку сеансу. Це означає, що між клієнтом або проксі-сервером і доменом даних відбувається взаємне рукостискання TLS.

Клієнт або проксі-сервер може перевірити ланцюжок сертифікатів Data Domain, оскільки він використовує той самий внутрішній кореневий ЦС 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

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


Керування настройками

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

000222234 | Авамар: Керування настройками безпеки сеансу з інтерфейсу командного рядка
000222279 | Авамар: Керування налаштуваннями безпеки сеансу за допомогою інсталяційного пакета 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.

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

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


Змішаний сингл

Параметри:

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"

Змішано-одиночний режим використовувався частіше, коли Session Security був вперше представлений в Avamar 7.3, зокрема, дозволяючи тим клієнтам, чия версія не була 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

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

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

Коли Avamar використовує свій кореневий центр сертифікації для підпису сертифікатів 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.

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

КБ 000204629 | Авамар: Інсталяція/заміна центру сертифікації Avamar (CA) на центр сертифікації, наданий користувачем (CA)

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

Прикладом внутрішнього центру сертифікації може бути Microsoft Active Directory Certificate Services.
Що таке служби сертифікатів Active Directory? | Microsoft Learn

Прикладом публічного ЦС може бути DigiCert.

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

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


Обмеження

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

• Клієнтів
  • Функції безпеки сеансу не можна використовувати з жодним із наступних клієнтів Avamar:
    • Кластерний клієнт Avamar для Solaris на Veritas Cluster Server
    • Клієнт Avamar для Solaris у кластерах Solaris
• Інша продукція
  • Заохочується використання синхронізації часу NTP сервера Avamar, клієнтів Avamar і системи Data Domain (якщо застосовно). Якщо час не синхронізовано, це може призвести до помилки реєстрації та резервного копіювання/відновлення через термін дії сертифіката та термін дії. Зміна часового поясу на хості може мати аналогічний вплив і вимагати повторної генерації сертифіката.
• Токен безпеки
  • Автентифікація захищеного токена не працює за таких умов:
    • Клієнтський комп'ютер стоїть за брандмауером перетворення мережевих адрес (NAT)
    • Ім'я хоста клієнта — це віртуальне ім'я, яке відрізняється від FQDN, визначеного з його IP-адреси
    • Клієнтський комп'ютер має кілька IP-інтерфейсів, і кожен з них має окреме повністю кваліфіковане доменне ім'я (FQDN). Щоб дізнатися більше, перегляньте наступну базу знань: КБ 000056252 | Авамар: Помилка резервного копіювання в Data Domain з повідомленням "DDR_GET_AUTH_TOKEN" через занадто велику кількість IP-адрес

Планування

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

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

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

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

Отримайте поточні параметри безпеки сеансу та запишіть їх:

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, якому вже довіряли клієнти, проксі-сервери та Data Domain.


Виправлення неполадок

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

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

Локальні змиви

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

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

Дивіться наступну базу знань для отримання додаткової інформації:

000214340 | Авамар: Avtar не може підключитися до служби GSAN 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.

Подібно до KB 000214340 | Авамар: Avtar не може підключитися до служби GSAN 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

Зв'язок з адресатом Avamar можна перевірити з командного рядка Source Avamar ssh:

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

Реєстрація

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

Це може призвести до того, що багато клієнтів на основі агентів перебуватимуть у статусі «Клієнт очікування», доки не вдасться створити резервну копію за допомогою «Timed-Out Start».

Після регенерації нових сертифікатів клієнту має пройти близько 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 або записи hosts на клієнті.

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-з'єднання.

У наведеній нижче статті бази знань описано цей сценарій, а також те, як обмінюватися новими сертифікатами за допомогою Data Domain.

000197106 | Інтеграція Avamar і Data Domain: DD Відображається червоним кольором у Avamar AUI та/або інтерфейсі користувача Шлях

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

За допомогою Goav SSL-з'єднання Data Domain з Avamar може бути автоматично діагностовано та вирішено, дивіться наступну базу даних з додатковою інформацією:

000215679 | Авамар: Інформація про функцію

Goav dd check-ssl Виконайте наступну команду, щоб автоматично виправити сертифікати Avamar і Data Domain:

./goav dd check-ssl --fix