Avamar: Zabezpieczenia sesji

Czym są zabezpieczenia sesji?

Zabezpieczenia sesji: Przewodnik po zabezpieczeniach produktu

Klienty Avamar mogą używać zabezpieczeń sesji do zabezpieczania całej komunikacji między serwerem Avamar a oprogramowaniem klienta Avamar. Serwer Avamar zapewnia uwierzytelnianie klientowi Avamar, a klient Avamar zapewnia uwierzytelnianie serwerowi Avamar.

Funkcje zabezpieczenia sesji obejmują udoskonalenia zabezpieczeń komunikacji między procesami systemu Avamar.

Avamar zabezpiecza całą komunikację między procesami systemu Avamar za pomocą zgłoszeń sesji. Zanim proces Avamar zaakceptuje transmisję z innego procesu Avamar, wymagane jest prawidłowe zgłoszenie sesji.

Zgłoszenia sesji mają następującą ogólną charakterystykę:

• Zgłoszenie sesji jest szyfrowane i podpisywane w celu ochrony przed zmodyfikowaniem
• Zgłoszenie sesji jest ważne przez krótki czas
• Każde zgłoszenie sesji zawiera unikatowy podpis i jest przypisane tylko do jednego procesu Avamar
• Integralność zgłoszenia sesji jest chroniona przez szyfrowanie
• Każdy węzeł systemu Avamar oddzielnie weryfikuje podpis zgłoszenia sesji
• W razie potrzeby sesję można przedłużyć poza okres ważności zgłoszenia sesji

Avamar działa jako prywatny urząd certyfikacji i generuje unikatowy certyfikat serwera dla systemu Avamar.

System Avamar instaluje klucz publiczny certyfikatu serwera na każdym kliencie Avamar zarejestrowanym na serwerze Avamar. Klienty Avamar używają klucza publicznego do uwierzytelniania transmisji z systemu Avamar.

W przypadku klientów, którzy są obecnie zarejestrowani, klucz publiczny certyfikatu serwera i inne wymagane pliki certyfikatów są propagowane do klienta w ciągu godziny od instalacji.

System Avamar automatycznie udostępnia również certyfikat serwera Avamar węzłom pamięci masowej Avamar. Współużytkowanie certyfikatu umożliwia węzłowi mediów i węzłom pamięci masowej dostarczenie tego samego certyfikatu do uwierzytelniania.

Certyfikat klienta jest generowany, gdy serwer Avamar rejestruje klienta Avamar.

Po wygenerowaniu certyfikatu klienta system Avamar używa szyfrowanego połączenia z klientem Avamar w celu zainstalowania certyfikatu na kliencie. System Avamar przechowuje również klucz publiczny certyfikatu klienta. Klucz publiczny służy do uwierzytelniania klienta we wszystkich kolejnych komunikacjach.


Jak działają zabezpieczenia sesji?

Zabezpieczenia sesji są włączone na serwerze Avamar. Po włączeniu tej opcji klienty, serwery proxy i systemy Data Domain przechodzą specjalny proces rejestracji certyfikatów w systemie Avamar.

Klient i serwer proxy z systemem Windows lub Linux w czasie rejestracji wykrywa, że serwer Avamar ma włączone zabezpieczenia sesji. Avamar wysyła swój wewnętrzny główny urząd certyfikacji do klienta (chain.pem), aby klient mógł go przechowywać i ufać mu. Klient generuje żądanie podpisania certyfikatu (CSR). CSR (avclient.csr) zostaje wysłany od klienta do procesu MCS serwera Avamar, który podpisuje CSR i zwraca klientowi parę kluczy certyfikatu (key.pem i cert.pem).

