Avamar: Sitzungssicherheit
Summary: In diesem Artikel wird die Sitzungssicherheit in Avamar beschrieben und erläutert, wie sie funktioniert und verwaltet wird.
Instructions
Sitzungssicherheit: Produktsicherheitshandbuch
Avamar Clients können Sitzungssicherheit verwenden, um die gesamte Kommunikation zwischen dem Avamar Server und der Avamar Client-Software zu sichern. Der Avamar Server authentifiziert sich beim Avamar Client und der Avamar Client authentifiziert sich beim Avamar Server.
Die Sitzungssicherheitsfunktionen umfassen Sicherheitsverbesserungen für die Kommunikation zwischen Avamar-Systemprozessen.
Avamar sichert die gesamte Kommunikation zwischen Avamar-Systemprozessen mithilfe von Sitzungstickets. Bevor ein Avamar-Prozess eine Übertragung von einem anderen Avamar-Prozess akzeptiert, ist ein gültiges Sitzungsticket erforderlich.
Die Sitzungstickets weisen die folgenden allgemeinen Merkmale auf:
- Das Sitzungsticket ist verschlüsselt und signiert, um es vor Änderungen zu schützen.
- Das Sitzungsticket ist nur für kurze Zeit gültig.
- Jedes Sitzungsticket enthält eine eindeutige Signatur und ist nur einem Avamar-Prozess zugewiesen.
- Die Integrität eines Sitzungstickets wird durch Verschlüsselung geschützt.
- Die Signatur des Sitzungstickets wird von jedem Avamar-System-Node separat überprüft.
- Bei Bedarf kann eine Sitzung über die Lebensdauer des Sitzungstickets hinaus verlängert werden.
Das Avamar-System installiert den öffentlichen Schlüssel für das Serverzertifikat auf jedem Avamar Client, der beim Avamar Server registriert ist. Avamar Clients authentifizieren Übertragungen vom Avamar-System mithilfe des öffentlichen Schlüssels.
Bei Clients, die derzeit registriert sind, werden der öffentliche Schlüssel für das Serverzertifikat und andere erforderliche Zertifikatdateien innerhalb einer Stunde nach der Installation an den Client übertragen.
Das Avamar-System teilt das Avamar Server-Zertifikat auch automatisch mit den Avamar Storage Nodes. Durch das Teilen des Zertifikats können der Utility-Node und die Storage Nodes dasselbe Zertifikat für die Authentifizierung bereitstellen.
Wenn der Avamar Server einen Avamar Client registriert, wird ein Client-Zertifikat erzeugt.
Nach dem Erzeugen eines Client-Zertifikats verwendet das Avamar-System eine verschlüsselte Verbindung zum Avamar Client, um das Zertifikat auf dem Client zu installieren. Das Avamar-System speichert außerdem den öffentlichen Schlüssel für das Client-Zertifikat. Der öffentliche Schlüssel wird verwendet, um den Client für jede nachfolgende Kommunikation zu authentifizieren.
Wie funktioniert die Sitzungssicherheit?
Die Sitzungssicherheit wird auf dem Avamar Server aktiviert. Wenn die Option aktiviert ist, durchlaufen die Clients, Proxys und Data Domain-Systeme einen speziellen Zertifikatregistrierungsprozess mit Avamar.
Ein Windows- oder Linux-Client und -Proxy sieht bei der Registrierung, dass auf dem Avamar Server Sitzungssicherheit aktiviert ist. Der Avamar Server sendet seine interne Stammzertifizierungsstelle (chain.pem) an den Client, damit der Client sie speichern und als vertrauenswürdig einstufen kann. Der Client erzeugt eine Zertifikatsignieranfrage (Certificate Signing Request, CSR). Die CSR (avclient.csr) wird vom Client an den MCS-Prozess des Avamar Servers gesendet, der die CSR signiert und ein Zertifikat-Schlüsselpaar (key.pem und cert.pem) an den Client zurückgibt.
Wenn ein Data Domain-System mit Avamar verbunden oder die SSL-Kommunikation aktualisiert wird, sieht Avamar, dass die Data Domain kein selbst oder von einem anderen validierten Avamar-System (imported-host ddboost) signiertes Zertifikat besitzt. Avamar verwendet den privaten SSH-Schlüssel der Data Domain, um sich bei der Data Domain anzumelden und SSH-Befehle über die Data Domain-Shell (ddsh) auszuführen. Avamar ruft die Data Domain-Zertifikatsignieranfrage (CSR) über SCP ab und signiert die CSR mit der internen Stammzertifizierungsstelle von Avamar. Sobald Data Domain das signierte Zertifikat von Avamar (imported-host ddboost) erhalten hat, importiert Avamar die Stammzertifizierungsstelle, die das Zertifikat (chain.pem als imported-ca ddboost/login-auth) signiert hat.
Nachdem nun ein Client/Proxy registriert wurde und über die Client-seitigen Zertifikate verfügt, die für die Authentifizierung beim MCS von Avamar erforderlich sind, wird ein Backupversuch unternommen. Avamar sendet einen Arbeitsauftrag an den Avagent-Listener des Clients oder Proxys, der den Arbeitsauftrag annimmt. Der Client oder Proxy validiert und verifiziert nun die Zertifikatkette des Avamar Servers mithilfe der Avamar-Stammzertifizierungsstelle, die Avamar bei der Registrierung in den Client importiert hat. Ebenso authentifiziert Avamar den Client oder Proxy. Zu diesem Zeitpunkt wurden noch keine Daten übertragen.
Nach der erfolgreichen Authentifizierung wird der Arbeitsauftrag gestartet und der Status des Arbeitsauftrags ändert sich von „Waiting-Client“ zu „Running“.
Die Clients und Proxys übertragen jetzt Daten an Avamar und die Data Domain unter Verwendung der auf ihnen installierten avtar-Binärdatei. Die avtar-Binärdatei überträgt einige Markierungen, die steuern, wie die Daten und welche Daten verschoben werden.
Wenn avtar auf einem Client oder Proxy eine Verbindung zum GSAN von Avamar herstellt, muss es wissen, ob verifypeer aktiviert ist. Die verifypeer-Einstellung ist eine Einstellung des GSAN-Servers und Teil der Sitzungssicherheitskonfiguration, die den SSL-Sockel von GSAN auf Port 29000 steuert, indem sie ihm mitteilt, ob für jede eingehende Verbindung Client-Zertifikate erforderlich sind oder nicht. Glücklicherweise wurde das TLS-1.2-Protokoll implementiert, das automatisch steuert, wie ein Client oder Proxy seine Client-Zertifikate während des TLS-Handshakes an GSAN übertragen soll.
Im Folgenden finden Sie eine Demonstration des gegenseitigen/bidirektionalen TLS-Handshakes, wenn verifypeer aktiviert ist.
Aus Sicht des Clients oder Proxys zeigt ein Pfeil nach rechts eine Verbindung zum Avamar Server an. Ein Pfeil nach links zeigt eine Verbindung vom Avamar Server zum Client an.
[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
Wenn verifypeer deaktiviert ist, muss der Client kein Client-Zertifikat an GSAN senden.
[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
Wichtig ist, dass der Client oder Proxy die erforderlichen Client-seitigen Zertifikate erhalten hat, um einen gegenseitigen TLS-Handshake durchführen zu können, wenn dies von GSAN verlangt wird.
Das heißt, wenn sich die interne Avamar-Stammzertifizierungsstelle ändert, müssen die Clients, Proxys oder Data Domains die neue Stammzertifizierungsstelle erhalten, um ihre Zertifikate zu signieren.
Nachdem der Client oder Proxy erfolgreich eine Verbindung zum GSAN hergestellt hat, versucht er, eine Verbindung zur Data Domain herzustellen.
Das folgende Protokoll zeigt einen Proxy, der über avtar eine Verbindung zur Data Domain herstellt. Die verifypeer-Einstellung ist deaktiviert, aber die Sitzungssicherheit ist aktiviert (Authenticated-Single-Modus).
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
Da verifypeer eine Einstellung des Avamar-GSAN-Servers ist, hat sie keinen Einfluss darauf, wie avtar eine direkte Verbindung zur Data Domain herstellt, wenn Sitzungssicherheit aktiviert ist. Das bedeutet, dass ein gegenseitiger TLS-Handshake zwischen dem Client oder Proxy und der Data Domain stattfindet.
Der Client oder Proxy kann die Data Domain-Zertifikatkette validieren, da sie dieselbe interne Avamar-Stammzertifizierungsstelle verwendet, die von Avamar zum Zeitpunkt der Client-Registrierung (oder Zeitpunkt der Bearbeitung oder des Anschlusses der DD) importiert wurde.
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
Nach der Zertifikatvalidierung wird der Handshake abgeschlossen und die Backupdaten werden im Netzwerk vom Client zur Data Domain und zu Avamar verschoben.
Verwalten der Sitzungssicherheitseinstellungen
Die folgenden beiden Artikel enthalten Informationen dazu, wie die Einstellungen für die Sitzungssicherheit entweder über die Befehlszeile oder den Avinstaller-Webservice verwaltet werden.
000222234 | Avamar: Verwalten der Sitzungssicherheitseinstellungen über die Befehlszeilenschnittstelle
000222279 | Avamar: Verwalten der Sitzungssicherheitseinstellungen mit dem Avinstaller-Installationspaket (AVP)
Es gibt vier mögliche unterstützte Konfigurationen:
- Deaktiviert
- Mixed-Single
- Authenticated-Single
- Authenticated-Dual
Deaktiviert
Einstellungen:
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"
Wenn die Sitzungssicherheit deaktiviert ist, stellen Clients ausschließlich auf Port 28001 eine Verbindung zum Avagent-Service von Avamar her und die Clients überwachen den Avagent-Port 28002 auf Anfragen von Avamar.
Ein Proxy überwacht den Port 28009.
Port 28001 ist ein einfacher TCP-Sockel, der keine TLS-Handshakes durchführt.
Der Client stellt eine Verbindung zum Avamar-GSAN auf Port 29000 her und führt einen unidirektionalen TLS-Handshake durch. Das bedeutet, dass selbst bei deaktivierter Sitzungssicherheit Backupdaten bei der Übertragung zwischen dem Client und Avamar weiterhin In-Flight verschlüsselt werden.
Es werden keine Zertifikate für die Authentifizierung bei der Avamar-Software zwischen Avamar, Proxys, Clients und Data Domain ausgetauscht.
Mixed-Single
Einstellungen:
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"
Der Mixed-Single-Modus wurde bei der Einführung der Sitzungssicherheit in Avamar 7.3 häufiger verwendet, sodass insbesondere Clients, deren Version nicht 7.3 oder höher war, sich bei Avamar registrieren und Backups auf Avamar durchführen konnten. Zum Zeitpunkt der Erstellung dieses Artikels ist Avamar 19.10 die aktuelle Version und Mixed-Single ist im Wesentlichen identisch mit dem als nächstes vorgestellten Modus: Authenticated-Single.
Authenticated-Single
Einstellungen:
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"
In diesem Modus ist die Sitzungssicherheit aktiviert und die Zertifikate werden zur Authentifizierung vor einem Backup zwischen Avamar, den Clients, Proxys und Data Domains übertragen.
Clients überwachen jetzt Port 30002 auf Avagent-Arbeitsauftragsanfragen von Avamar, während Proxys Port 30009 überwachen. Avamar überwacht die Ports 30001 und 30003 auf Verbindungsanfragen von Clients und Proxys. Hierbei handelt es sich um SSL-Sockel, die TLS-Handshakes durchführen.
Im Gegensatz zum Mixed-Single-Modus zwingt der Authenticated-Single-Modus alle Clients dazu, sich unter Verwendung von Sitzungssicherheitsmethoden zu registrieren.
In diesem Modus wird verifypeer im Avamar-GSAN deaktiviert, was bedeutet, dass GSAN keine Client-Zertifikate von einer eingehenden avtar-Verbindung benötigt.
Authenticated-Dual
Einstellungen:
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 ist identisch mit Authenticated-Single, außer dass die verifypeer-Einstellung für den GSAN-Service von Avamar aktiviert wird.
Authenticated-Dual gilt als stärkste Einstellung, die auf einen Avamar Server angewendet werden kann, und ist die Standardauswahl bei Avamar-Bereitstellungen.
Übersicht: Interne selbstsignierte Avamar-Stammzertifizierungsstelle
Die interne Stammzertifizierungsstelle von Avamar ist eine intern vertrauenswürdige Zertifizierungsstelle für Avamar und die Clients und Proxys sowie Data Domains, die Avamar in diese importiert.
Avamar ist die interne Zertifizierungsstelle für sich selbst, da es Zertifikate für Zertifikatsignieranfragen (CSRs) ausstellt.
Wenn Avamar seine Stammzertifizierungsstelle verwendet, um Zertifikate für GSAN zu signieren, werden diese am folgenden Speicherort gespeichert:
/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
Wenn ein Sicherheitsscanner Port 29000 auf Avamar überprüft, meldet er selbstsignierte Zertifikate auf diesem Port, der die Backups an das GSAN verarbeitet.
In einigen Umgebungen ist dies möglicherweise nicht akzeptabel. Lesen Sie in diesem Fall den folgenden Wissensdatenbank-Artikel, um weitere Informationen zum Ersetzen der internen Avamar-Stammzertifizierungsstelle durch eine vom Nutzer bereitgestellte interne Stammzertifizierungsstelle zu erhalten.
KB 000204629 | Avamar: Installieren/Ersetzen der Avamar-Zertifizierungsstelle (CA) durch eine vom Nutzer bereitgestellte Zertifizierungsstelle (CA)
Es wird erläutert, wie das importcert.sh-Skript verwendet wird, um eine vom Nutzer bereitgestellte unternehmensinterne Zertifizierungsstelle zu installieren. Die vom Nutzer bereitgestellte Zertifizierungsstelle wird höchstwahrscheinlich vom Sicherheitsteam verwaltet, da keine öffentliche Zertifizierungsstelle ihren privaten Schlüssel herausgibt. Schließlich verdienen sie ihr Geld damit, Zertifikate für andere zu signieren und eine Vertrauenskette aufrechtzuerhalten.
Ein Beispiel für eine interne Zertifizierungsstelle sind die Microsoft Active Directory-Zertifikatdienste.
Was sind die Active Directory-Zertifikatdienste? | Microsoft Learn
Ein Beispiel für eine öffentliche Zertifizierungsstelle ist DigiCert.
Um die interne Avamar-Stammzertifizierungsstelle zu ersetzen, muss das Schlüsselpaar der Stammzertifizierungsstelle im Avamar Keystore durch das Schlüsselpaar der vom Nutzer bereitgestellten Zertifizierungsstelle ersetzt werden. Dann erzeugt GSAN eine CSR und einen privaten Schlüssel, lässt die CSR vom Schlüsselpaar der neuen Zertifizierungsstelle signieren und anschließend werden die zuvor in diesem Abschnitt erwähnten Dateien ersetzt. GSAN lädt den SSL-Sockel erneut auf Port 29000 und neue Clients, die eine Verbindung zum GSAN herstellen, sehen die vom Nutzer bereitgestellte Zertifizierungsstelle.
Sicherheitsscanner zeigen nun signierte Zertifikate auf dem Port an und Clients, Proxys und Data Domains müssen sich erneut registrieren, um die neue Zertifizierungsstelle zu erhalten.
Einschränkungen
Die Sicherheitsfunktionen für Avamar-Sitzungen unterliegen jedoch einigen Einschränkungen:
- Clients
- Die Sitzungssicherheitsfunktionen können mit den folgenden Avamar Clients nicht verwendet werden:
- Avamar Clusterclient für Solaris auf Veritas Cluster Server
- Avamar Client für Solaris in Solaris-Clustern
- Die Sitzungssicherheitsfunktionen können mit den folgenden Avamar Clients nicht verwendet werden:
- Andere Produkte
- Es wird empfohlen, auf dem Avamar Server, den Avamar Clients und dem Data Domain-System (falls zutreffend) die NTP-Zeitsynchronisierung zu verwenden. Wenn die Zeit nicht synchronisiert ist, kann dies aufgrund der Gültigkeitsdauer und der Ablaufzeiten von Zertifikaten zu Registrierungs- und Backup-/Wiederherstellungsfehlern führen. Das Ändern der Zeitzone auf einem Host kann ähnliche Auswirkungen haben und möglicherweise eine Neuerzeugung des Zertifikats erfordern.
- Sicherheitstoken
- Die Authentifizierung mittels Sicherheitstoken funktioniert unter den folgenden Bedingungen nicht:
- Der Client-Computer befindet sich hinter einem NAT-Firewallgerät (Network Address Translation)
- Der Hostname des Clients ist ein virtueller Name, der sich vom FQDN unterscheidet, der von seiner IP-Adresse aufgelöst wird.
- Der Client-Computer verfügt über mehrere IP-Schnittstellen und jede wird in einen anderen vollständig qualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) aufgelöst. Weitere Informationen finden Sie im folgenden Wissensdatenbank-Artikel: KB 000056252 | Avamar: Backup auf Data Domain aufgrund zu vieler IP-Adressen mit der Meldung „DDR_GET_AUTH_TOKEN“ fehlgeschlagen
- Die Authentifizierung mittels Sicherheitstoken funktioniert unter den folgenden Bedingungen nicht:
Geplante Änderungen an der SitzungssicherheitBevor Sie eine Änderung an den Sitzungssicherheitseinstellungen vornehmen, können Sie die folgenden Schritte ausführen, um die vorherige Konfiguration oder die vorherigen Zertifikate wiederherzustellen, bevor Sie Änderungen vornehmen.
Denken Sie daran, dass Clients, Proxys und Data Domains neu registriert werden müssen, wenn die interne Stammzertifizierungsstelle von Avamar geändert wird. Je nach Größe der Umgebung (Anzahl der Clients, Proxys und Data Domains) kann dies eine langwierige Aufgabe sein, die sich über mehrere Tage erstreckt.
Der Anwendungsfall würde sich ergeben, wenn Zertifikate neu erzeugt werden und dann Registrierungs- und Backupfehler auftreten.
Unter der Annahme, dass die Zertifikate noch nicht abgelaufen sind bzw. in Kürze ablaufen und möglicherweise versehentlich neu erzeugt werden, bieten die folgenden Schritte Unterstützung, um Datenverluste oder eine Nichtverfügbarkeit von Daten zu vermeiden.
Rufen Sie die aktuellen Sitzungssicherheitseinstellungen ab und notieren Sie sie:
enable_secure_config.sh --showconfig
Erstellen Sie eine Kopie des Avamar Keystores:
cp -p /usr/local/avamar/lib/avamar_keystore /usr/local/avamar/lib/x-avamar_keystore-original
Angenommen, die Zertifikate wurden jetzt neu erzeugt, entweder über das Sitzungssicherheits-AVP oder die CLI.
Dadurch wurde der Avamar Keystore geändert und die GSAN-Zertifikate wurden neu signiert.
Der ursprüngliche Avamar Keystore kann nun einfach wieder an seinen Speicherort verschoben werden:
cp -p /usr/local/avamar/lib/x-avamar_keystore-original /usr/local/avamar/lib/avamar_keystore
Erzeugen Sie die GSAN-Zertifikate neu:
enable_secure_config.sh --certs
Starten Sie MCS und den Backup Scheduler neu:
mcserver.sh --restart --force dpnctl start sched
Dadurch wird die ursprüngliche interne Avamar-Stammzertifizierungsstelle wiederhergestellt, der Clients, Proxys und Data Domains bereits vertraut haben.
Troubleshooting
In den meisten Fällen gestaltet sich das Ändern der Sitzungssicherheitseinstellungen oder das erneute Erzeugen der Zertifikate unkompliziert.
In diesem Abschnitt wird erläutert, wie alles wieder funktioniert, nachdem Zertifikate neu erzeugt oder Einstellungen geändert wurden.
Lokale Entleerungen
Wenn verifypeer aktiviert ist und alle Avamar-Zertifikate neu erstellt werden, werden die Client-Zertifikate, die von den avtar- und avmgr-Prozessen des Avamar Servers verwendet werden, nicht sofort aktualisiert.
Das heißt, wenn MCS eine geplante Entleerung (Backup der MCS-Konfiguration auf GSAN) ausführt, schlägt diese aufgrund eines TLS-Handshake-Fehlers fehl. Das liegt daran, dass die Client-Zertifikate für avtar, das auf dem Avamar Server ausgeführt wird, noch nicht die aktualisierte interne Avamar-Stammzertifizierungsstelle und den neuen Satz signierter Client-Zertifikate erhalten haben.
Weitere Informationen finden Sie im folgenden Wissensdatenbank-Artikel:
000214340 | Avamar: Avtar kann keine Verbindung zum GSAN-Service von Avamar herstellen, „Fatal server connection problem, aborting initialization. Verify correct server address and login credentials.“
Replikation
Wenn verifypeer auf dem Replikationsziel aktiviert ist und die Zertifikate auf dem Ziel neu erzeugt werden, gilt eine ähnliche Vorgehensweise wie im obigen Abschnitt „Lokale Entleerungen“.
Stellen Sie zunächst sicher, dass der Avagent des Replikationsziels registriert ist, damit er Replikationsarbeitsaufträge annehmen kann.
Überprüfen Sie auf dem Ziel das Avagent-Protokoll an folgendem Speicherort:
/usr/local/avamar/var/client/avagent.log
Ein fehlerfreies Protokoll könnte wie folgt aussehen:
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
Wenn Sie das Protokoll weiter durchgehen, finden Sie möglicherweise eine kürzlich durchgeführte erfolgreiche Neuregistrierung:
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
Ein fehlerhaftes Protokoll mit Registrierungsproblemen, die durch Zertifikatsänderungen verursacht wurden, könnte wie folgt aussehen:
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.
In diesem Fall müssen die folgenden Schritte ausgeführt werden, um eine sofortige erneute Registrierung des Avagent bei MCS zu erzwingen:
Rufen Sie den MC_SYSTEM-Kontonamen ab, der wahrscheinlich dem Avamar-FQDN entspricht:
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
Deaktivieren Sie das MC_SYSTEM-Konto:
mccli client edit --name=/MC_SYSTEM/<avamar_fqdn> --activated=false example: mccli client edit --name=/MC_SYSTEM/avamar.lab --activated=false
Registrieren Sie das MC_SYSTEM-Konto neu:
/etc/init.d/avagent register <avamar_fqdn> /MC_SYSTEM example: /etc/init.d/avagent register avamar.lab /MC_SYSTEM
Nach der erfolgreichen Registrierung kann Avagent die Replikation auf dem Ziel akzeptieren.
Wenn verifypeer auf dem Avamar-Replikationsziel aktiviert ist, müssen auf dem Avamar-Quellsystem die Client-Zertifikate neu erzeugt werden, die für die Verbindung mit dem Avamar-Zielsystem verwendet werden.
Ähnlich wie im Wissensdatenbank-Artikel 000214340 | Avamar: Avtar kann keine Verbindung zum GSAN-Service von Avamar herstellen, „Fatal server connection problem, aborting initialization. Verify correct server address and login credentials.“
Entfernen Sie den vorhandenen Zertifikatordner des Avamar-Zielsystems aus der SSH-Sitzung des Avamar-Quellsystems:
rm -r /usr/local/avamar/etc/<destination_avamar_ip_address> rm -r /usr/local/avamar/etc/client/<destination_avamar_ip_address>
Erzeugen Sie die Client-Zertifikate neu:
/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
Die Kommunikation mit dem Avamar-Zielsystem kann über die SSH-Befehlszeile des Avamar-Quellsystems getestet werden:
avmgr logn --id=repluser --ap=<destination_repluser_password> --hfsaddr=<destination_avamar_ip_address> --debug --x19=1024 --x30=8192
Client-Registrierung
Nach dem Ändern der Sitzungssicherheitseinstellungen oder dem erneuten Erzeugen der Zertifikate kann es zu Backupversuchen kommen.
Dies kann dazu führen, dass sich viele Agent-basierte Clients im Status „Waiting-Client“ befinden, bis das Backup mit der Meldung „Timed-Out Start“ fehlschlägt.
Nachdem die neuen Zertifikate erzeugt wurden, dauert es ca. 23 Stunden, bis der Client automatisch eine erneute Registrierung versucht.
Der folgende Befehl kann auf dem Avamar Server verwendet werden, um eine Einladung an Agent-basierte Clients zur erneuten Registrierung beim Avamar MCS zu senden.
mccli client re-register-all
Der Befehl kann je nach Anzahl der Clients einige Zeit in Anspruch nehmen, da er die Einladungen nacheinander an jeden Client sendet. Führen Sie den Befehl im Hintergrund aus, falls es zu einem Timeout der SSH-Sitzung kommt.
nohup mccli client re-register-all &
Beachten Sie, dass dadurch möglicherweise nicht alle Agent-basierten Clients erneut registriert werden, und dass einige möglicherweise manuell neu registriert werden müssen.
Der manuelle Prozess für die erneute Registrierung eines Clients unter Windows sieht wie folgt aus:
- Entfernen Sie den Inhalt des folgenden Verzeichnisses, das die alten Client-Zertifikate enthält:
-
"C:\Program Files\avs\etc"
-
- Starten Sie den „Backup Agent“-Service neu.
- Entfernen Sie den Inhalt des folgenden Verzeichnisses, das die alten Client-Zertifikate enthält:
-
/usr/local/avamar/etc
-
- Starten Sie den Avagent-Service neu:
-
service avagent restart
-
Der Client-Computer kann auch neu gestartet werden, um eine vollständige Neuregistrierung auszulösen.
Beachten Sie, dass die Namensauflösung eine wichtige Rolle bei der Registrierung von Clients spielt, wenn Sitzungssicherheit aktiviert ist. Stellen Sie daher sicher, dass die Clients eine Vorwärts- und Rückwärts-DNS-Suche des Avamar Servers durchführen können und umgekehrt. Dies kann entweder durch die Konfiguration von DNS-A-Datensätzen oder Hosteinträgen auf dem Client erreicht werden.
Avamar bietet keinerlei Skript, mit dem jeder verbundene Client erreicht werden kann, um eine manuelle Neuregistrierung durchzuführen. Der zuvor erwähnte mccli-Befehl erreicht dies noch am ehesten.
Proxy-Registrierung
Virtuelle Maschinen, die mithilfe von Proxys in Avamar gesichert werden, haben einen gewissen Vorteil, was Sicherheitsänderungen nach der Sitzung betrifft, da es in der Regel deutlich weniger Proxys als Agent-basierte Clients gibt.
Proxys sollten ebenfalls versuchen, innerhalb von 23 Stunden eine automatische Neuregistrierung durchzuführen. Es kann jedoch einfacher und schneller sein, sie sofort neu zu registrieren.
Es stehen einige Optionen zur Verfügung, um auf den Proxys eine erneute Registrierung zu erzwingen.
Die erste Option besteht darin, die Proxys mit dem folgenden Befehl neu zu starten:
mccli mcs reboot-proxy --all
Die zweite Option besteht darin, die Proxys mit dem Goav-Tool zu verwalten.
Legen Sie das Proxykennwort für das Goav-Tool fest, damit es sich bei den Proxys anmelden kann, wann immer nötig. Mit dem folgenden Befehl wird das Betriebssystemkennwort des Proxys nicht geändert, sondern lediglich verschlüsselt gespeichert, sodass das Goav-Tool es verwenden kann, um sich beim Proxy über SSH anzumelden.
./goav proxy set-password
Führen Sie auf allen verbundenen Proxys einen Avagent-Neustart durch:
./goav proxy exec "service avagent restart"
Führen Sie den folgenden Befehl aus, um das Avagent-Protokoll im Proxy daraufhin zu überprüfen, ob eine erfolgreiche erneute Registrierung stattgefunden hat:
./goav proxy exec "grep -i registration /usr/local/avamarclient/var/avagent.log"
Eine erfolgreiche Ausgabe könnte wie folgt aussehen:
============== 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.
Die dritte Option besteht darin, eine SSH-Verbindung zum Proxy herzustellen und das Initialisierungsskript auszuführen:
/usr/local/avamarclient/etc/initproxyappliance.sh start
Data Domain-Synchronisierung
Nachdem die Einstellungen für die Sitzungssicherheit geändert oder die Zertifikate auf Avamar neu erzeugt wurden, muss die Data Domain neu synchronisiert oder die SSL-Verbindung wiederhergestellt werden.
Der folgende Wissensdatenbank-Artikel behandelt dieses Szenario und wie Sie die neuen Zertifikate an die Data Domain übertragen.
000197106 | Avamar- und Data Domain-Integration: DD wird in Avamar AUI und/oder Benutzeroberfläche rot angezeigt – Lösungspfad
Es wird dringend empfohlen, das Avamar- und Data Domain-SSL-Troubleshooting mit dem Goav-Tool durchzuführen.
Mit Goav kann die Data Domain-SSL-Verbindung mit Avamar automatisch diagnostiziert und aufgelöst werden. Weitere Informationen finden Sie im folgenden Wissensdatenbank-Artikel:
000215679 | Avamar: Informationen zur Goav-dd-check-ssl-Funktion
Führen Sie den folgenden Befehl aus, um Avamar- und Data Domain-Zertifikate automatisch zu korrigieren:
./goav dd check-ssl --fix