Avamar. Session Security

Что такое Session Security?

Session Security. Руководство по безопасности продуктов

Клиенты Avamar могут использовать Session Security для обеспечения безопасности всех операций обмена данными между Avamar Server и Avamar Client. Avamar Server обеспечивает проверку подлинности Avamar Client, а Avamar Client обеспечивает проверку подлинности Avamar Server.

Функции Session Security включают в себя улучшения безопасности для обмена данными между процессами системы Avamar.

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

Запросы сеанса имеют следующие общие характеристики:

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

Avamar выступает в качестве частного центра сертификации и создает уникальный сертификат сервера для системы Avamar.

Система Avamar устанавливает открытый ключ для сертификата сервера на каждом Avamar Client, зарегистрированном на Avamar Server. Клиенты Avamar Client используют открытый ключ для проверки подлинности передач из системы Avamar.

Для клиентов, которые зарегистрированы в настоящее время, открытый ключ сертификата сервера и другие необходимые файлы сертификата передаются клиенту в течение часа после установки.

Система Avamar также автоматически предоставляет общий доступ к сертификату Avamar Server узлам хранения Avamar. Общий доступ к сертификату позволяет служебному узлу и узлам хранения предоставлять один и тот же сертификат для проверки подлинности.

Сертификат клиента генерируется при регистрации клиента Avamar Client сервером Avamar Server.

После создания сертификата клиента система Avamar использует зашифрованное соединение с Avamar Client для установки сертификата на клиент. Система Avamar также хранит открытый ключ для сертификата клиента. Открытый ключ используется для проверки подлинности клиента во всех последующих обменах данными.


Как работает Session Security?

Функция Session Security включена на Avamar Server. Если эта функция включена, клиенты, прокси-серверы и системы Data Domain проходят специальную процедуру регистрации сертификатов в Avamar.

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

В системе Data Domain при подключении Data Domain к Avamar или обновлении соединения SSL экземпляр Avamar распознает, что в системе Data Domain нет подписанного сертификата от него или другого проверенного экземпляра Avamar (imported-host ddboost). Avamar будет использовать закрытый ключ SSH Data Domain для входа в систему Data Domain и выполнения команд SSH через оболочку Data Domain (ddsh). Avamar извлечет запрос на подписание сертификата Data Domain (CSR) через SCP и подпишет CSR с помощью внутреннего корневого CA Avamar. После того как в системе Data Domain будет подписан сертификат из Avamar (imported-host ddboost), Avamar импортирует корневой CA, подписавший сертификат (chain.pem as imported-ca ddboost/login-auth).

Теперь, когда клиент/прокси-сервер зарегистрирован и имеет сертификаты на стороне клиента, необходимые для проверки подлинности в MCS Avamar, выполняется попытка резервного копирования. Avamar отправляет рабочее задание на обработчик событий Avagent клиента или прокси-сервера, который принимает рабочее задание. Затем клиент или прокси-сервер проверяет и подтверждает цепочку сертификатов Avamar Server с помощью корневого CA Avamar, который был импортирован Avamar в клиент во время регистрации. Аналогичным образом Avamar выполняет проверку подлинности клиента или прокси-сервера. На данном этапе никакие данные не были переданы.

После успешного завершения проверки подлинности запускается рабочее задание, и статус рабочего задания меняется с «Waiting-Client» на «Running».

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

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

Ниже приводится демонстрация взаимного/двустороннего подтверждения подключения TLS при включенном параметре verifypeer.
С точки зрения клиента или прокси-сервера стрелка, указывающая вправо, — это подключение к Avamar Server. Стрелка, указывающая влево, — это подключение Avamar Server к клиенту.
 