W systemie Data Domain, podczas podłączania systemu Data Domain do systemu Avamar lub po odświeżeniu komunikacji SSL, system Avamar wykryje, że Data Domain nie ma pochodzącego od niego podpisanego certyfikatu lub od innego zweryfikowanego systemu Avamar (certyfikat ddboost importowanego hosta). System Avamar użyje klucza prywatnego ssh Data Domain do zalogowania się do Data Domain w celu uruchomienia poleceń ssh w powłoce Data Domain (ddsh). System Avamar pobiera żądanie podpisania certyfikatu Data Domain (CSR) przez SCP i podpisuje CSR za pomocą wewnętrznego głównego urzędu certyfikacji Avamar. Gdy system Data Domain podpisze certyfikat od Avamar (certyfikat ddboost importowanego hosta), system Avamar zaimportuje główny urząd certyfikacji, który podpisał certyfikat (chain.pem jako importowany urząd certyfikacji ddboost/dane logowania).

Teraz, gdy klient/serwer proxy jest zarejestrowany i dysponuje certyfikatami po stronie klienta wymaganymi do uwierzytelnienia w MCS systemu Avamar, zostanie podjęta próba utworzenia kopii zapasowej. Avamar wysyła zlecenie robocze do klienta lub Avagent listener serwera proxy, który pobiera zlecenie robocze. Następnie klient lub serwer proxy sprawdza poprawność i weryfikuje łańcuch certyfikatów serwera Avamar przy użyciu głównego urzędu certyfikacji Avamar, który został zaimportowany do klienta w czasie rejestracji. Podobnie Avamar uwierzytelnia klienta lub serwer proxy. W tym momencie nie są przekazywane żadne dane.

Po pomyślnym uwierzytelnieniu zlecenie robocze zostaje uruchomione, a stan zlecenia roboczego zmienia się z „Waiting-Client” na „Running”.

W tym momencie klienty i serwery proxy ostatecznie przenoszą dane do Avamar i Data Domain przy użyciu zainstalowanego na nich binarnego pliku avtar. Plik binarny avtar przekazuje kilka flag, które kontrolują szczegóły dotyczące sposobu przenoszenia danych i ich wyboru.

Gdy plik avtar na kliencie lub serwerze proxy łączy się z GSAN Avamar, musi wiedzieć, czy włączona jest funkcja verifypeer. Ustawienie funkcji verifypeer to ustawienie serwera GSAN w ramach konfiguracji zabezpieczeń sesji, które kontroluje gniazdo SSL GSAN na porcie 29000, informując go, czy ma wymagać certyfikatów klienta dla każdego połączenia przychodzącego. Na szczęście zaimplementowany został protokół TLS 1.2, który automatycznie obsługuje sposób, w jaki klient lub serwer proxy powinien przedstawić certyfikaty klienta gsan podczas uzgadniania TLS.

Poniżej przedstawiono prezentację wzajemnego/dwukierunkowego uzgadniania TLS po włączeniu funkcji verifypeer.
Z punktu widzenia klienta lub serwera proxy strzałka skierowana w prawo oznacza połączenie z serwerem Avamar. Strzałka po lewej stronie to połączenie przychodzące z serwera Avamar do klienta.
 