[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 поменяется, клиент, прокси-сервер или Data Domain должны получить новый корневой CA для подписания сертификатов.

После успешного подключения клиента или прокси-сервера к GSAN он пытается подключиться к Data Domain.

В следующем журнале отображается прокси-сервер, который подключается к Data Domain с помощью avtar. Параметр verifypeer отключен, но включена функция Session Security (режим «Authenticated-Single»). 
 

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. Это означает, что между клиентом или прокси-сервером и системой Data Domain выполняется взаимное подтверждение подключения TLS.

Клиент или прокси-сервер может проверить цепочку сертификатов Data Domain, так как он использует тот же внутренний корневой 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

После проверки сертификата подтверждение подключения завершается, и данные резервного копирования перемещаются из клиента в Data Domain и Avamar в сети.


Управление настройками Session Security

Следующие две статьи используются для управления настройками Session Security с помощью командной строки или веб-службы Avinstaller.

000222234 | Avamar. Управление настройками Session Security из интерфейса командной строки
000222279 | Avamar. Управление настройками Session Security с помощью пакета установки Avinstaller (AVP)
 

Существует четыре возможные поддерживаемые конфигурации:

1. Disabled
2. Mixed-Single
3. Authenticated-Single
4. Authenticated-Dual

Disabled

Настройки:

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 отключена, клиенты подключаются только к службе Avamar Avagent через порт 28001, а клиенты прослушивают порт Avagent 28002 на наличие запросов от Avamar.

Прокси-сервер прослушивает 28009.

Порт 28001 — это обычный TCP-разъем, который не выполняет подтверждение подключения TLS.

Клиент подключается к Avamar GSAN через порт 29000 и выполняет одностороннее подтверждение подключения TLS. Это означает, что даже если функция Session Security отключена, при передаче данных резервного копирования между клиентом и Avamar они шифруются динамически. 

Обмен сертификатами для проверки подлинности с программным обеспечением Avamar между Avamar, прокси-серверами, клиентами и Data Domain не осуществляется.


Mixed-Single

Настройки:

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 использовался чаще, когда функция Session Security была впервые представлена в Avamar 7.3. В частности, он позволял клиентам, версия которых не была 7.3 или выше, регистрироваться и выполнять резервное копирование в Avamar. На момент написания этой статьи последняя версия — это Avamar 19.10, а Mixed-Single работает по сути так же, как и следующий режим: Authenticated-Single.


Authenticated-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"

В этом режиме функция Session Security включена, и перед резервным копированием между Avamar, клиентами, прокси-серверами и Data Domain передаются сертификаты для проверки подлинности.

Теперь клиенты прослушают порт 30002 на наличие запросов рабочих заданий Avagent от Avamar, а прокси прослушивает порт 30009. Avamar прослушивает порты 30001 и 30003 на наличие запросов на подключение от клиентов и прокси-серверов. Это сокеты SSL, которые выполняют подтверждение подключения TLS.

В режиме Authenticated-Single все клиенты принудительно регистрируются с помощью методов Session Security, в отличие от режима Mixed-Single.

В этом режиме параметр verifypeer в Avamar GSAN отключен, что означает, что GSAN не требует сертификаты клиента от входящего подключения avtar.


Authenticated-Dual

Настройки:

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 Server, и является параметром по умолчанию во время развертывания Avamar.


Обзор: Внутренний самозаверяющий корневой CA Avamar

Внутренний корневой CA Avamar — это внутренний доверенный источник сертификатов для Avamar, а также клиентов, прокси-серверов и объектов Data Domain, которые 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.

В некоторых средах это может быть неприемлемо, и рекомендуется ознакомиться со следующей статьей базы знаний для получения дополнительной информации о замене внутреннего корневого CA Avamar на внутренний корневой CA, предоставленный пользователем.

KB 000204629 | Avamar. Установка/замена источника сертификатов Avamar (CA) на источник сертификатов, предоставляемый пользователем (CA)

Процесс описывает использование сценария importcert.sh для установки предоставленного пользователем источника сертификатов внутри компании. Источник сертификатов, предоставляемый пользователем, скорее всего управляется службой ИТ-безопасности, поскольку ни один из общедоступных источников сертификатов не предоставляет закрытый ключ для своего CA, поскольку именно так они зарабатывают деньги, подписывая сертификаты другим лицам и поддерживая цепочку доверия.

Примером внутреннего CA могут служить службы сертификации Microsoft Active Directory.
Что такое службы сертификации Active Directory? | Microsoft Learn

Пример общедоступного CA — DigiCert.

Замена внутреннего корневого CA Avamar выполняется путем замены корневой пары ключей в хранилище ключей Avamar на пару ключей CA, предоставляемого пользователем. Затем GSAN генерирует CSR и закрытый ключ, подписывает CSR новой парой ключей CA, и файлы, упомянутые выше в этом разделе, заменяются. GSAN перезагружает сокет SSL на порте 29000, а новые клиенты, которые подключаются к GSAN, видят предоставленный пользователем CA.

Сканеры безопасности теперь отображают подписанные сертификаты на порте, а клиентам, прокси-серверам и Data Domain необходимо повторно зарегистрироваться, чтобы получить новый CA.


Ограничения

Функция Session Security Avamar имеет некоторые ограничения.

• Клиенты
  • Функции Session Security не могут использоваться ни с одним из следующих клиентов Avamar Client:
    • Avamar Cluster Client for Solaris на Veritas Cluster Server
    • Avamar Client for Solaris в кластерах Solaris
• Другие продукты
  • Рекомендуется использовать синхронизацию времени NTP сервера Avamar Server, клиентов Avamar Client и системы Data Domain (если применимо). Если время не синхронизировано, это может привести к сбою регистрации и резервного копирования/восстановления из-за срока действия сертификата. Изменение часового пояса на хосте может иметь аналогичные последствия и может потребовать повторного создания сертификата.
• Secure Token
  • Проверка подлинности с помощью маркера безопасности не работает при следующих условиях:
    • Клиентский компьютер находится за межсетевым экраном Network Address Translation (NAT).
    • Имя хоста клиента — это виртуальное имя, которое отличается от FQDN, разрешенного по его IP-адресу.
    • На клиентском компьютере имеется несколько IP-интерфейсов, и каждый из них разрешается в другое полное доменное имя (FQDN). Дополнительные сведения см. в следующей статье базы знаний: KB 000056252 | Avamar. Сбой резервного копирования в Data Domain с сообщением «DDR_GET_AUTH_TOKEN» из-за слишком большого количества IP-адресов

Планирование изменений Session Security

Перед внесением изменений в настройки Session Security можно выполнить следующие действия, чтобы обеспечить возможность восстановления предыдущей конфигурации или сертификатов.

Помните, что в случае изменения внутреннего корневого CA Avamar клиенты, прокси-серверы и Data Domain должны зарегистрироваться повторно. В зависимости от размера среды (количество клиентов, прокси-серверов и объектов Data Domain), эта задача может оказаться трудоемкой и растянуться на нескольких дней.

Здесь описан сценарий, когда сертификаты были повторно созданы, а теперь при регистрации и резервном копировании возникают ошибки.

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

Получите текущие настройки 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, которому клиенты, прокси-серверы и объекты Data Domain уже доверяют.


Устранение неисправностей

В большинстве случаев, изменение настроек Session Security или повторное создание сертификатов — это простой процесс.

В этом разделе рассказывается о том, как восстановить работу всех компонентов после повторного создания сертификатов или изменения настроек.

Локальные очистки

В сценарии, когда параметр verifypeer включен, при повторном создании всех сертификатов Avamar клиентские сертификаты, которые используются процессами Avamar Server avtar и avmgr, не обновляются немедленно.

Это означает, что когда MCS выполняет запланированную очистку (резервное копирование конфигурации MCS в GSAN), произойдет сбой из-за ошибки подтверждения подключения TLS. Это связано с тем, что сертификаты клиента для avtar, запущенного на Avamar Server, еще не получили обновленный внутренний корневой CA Avamar и новый набор подписанных клиентских сертификатов.

Дополнительные сведения см. в статье

000214340 | Avamar. Avtar не удается подключиться к службе Avamar GSAN: «Fatal server connection problem, aborting initialization. Verify correct server address and login credentials».

Репликация

В сценарии, когда параметр 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:

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 может принять репликацию на целевом устройстве.

Если параметр verifypeer включен на целевом устройстве репликации, на исходном Avamar необходимо повторно создать сертификаты клиента, используемые для подключения к целевому устройству Avamar.

Аналогично статье базы знаний 000214340 | Avamar. Avtar не удается подключиться к службе Avamar GSAN: «Fatal server connection problem, aborting initialization. Verify correct server address and login credentials». 

Удалите существующую папку сертификатов на целевом устройстве Avamar, подключившись по SSH к исходному Avamar:

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 можно проверить с помощью командной строки, подключившись по SSH к исходному Avamar:

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

Регистрация клиента

Может быть предпринята попытка резервного копирования после изменения настроек Session Security или повторного создания сертификатов.

Это может привести к тому, что многие клиенты на основе агентов будут находиться в состоянии «Waiting-Client» до тех пор, пока не произойдет сбой резервного копирования и состояние не поменяется на «Timed-Out Start».

После повторного создания новых сертификатов клиенту потребуется около 23 часов для автоматической попытки повторной регистрации.

Следующую команду можно использовать на Avamar Server для отправки приглашений клиентам на основе агентов для повторной регистрации в Avamar MCS.

mccli client re-register-all

Выполнение команды может занять некоторое время в зависимости от количества клиентов, поскольку она отправляет приглашение каждому клиенту последовательно. Попробуйте выполнить команду в фоновом режиме, на случай, если время ожидания сеанса SSH истечет.

nohup mccli client re-register-all &

Обратите внимание, что это может не работать для повторной регистрации всех клиентов на основе агентов, и некоторые из них потребуется повторно зарегистрировать вручную.

Регистрация клиента в Windows вручную выполняется следующим образом:

• Удалите содержимое следующего каталога, содержащего старые сертификаты клиента:

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

• Перезапустите службу «Backup Agent».

Процесс повторной регистрации клиента в Linux вручную выполняется следующим образом:

• Удалите содержимое следующего каталога, содержащего старые сертификаты клиента:

  • /usr/local/avamar/etc

• Перезапустите службу Avagent:

  • service avagent restart

Также можно перезагрузить клиентский компьютер, чтобы попытаться инициировать полную повторную регистрацию.

Обратите внимание, что разрешение имен играет важную роль при регистрации клиентов, когда включена функция Session Security. Убедитесь, что клиенты могут выполнять прямой и обратный поиск DNS Avamar Server и наоборот. Это можно сделать, настроив записи 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

Синхронизация Data Domain

После изменения настроек Session Security или повторного создания сертификатов в Avamar необходимо выполнить повторную синхронизацию Data Domain или восстановить подключение SSL.

В следующей статье базы знаний описывается этот сценарий и порядок обмена новыми сертификатами с Data Domain.

000197106 | Интеграция Avamar и Data Domain. DD отображается красным в AUI Avamar и/или пути разрешения пользовательского интерфейса

Настоятельно рекомендуется выполнять поиск и устранение неполадок Avamar и Data Domain SSL с помощью инструмента Goav.

С помощью Goav можно автоматически диагностировать и устранить проблемы SSL-соединения Data Domain с Avamar. Дополнительные сведения см. в следующей статье базы знаний:

000215679 | Avamar. Информация о функции Goav dd check-ssl

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

./goav dd check-ssl --fix