[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

Gdy funkcja verifypeer jest wyłączona, klient nie musi wysyłać certyfikatu klienta do 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

Ważne jest to, aby klient lub serwer proxy uzyskał niezbędne certyfikaty po stronie klienta, aby móc wykonać wzajemny protokół uzgadniania hosta TLS, jeśli jest to wymagane przez GSAN.

Oznacza to, że jeśli zmieni się wewnętrzny główny urząd certyfikacji Avamar, klient, serwer proxy lub Data Domain muszą uzyskać nowy główny urząd certyfikacji, aby podpisywać certyfikaty w ich imieniu.

Po pomyślnym nawiązaniu połączenia klienta lub serwera proxy z usługą GSAN podejmuje próbę nawiązania połączenia z Data Domain.

Poniższy dziennik przedstawia serwer proxy łączący się z Data Domain za pomocą pliku avtar. Funkcja verifypeer jest wyłączona, ale zabezpieczenia sesji są włączone (tryb 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

Ponieważ funkcja verifypeer jest ustawieniem serwera GSAN Avamar, nie ma ona wpływu na sposób, w jaki avtar łączy się bezpośrednio z Data Domain, jeśli włączone są zabezpieczenia sesji. Oznacza to, że między klientem lub serwerem proxy a Data Domain wykonywany jest wzajemny protokół uzgadniania hosta TLS.

Klient lub serwer proxy może zweryfikować łańcuch certyfikatów Data Domain, ponieważ współdzieli ten sam wewnętrzny główny urząd certyfikacji Avamar, który został zaimportowany przez Avamar w czasie rejestracji klienta (lub edycji albo podłączania 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

Po zweryfikowaniu poprawności certyfikatu uzgadnianie zostanie zakończone, a dane kopii zapasowej zostaną przeniesione z klienta do Data Domain i Avamar w sieci.


Zarządzanie ustawieniami zabezpieczeń sesji

Poniższe dwa artykuły służą do zarządzania ustawieniami zabezpieczeń sesji z poziomu wiersza polecenia lub usługi sieci Web Avinstaller.

000222234 | Avamar: Zarządzanie ustawieniami zabezpieczeń sesji z poziomu wiersza polecenia000222279
| Avamar: Zarządzanie ustawieniami zabezpieczeń sesji za pomocą pakietu instalacyjnego Avinstaller (AVP)
 

Obsługiwane są cztery możliwe konfiguracje:

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

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

Gdy zabezpieczenia sesji są wyłączone, klienty łączą się z usługą Avagent Avamar tylko na porcie 28001, a klienty nasłuchują na porcie Avagent 28002 żądań od Avamar.

Serwer proxy nasłuchuje na 28009.

Port 28001 jest zwykłym gniazdem TCP i nie obsługuje uzgadniania TLS.

Klient łączy się z Avamar GSAN na porcie 29000 i wykonuje jednokierunkowy protokół uzgadniania hosta TLS. Oznacza to, że nawet jeśli zabezpieczenia sesji są wyłączone, dane kopii zapasowej przesyłane między klientem a Avamar są nadal szyfrowane w dystrybucji testowej. 

Certyfikaty do uwierzytelniania za pomocą oprogramowania Avamar nie są wymieniane między Avamar, serwerami proxy, klientami i Data Domain.


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

Tryb Mixed-Single był używany częściej po wprowadzeniu zabezpieczeń sesji w Avamar 7.3 po raz pierwszy, umożliwiając rejestrację i tworzenie kopii zapasowych w systemie Avamar klientom w wersji starszej niż 7.3. W chwili pisania tego artykułu najnowszą wersją jest Avamar 19.10, a tryb Mixed-Single będzie zasadniczo taki sam jak następny tryb do omówienia: Authenticated-Single.


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

W tym trybie zabezpieczenia sesji są włączone, a certyfikaty są przekazywane między Avamar, klientami, serwerami proxy i Data Domain w celu uwierzytelnienia przed utworzeniem kopii zapasowej.

Klienty nasłuchują teraz na porcie 30002 żądań zleceń roboczych Avagent z Avamar, a serwery proxy nasłuchują na porcie 30009. Avamar nasłuchuje na portach 30001 i 30003 żądań połączeń od klientów i serwerów proxy. Są to gniazda SSL, które wykonują protokół uzgadniania hosta TLS.

Tryb Authenticated-Single wymusza na wszystkich klientach zarejestrowanie się przy użyciu metod zabezpieczeń sesji, w przeciwieństwie do trybu Mixed-Single.

Ten tryb wyłącza opcję verifypeer w usłudze GSAN Avamar, co oznacza, że usługa GSAN nie będzie wymagać certyfikatów klienta od przychodzącego połączenia avtar.


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

Tryb Authenticated-Dual jest taki sam jak Authenticated-Single, z tą różnicą, że włącza opcję verifypeer w usłudze GSAN Avamar.

Tryb Authenticated-Dual jest uważany za najsilniejsze ustawienie do zastosowania do serwera Avamar i jest domyślnym wyborem podczas wdrożeń Avamar.


Informacje ogólne: Wewnętrzny główny urząd certyfikacji Avamar z podpisem własnym

Wewnętrzny główny urząd certyfikacji Avamar jest wewnętrznym zaufanym urzędem certyfikacji dla Avamar oraz klientów, serwerów proxy i Data Domain, które Avamar do nich importuje.

Avamar jest wewnętrznym urzędem certyfikacji, ponieważ wystawia certyfikaty dla żądań podpisania certyfikatów (CSR).

Gdy Avamar używa swojego głównego urzędu certyfikacji do podpisywania certyfikatów dla GSAN, są one przechowywane w następującej lokalizacji:
 

/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

Jeśli skaner zabezpieczeń przeskanuje port 29000 w Avamar, zgłosi do GSAN certyfikaty z podpisem własnym na tym porcie, który przetwarza kopie zapasowe.

W niektórych środowiskach może to być niedopuszczalne, dlatego zaleca się zapoznanie się z następującym artykułem bazy wiedzy w celu uzyskania dodatkowych informacji na temat zastępowania wewnętrznego głównego urzędu certyfikacji Avamar wewnętrznym głównym urzędem certyfikacji dostarczonym przez użytkownika.

KB 000204629 | Avamar: Instalacja/wymiana urzędu certyfikacji Avamar na urząd certyfikacji (CA) dostarczony przez użytkownika

Proces ten zawiera szczegółowe informacje na temat korzystania ze skryptu importcert.sh w celu zainstalowania wewnętrznego urzędu certyfikacji firmy dostarczonego przez użytkownika. Urząd certyfikacji dostarczony przez użytkownika prawdopodobnie podlega zarządzaniu przez zespół ds. zabezpieczeń, ponieważ żaden publiczny urząd certyfikacji nie przekaże swojemu urzędowi certyfikacji klucza prywatnego, jako że jest to narzędzie zarabiania pieniędzy przez podpisywanie certyfikatów dla innych i utrzymywanie łańcucha zaufania.

Przykładem wewnętrznego urzędu certyfikacji mogą być Usługi certyfikatów Microsoft Active Directory.
Co to są usługi certyfikatów Active Directory? | Microsoft Learn

Przykładem publicznego urzędu certyfikacji może być DigiCert.

Wymiana wewnętrznego głównego urzędu certyfikacji Avamar polega na zastąpieniu pary kluczy root w magazynie kluczy Avamar parą kluczy urzędu certyfikacji dostarczoną przez użytkownika. Następnie GSAN generuje CSR i klucz prywatny, pobiera CSR podpisany przez nową parę kluczy CA, a pliki wymienione wcześniej w tej sekcji są zastępowane. GSAN ponownie ładuje gniazdo SSL na porcie 29000, a nowe klienty łączący się z GSAN wykrywają urząd certyfikacji dostarczony przez użytkownika.

Skanery zabezpieczeń będą teraz pokazywać podpisane certyfikaty na porcie, a klienty, serwery proxy i Data Domain będą musiały ponownie się zarejestrować, aby uzyskać nowy urząd certyfikacji.


Ograniczenia

Funkcje zabezpieczeń sesji Avamar podlegają pewnym ograniczeniom:

• Klienty
  • Funkcji zabezpieczeń sesji nie można używać z żadnym z następujących klientów Avamar Client:
    • Klient klastra Avamar dla systemu Solaris na serwerze klastrowym Veritas
    • Avamar Client dla systemu Solaris w klastrach Solaris
• Inne produkty
  • Zaleca się korzystanie z synchronizacji czasu NTP serwera Avamar, klientów Avamar Client i systemu Data Domain (w uzasadnionych przypadkach). Jeśli czas nie jest zsynchronizowany, może to spowodować niepowodzenie rejestracji i tworzenia/przywracania kopii zapasowej z powodu czasu ważności i wygaśnięcia certyfikatu. Zmiana strefy czasowej na hoście może mieć podobny wpływ i może wymagać regeneracji certyfikatu.
• Bezpieczny token
  • Uwierzytelnianie zabezpieczonego tokenu nie działa w następujących warunkach:
    • Komputer kliencki znajduje się za urządzeniem zapory sieciowej NAT (Network Address Translation)
    • Nazwa hosta klienta jest nazwą wirtualną, która różni się od nazwy FQDN rozpoznanej na podstawie jego adresu IP
    • Komputer kliencki ma kilka interfejsów IP, a każdy z nich jest rozpoznawany jako inna w pełni kwalifikowana nazwa domeny (FQDN). Aby uzyskać więcej informacji, skorzystaj z poniższych artykułów bazy wiedzy: KB 000056252 | Avamar: Tworzenie kopii zapasowej w Data Domain nie powiodło się z komunikatem „DDR_GET_AUTH_TOKEN” z powodu zbyt wielu adresów IP

Planowanie zmian zabezpieczeń sesji

Przed wykonaniem zmiany ustawień zabezpieczeń sesji można wykonać następujące kroki, aby mieć możliwość przywrócenia poprzedniej konfiguracji lub certyfikatów przed wprowadzeniem jakichkolwiek zmian.

Należy pamiętać, że w przypadku zmiany wewnętrznego głównego urzędu certyfikacji Avamar należy ponownie zarejestrować klientów, serwery proxy i Data Domain. W zależności od rozmiaru środowiska (liczby klientów, serwerów proxy i Data Domain) może to być kłopotliwe zadanie trwające nawet kilka dni.

Przykładem zastosowania jest ponownie generowanie certyfikatów, po którym występują błędy rejestracji i tworzenia kopii zapasowych.

Przy założeniu, że certyfikaty nie wygasły lub są bliskie wygaśnięcia oraz być może są ponownie generowane przez przypadek, poniższe kroki zawierają pewne wskazówki dotyczące sposobu zapobiegania utracie lub niedostępności danych.

Pobierz aktualne ustawienia zabezpieczeń sesji i zanotuj je:

enable_secure_config.sh --showconfig

Wykonanie kopii magazynu kluczy Avamar:

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

Załóżmy, że certyfikaty są teraz ponownie generowane przy użyciu metod AVP zabezpieczeń sesji lub wiersza polecenia.

Oznacza to, że magazyn kluczy Avamar uległ zmianie, a certyfikaty GSAN zostały ponownie podpisane.

Oryginalny magazyn kluczy Avamar można po prostu przenieść z powrotem na miejsce:

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

Ponowne generowanie certyfikatów GSAN:

enable_secure_config.sh --certs

Ponowne uruchomienie MCS i Backup Scheduler:

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

Spowoduje to przywrócenie oryginalnego wewnętrznego głównego urzędu certyfikacji Avamar, któremu ufały już klienty, serwery proxy i Data Domain.


Rozwiązywanie problemów

W większości przypadków zmiana ustawień zabezpieczeń sesji lub ponowne wygenerowanie certyfikatów jest proste.

W tej sekcji omówiono sposób przywrócenia działania wszystkich elementów po ponownym wygenerowaniu certyfikatów lub zmianie ustawień.

Miejscowe opróżnianie

W scenariuszu, w którym funkcja verifypeer jest włączona, po ponownym wygenerowaniu wszystkich certyfikatów Avamar certyfikaty klienta używane przez avtar i avmgr serwera Avamar nie są natychmiast aktualizowane.

Oznacza to, że po uruchomieniu zaplanowanego opróżnienia MCS (kopia zapasowa konfiguracji MCS w GSAN) zakończy się niepowodzeniem z powodu niepowodzenia uzgadniania TLS. Wynika to z faktu, że certyfikaty klienta dla avtar uruchomionego na serwerze Avamar nie otrzymały jeszcze zaktualizowanego wewnętrznego głównego urzędu certyfikacji Avamar i nowego zestawu podpisanych certyfikatów klienta.

Więcej informacji można znaleźć w następującym artykule bazy wiedzy:

000214340 | Avamar: Avtar nie może połączyć się z usługą GSAN Avamar, „Fatal server connection problem, aborting initialization. Verify correct server address and login credentials”.

Replikacja

W scenariuszu, w którym funkcja verifypeer jest włączona w miejscu docelowym replikacji oraz certyfikaty są ponownie generowane w miejscu docelowym, należy zastosować podejście podobne do opisanego w powyższej sekcji „Miejscowe opróżnianie”.

Najpierw upewnij się, że docelowy Avagent replikacji jest zarejestrowany, aby mógł akceptować zlecenia robocze replikacji.

W miejscu docelowym sprawdź dziennik Avagent w następującej lokalizacji:

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

Prawidłowy dziennik może wyglądać następująco:

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

W dalszej starszej części dziennika może istnieć niedawna pomyślna ponowna rejestracja:

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

Niepoprawny dzienni zawierający problemy z rejestracją spowodowane zmianami certyfikatów może wyglądać następująco:

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.

W takim przypadku, aby wymusić natychmiastową ponowną rejestrację Avagent w MCS, należy wykonać następujące czynności:

Pobierz nazwę konta MC_SYSTEM, która prawdopodobnie będzie nazwą FQDN 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

Dezaktywuj konto MC_SYSTEM:

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

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

Ponownie zarejestruj konto MC_SYSTEM:

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

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

Po pomyślnym zakończeniu rejestracji Avagent może zaakceptować replikację w miejscu docelowym.

Teraz w źródle Avamar, jeśli funkcja verifypeer jest włączona w docelowym miejscu replikacji Avamar, musimy ponownie wygenerować certyfikaty klienta używane do łączenia się z docelowym systemem Avamar.

Podobnie jak w artykule bazy wiedzy KB 000214340 | Avamar: Avtar nie może połączyć się z usługą GSAN Avamar, „Fatal server connection problem, aborting initialization. Verify correct server address and login credentials”. 

Usuń istniejący docelowy folder certyfikatów Avamar ze źródłowej sesji ssh Avamar:

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

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

Wygeneruj ponownie certyfikaty klienta:

/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

Komunikację z docelowym Avamar można przetestować za pomocą wiersza polecenia ssh Source Avamar:

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

Rejestracja klienta

Próba utworzenia kopii zapasowej może zostać podjęta po zmianie ustawień zabezpieczeń sesji lub ponownym wygenerowaniu certyfikatów.

Może to prowadzić do znalezienia wielu klientów opartych na agentach w stanie „Waiting-Client”, dopóki nie uda się utworzyć kopii zapasowej za pomocą „Timed-Out Start”.

Po ponownym wygenerowaniu nowych certyfikatów automatyczna próba ponownej rejestracji klienta powinna potrwać około 23 godzin.

Następujące polecenie może zostać użyte na serwerze Avamar w celu wysłania zaproszenia do klientów opartych na agentach w celu ponownej rejestracji w Avamar MCS.

mccli client re-register-all

Polecenie może trochę potrwać w zależności od liczby klientów, ponieważ wysyła zaproszenie do każdego z nich w kolejności sekwencyjnej. Rozważ uruchomienie polecenia w tle na wypadek, gdyby upłynął limit czasu sesji ssh.

nohup mccli client re-register-all &

Należy pamiętać, że może to nie zadziałać w przypadku ponownego zarejestrowania wszystkich klientów opartych na agentach, a niektóre z nich mogą wymagać ponownej ręcznej rejestracji.

Ręczny proces ponownej rejestracji klienta w systemie Windows wygląda następująco:

• Usuń zawartość następującego katalogu zawierającego stare certyfikaty klienta:

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

• Uruchom ponownie usługę „Backup Agent”

Ręczny proces ponownej rejestracji klienta w systemie Linux wygląda następująco:

• Usuń zawartość następującego katalogu zawierającego stare certyfikaty klienta:

  • /usr/local/avamar/etc

• Uruchom ponownie usługę Avagent:

  • service avagent restart

Można również ponownie uruchomić komputer kliencki, aby spróbować wyzwolić pełną ponowną rejestrację.

Należy pamiętać, że rozpoznawanie nazw odgrywa ważną rolę w rejestrowaniu klientów, gdy włączone są zabezpieczenia sesji, upewnij się, że klienty mogą wykonywać dwukierunkowe wyszukiwanie DNS serwera Avamar i odwrotnie. Można to zrobić poprzez skonfigurowanie rekordów A DNS lub wpisów hostów na kliencie.

Avamar nie udostępnia żadnego skryptu, który mógłby skontaktować się z każdym podłączonym klientem w celu przeprowadzenia ręcznej ponownej rejestracji. Wspomniane wcześniej polecenie mccli jest tego najbliższe.

Rejestracja serwera proxy

Maszyny wirtualne, których kopie zapasowe są tworzone w systemie Avamar przy użyciu serwerów proxy, mają pewną przewagę, jeśli chodzi o zmiany zabezpieczeń po sesji, ponieważ zwykle jest ich znacznie mniej niż klientów opartych na agentach.

Serwery proxy powinny również podjąć próbę automatycznej ponownej rejestracji w ciągu 23 godzin, ale ich natychmiastowa ponowna rejestracja może być łatwiejsza i szybsza.

Dostępnych jest kilka opcji wymuszenia ponownej rejestracji na serwerach proxy.

Pierwszą opcją może być ponowne uruchomienie serwerów proxy za pomocą następującego polecenia:

mccli mcs reboot-proxy --all

Drugą opcją może być użycie narzędzia Goav do zarządzania serwerami proxy.

Ustaw hasło serwera proxy dla narzędzia Goav, aby mogło logować się do serwerów proxy, kiedy tylko zajdzie taka potrzeba. Poniższe polecenie nie powoduje zmiany hasła systemu operacyjnego serwera proxy, a po prostu przechowuje zaszyfrowane hasło, dzięki czemu narzędzie Goav może go używać do logowania się do serwera proxy, gdy tylko zajdzie taka potrzeba przez ssh.

./goav proxy set-password

Uruchom ponownie Avagent na wszystkich podłączonych serwerach proxy:

./goav proxy exec "service avagent restart"

Aby sprawdzić w dzienniku Avagent na serwerze proxy, czy ponowna rejestracja przebiegła pomyślnie, uruchom następujące polecenie:

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

Pomyślny wynik może wyglądać następująco:

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

Trzecią opcją jest połączenie się z serwerem proxy przez ssh i uruchomienie skryptu inicjalizacji:

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

Synchronizacja Data Domain

Po zmianie ustawień zabezpieczeń sesji lub ponownym wygenerowaniu certyfikatów w systemie Avamar, system Data Domain będzie musiał zostać ponownie zsynchronizowany lub będzie musiało zostać ponownie ustanowione połączenie SSL.

Poniższy artykuł bazy wiedzy opisuje ten scenariusz i sposób wymiany nowych certyfikatów z Data Domain.

000197106 | Integracja Avamar i Data Domain: DD wyświetla się na czerwono w Avamar AUI i/lub w ścieżce rozwiązania interfejsu użytkownika

Zdecydowanie zaleca się rozwiązywanie problemów z Avamar i Data Domain SSL za pomocą narzędzia Goav.

Za pomocą narzędzia Goav można automatycznie zdiagnozować i rozwiązać problemy z połączeniem SSL Data Domain z Avamar. Więcej informacji można znaleźć w następującym artykule bazy wiedzy:

000215679 | Avamar: Informacje o funkcji Goav dd check-ssl

Uruchom następujące polecenie, aby automatycznie naprawić certyfikaty Avamar i Data Domain:

./goav dd check-ssl --fix