Avamar: Oturum Güvenliği
Summary: Bu makalede Avamar'da Oturum Güvenliğinin ne olduğu, nasıl çalıştığı ve nasıl yönetileceği açıklanmıştır.
Instructions
Oturum Güvenliği: Ürün Güvenlik Rehberi
Avamar istemcileri, Avamar sunucusu ve Avamar istemci yazılımı arasındaki tüm iletişimlerin güvenliğini sağlamak için oturum güvenliğini kullanabilir. Avamar sunucusu, Avamar istemcisine kimlik doğrulama sağlar, Avamar istemcisi de Avamar sunucusuna kimlik doğrulaması sağlar.
Oturum güvenliği özellikleri, Avamar sistem işlemleri arasındaki iletişimler için güvenlik geliştirmeleri içerir.
Avamar, oturum anahtarlarını kullanarak Avamar sistem işlemleri arasındaki tüm iletişimleri güvenli hale getirir. Bir Avamar işlemi başka bir Avamar işleminden iletimi kabul etmeden önce geçerli bir oturum bileti gereklidir.
Oturum biletlerinin genel özelliklere aşağıda verilmiştir:
- Oturum bileti, değişikliğe karşı koruma sağlamak için şifrelenir ve imzalanır
- Oturum bileti kısa süreliğine geçerlidir
- Her oturum anahtarı benzersiz bir imza içerir ve yalnızca bir Avamar işlemine atanır
- Oturum anahtarının bütünlüğü şifreleme ile korunur
- Her Avamar sistem düğümü, oturum anahtarı imzasını ayrı ayrı doğrular
- Gerektiğinde, bir oturum, oturum bileti süresinin ötesine uzatılabilir
Avamar sistemi, Avamar sunucusuna kayıtlı her Avamar istemcisinde sunucu sertifikasına ilişkin genel anahtarı kurar. Avamar istemcileri, Avamar sisteminden yapılan aktarımları doğrulamak için genel anahtarı kullanır.
Şu anda kayıtlı olan istemciler için sunucu sertifikasına ve gerekli diğer sertifika dosyalarına ilişkin ortak anahtar, kurulumdan sonraki bir saat içinde istemciye yayılır.
Avamar sistemi ayrıca Avamar sunucu sertifikasını Avamar depolama düğümleriyle otomatik olarak paylaşır. Sertifikayı paylaşmak, yardımcı program düğümünün ve depolama düğümlerinin kimlik doğrulama için aynı sertifikayı sağlamasına olanak tanır.
Avamar sunucusu bir Avamar istemcisi kaydettiğinde istemci sertifikası oluşturulur.
Bir istemci sertifikası oluşturduktan sonra Avamar sistemi, sertifikayı istemciye kurmak için Avamar istemcisiyle şifrelenmiş bir bağlantı kullanır. Avamar sistemi, istemci sertifikasına ilişkin ortak anahtarı da depolar. Ortak anahtar, sonraki tüm iletişimlerde istemcinin kimliğini doğrulamak için kullanılır.
Oturum Güvenliği nasıl çalışır?
Oturum Güvenliği, Avamar sunucusunda etkindir. İstemciler, proxy'ler ve Data Domain sistemleri, etkinleştirildiklerinde, Avamar'da özel bir sertifika kayıt sürecinden geçer.
Bir Windows veya Linux istemcisinde ve proxy'sinde, kayıt sırasında Avamar sunucusunda Oturum Güvenliğinin etkin olduğunu görür. Avamar, istemcinin depolayabilmesi ve güvenebilmesi için dahili kök CA'sını istemciye (chain.pem) gönderir. İstemci bir sertifika imzalama isteği (CSR) oluşturur. CSR (avclient.csr), istemciden Avamar sunucusunun MCS işlemine gönderilir; MCS, CSR'yi imzalar ve istemciye bir sertifika anahtar çifti (key.pem ve cert.pem) verir.
Bir Data Domain'de, Data Domain'i Avamar'a eklerken veya SSL iletişimi yenilenirken Avamar, Data Domain'in kendisinden veya başka bir doğrulanmış Avamar'dan (imported-host ddboost) imzalı bir sertifikası olmadığını görür. Avamar, Data Domain kabuğu (ddsh) üzerinden SSH komutlarını çalıştırmak üzere Data Domain'de oturum açmak için Data Domain ssh özel anahtarını kullanır. Avamar, Data Domain sertifika imzalama isteğini (CSR) SCP üzerinden çeker ve CSR'yi Avamar dahili kök CA'sı ile imzalar. Data Domain, Avamar'dan imzalı sertifikayı aldığında (imported-host ddboost) Avamar, sertifikayı imzalayan kök CA'yı içe aktarır (imported-ca ddboost/login-auth olarak chain.pem).
Artık bir istemci/proxy kaydedildiğine ve Avamar MCS'de kimlik doğrulaması için gereken istemci tarafı sertifikalarına sahip olduğuna göre yedekleme denenir. Avamar, istemcinin veya proxy'nin Avagent dinleyicisine bir iş emri gönderir ve bu dinleyici de iş emrini alır. Ardından istemci veya proxy, Avamar'ın kayıt sırasında istemciye aktardığı Avamar kök CA'sını kullanarak Avamar sunucusunun sertifika zincirini doğrular ve onaylar. Benzer şekilde Avamar, istemcinin veya proxy'nin kimliğini doğrular. Bu noktada hiçbir veri aktarılmaz.
Kimlik doğrulama başarılı olduktan sonra iş emri başlatılır ve iş emrinin 'Waiting-Client' (Bekleyen İstemci) olan durumu 'Running' (Çalışıyor) olarak değişir.
İstemciler ve proxy'ler artık üzerlerinde yüklü olan avtar ikili dosyasını kullanarak verileri Avamar ve Data Domain'e taşır. Avtar ikili dosyası, verilerin nasıl taşındığına ve hangi verilerin taşındığına ilişkin ayrıntıları denetleyen bazı bayrakları iletir.
Bir istemci veya proxy üzerindeki avtar, Avamar'ın GSAN'sine bağlanmaya geçtiğinde verifypeer'in etkin olup olmadığını bilmelidir. Verifypeer ayarı, GSAN'nin 29000 numaralı bağlantı noktasındaki SSL soketini, gelen her bağlantı için istemci sertifikası gerekip gerekmediğini belirterek kontrol eden Oturum Güvenliği yapılandırmasının bir parçası olarak bir GSAN sunucusu ayarıdır. Neyse ki, TLS tokalaşması sırasında bir istemcinin veya proxy'nin istemci sertifikalarını gsan'ye nasıl sunacağını otomatik olarak işleyen TLS 1.2 protokolü uygulanır.
Aşağıda, verifypeer etkinleştirildiğinde TLS karşılıklı/iki yönlü tokalaşması gösterilmektedir.
İstemci veya proxy bakış açısından, sağı gösteren ok Avamar sunucusuna giden bir bağlantıdır. Solu gösteren ok, Avamar sunucusundan istemciye gelen bir bağlantıdır.
[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 devre dışı bırakıldığında, istemcinin GSAN'ye bir istemci sertifikası göndermesi gerekmez.
[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
Önemli olan, istemci veya proxy'nin GSAN tarafından istenmesi halinde karşılıklı TLS tokalaşması gerçekleştirebilmek için gerekli istemci tarafı sertifikalarına sahip olmasıdır.
Bu, Avamar dahili kök CA'sı değişirse istemcinin, proxy'nin veya Data Domain'in kendileri için sertifikaları imzalamak üzere yeni kök CA'yı alması gerektiği anlamına gelir.
İstemci veya proxy, GSAN'ye başarıyla bağlandıktan sonra Data Domain'e bağlanmaya çalışır.
Aşağıdaki günlükte avtar ile Data Domain'e bağlanan bir proxy gösterilmektedir. Verifypeer ayarı devre dışı bırakılır ancak Oturum Güvenliği etkinleştirilir (Kimliği Doğrulanmış-Tekli modu).
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 bir Avamar GSAN sunucusu ayarı olduğundan, Oturum Güvenliği etkinse avtar'ın doğrudan Data Domain'e bağlanma şeklini etkilemez. Bu, istemci veya proxy ile Data Domain arasında karşılıklı bir TLS tokalaşması gerçekleşeceği anlamına gelir.
İstemci veya proxy, istemci kaydı sırasında (veya DD düzenleme veya ekleme zamanında) Avamar tarafından içe aktarılan aynı Avamar dahili kök CA'yı paylaştığı için Data Domain sertifika zincirini doğrulayabilir.
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
Sertifika doğrulamasından sonra tokalaşma tamamlanır ve yedekleme verileri istemciden ağ üzerindeki Data Domain ve Avamar'a taşınır.
Oturum Güvenlik Ayarlarını Yönetme
Aşağıdaki iki makale, Oturum Güvenliği ayarlarını komut satırından veya Avinstaller web hizmetinden yönetmek için kullanılır.
000222234 | Avamar: Oturum Güvenliği Ayarlarını CLI'den Yönetme
000222279 | Avamar: Avinstaller Installation Package (AVP) ile Oturum Güvenliği Ayarlarını Yönetme
Olası dört yapılandırma desteklenmektedir:
- Disabled
- Karma-Tekli
- Kimliği Doğrulanmış-Tekli
- Kimliği Doğrulanmış-Çift
Devre dışı
Ayarları:
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"
Oturum Güvenliği devre dışı bırakıldığında istemciler yalnızca 28001 numaralı bağlantı noktasında Avamar'ın Avagent hizmetine bağlanır ve istemciler Avamar'dan gelen istekler için 28002 numaralı Avagent bağlantı noktasını dinler.
Bir proxy, 28009'u dinler.
28001 numaralı bağlantı noktası düz bir TCP yuvasıdır ve TLS tokalaşması gerçekleştirmez.
İstemci, 29000 numaralı bağlantı noktasında Avamar GSAN'ye bağlanır ve tek yönlü bir TLS tokalaşması gerçekleştirir. Bu, Oturum Güvenliği devre dışı bırakılması durumunda bile istemci ile Avamar arasında yedekleme verileri aktarıldığında bu verilerin hareket halindeyken şifrelendiği anlamına gelir.
Avamar yazılımıyla kimlik doğrulama sertifikaları Avamar, proxy'ler, istemciler ve Data Domain arasında alınamaz.
Karma-Tekli
Ayarları:
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"
Oturum Güvenliği Avamar 7.3'te ilk kez kullanıma sunulduğunda daha çok karma tekli mod kullanılıyordu, özellikle sürümü 7.3 veya üzeri olmayan istemcilerin Avamar'a kaydolmasına ve yedekleme yapmasına olanak tanıyordu. Bu makalenin yazıldığı tarihte Avamar 19.10 en güncel sürüm olup Karma-Tekli modu, esasen ele alınacak bir sonraki mod olan Kimliği Doğrulanmış-Tekli ile aynı olacaktır.
Kimliği Doğrulanmış-Tekli
Ayarlar:
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"
Bu modda Oturum Güvenliği etkinleştirilir ve sertifikalar, yedekleme öncesinde kimlik doğrulama için Avamar, istemciler, proxy'ler ve Data Domain arasında iletilir.
İstemciler artık Avamar'dan gelen Avagent iş emri istekleri için 30002 numaralı bağlantı noktasını, proxy'ler ise 30009 numaralı bağlantı noktasını dinler. Avamar, istemcilerden ve proxy'lerden gelen bağlantı istekleri için 30001 ve 30003 numaralı bağlantı noktalarını dinler. Bunlar, TLS tokalaşması gerçekleştiren SSL soketleridir.
Kimliği Doğrulanmış-Tekli modu, Karma-Tekli modundan farklı olarak tüm istemcileri Oturum Güvenliği yöntemlerini kullanarak kaydolmaya zorlar.
Bu mod, Avamar'ın GSAN sistemindeki verifypeer hizmetini devre dışı olarak ayarlar. Yani GSAN için gelen avtar bağlantısından istemci sertifikalarına gerek duyulmaz.
Kimliği Doğrulanmış-Çift
Ayarlar:
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"
Kimliği Doğrulanmış-Çift, Avamar'ın GSAN hizmetinde verifypeer ayarını etkinleştirmesi haricinde Kimliği Doğrulanmış-Tekli ile aynıdır.
Kimliği Doğrulanmış-Çift, bir Avamar sunucusuna uygulanabilecek en güçlü ayar olarak kabul edilir; bu, Avamar dağıtımları sırasında varsayılan seçimdir.
Genel bakış: Avamar kendinden imzalı dahili kök CA'si
Avamar dahili kök CA'sı, Avamar ve Avamar'ın içe aktarma işlemi yaptığı istemciler, proxy'ler ve Data Domain'ler için dahili olarak güvenilen bir sertifika yetkilisidir.
Avamar, sertifika imzalama isteklerine (CSR'ler) yönelik sertifikalar sağladığından kendisi için dahili CA'dır.
Avamar, GSAN sertifikalarını imzalamak için kök CA'sını kullandığında sertifikalar aşağıdaki konumda depolanır:
/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
Bir güvenlik tarayıcısı Avamar'da 29000 numaralı bağlantı noktasını tararsa bu bağlantı noktasında kendinden imzalı sertifikaları bildirir ve bu sertifika, GSAN'ye yapılan yedeklemeleri işler.
Bazı ortamlarda bu işlem kabul edilmeyebilir ve Avamar dahili kök CA'sını kullanıcı tarafından sağlanan dahili kök CA ile değiştirme hakkında daha fazla bilgi için aşağıdaki KB makalesine bakmanız önerilir.
KB 000204629 | Avamar: Avamar Sertifika Yetkilisi'ni (CA) Kullanıcı Tarafından Sağlanan Sertifika Yetkilisi (CA) ile Yükleme/Değiştirme
İşlem, şirket içinde kullanıcı tarafından sağlanan bir sertifika yetkilisini yüklemek için importcert.sh komut dosyasının nasıl kullanılacağını ayrıntılı olarak açıklar. Kullanıcı tarafından sağlanan sertifika yetkilisinin güvenlik ekibi tarafından yönetilmesi olasıdır çünkü hiçbir genel sertifika yetkilisi CA'larının özel anahtarını vermez ve başkaları için sertifika imzalayıp bir güven zincirini sürdürerek para kazanmalarının nedeni budur.
Dahili CA'ya örnek olarak Microsoft Active Directory Sertifika Hizmetleri verilebilir.
Active Directory Sertifika Hizmetleri nedir? | Microsoft Learn
Genel CA'ya örnek olarak DigiCert verilebilir.
Avamar dahili kök CA'sının değiştirilmesi, Avamar anahtar deposundaki kök anahtar çiftinin kullanıcı tarafından sağlanan CA anahtar çiftiyle değiştirilmesiyle gerçekleştirilir. Ardından GSAN bir CSR ve özel anahtar oluşturur, CSR'yi yeni CA anahtar çiftine imzalatır ve bu bölümde önceden bahsedilen dosyalar değiştirilir. GSAN, 29000 numaralı bağlantı noktasında SSL soketini yeniden yükler ve GSAN’ye bağlanan yeni istemciler, kullanıcı tarafından sağlanan CA'yı görür.
Güvenlik Tarayıcıları artık bağlantı noktasında imzalı sertifikaları gösterir ve istemcilerin, proxy'lerin ve Data Domain'in yeni CA'yı almak için yeniden kaydolması gerekir.
Sınırlamalar
Avamar oturum güvenliği özellikleri bazı sınırlamalara tabidir:
- İstemciler
- Oturum güvenliği özellikleri aşağıdaki Avamar istemcilerinin hiçbiriyle kullanılamaz:
- Veritas Cluster Server'da Solaris için Avamar küme istemcisi
- Solaris kümelerinde Solaris için Avamar istemcisi
- Oturum güvenliği özellikleri aşağıdaki Avamar istemcilerinin hiçbiriyle kullanılamaz:
- Diğer ürünler
- Avamar sunucusunun, Avamar istemcilerinin ve Data Domain sisteminin (varsa) NTP zaman senkronizasyonunun kullanılması önerilir. Zamanın senkronize edilememesi, sertifika geçerliliği ve geçerlilik bitiş süreleri nedeniyle kayıt ve yedekleme/geri yükleme hatasına neden olabilir. Bir ana bilgisayarda saat dilimini değiştirmek de benzer bir etki bırakabilir ve bu durumda sertifikanın yenilenmesi gerekebilir.
- Güvenli Belirteç
- Güvenli Belirteç Kimlik Doğrulaması aşağıdaki koşullarda çalışmaz:
- İstemci makinesi bir Network Address Translation (NAT) güvenlik duvarı aygıtının arkasındadır
- İstemcinin ana bilgisayar adı, IP adresinden çözümlenen FQDN'den farklı bir sanal addır
- İstemci makinede birden fazla IP arayüzü vardır; her biri farklı bir Tam Nitelikli Etki Alanı Adı (FQDN) şeklinde çözümlenir. Daha fazla bilgi için şu KB'ye bakın: KB 000056252 | Avamar: Data Domain'e yedekleme, çok fazla IP adresi nedeniyle "DDR_GET_AUTH_TOKEN" mesajını vererek başarısız oldu
- Güvenli Belirteç Kimlik Doğrulaması aşağıdaki koşullarda çalışmaz:
Oturum Güvenliği Değişikliği Planlaması
Oturum Güvenliği ayarlarında bir değişiklik yapmadan önce, önceki yapılandırmayı veya sertifikaları geri yükleyebilmek için bir değişiklik yapmadan önce aşağıdaki adımlar uygulanabilir.
Avamar dahili kök CA'sı değiştirilirse istemcilerin, proxy'lerin ve Data Domain'in yeniden kaydedilmesi gerektiğini unutmayın. Ortamın (istemci, proxy ve Data Domain sayısı) boyutuna bağlı olarak bu, birkaç gün sürebilecek zahmetli bir görev olabilir.
Sertifikaların yeniden oluşturulup kayıt ve yedekleme hatalarının yaşandığı bir durum, kullanım örneği olarak verilebilir.
Sertifikaların süresinin dolmadığı veya dolmak üzere olmadığı ve kazara yeniden oluşturulduğu varsayımıyla aşağıdaki adımlar, veri kaybının veya veri noksanlığının nasıl önleneceğine ilişkin rehberlik sağlar.
Mevcut Oturum Güvenliği ayarlarını alıp not edin:
enable_secure_config.sh --showconfig
Avamar anahtar deposunun bir kopyasını oluşturun:
cp -p /usr/local/avamar/lib/avamar_keystore /usr/local/avamar/lib/x-avamar_keystore-original
Sertifikaların, Oturum Güvenliği AVP veya CLI yöntemleri kullanılarak yeniden oluşturulduğunu varsayalım.
Bu, Avamar anahtar deposunun değiştiği ve GSAN sertifikalarının yeniden imzalandığı anlamına gelir.
Orijinal Avamar anahtar deposu kolayca yerine geri taşınabilir:
cp -p /usr/local/avamar/lib/x-avamar_keystore-original /usr/local/avamar/lib/avamar_keystore
GSAN sertifikalarını yeniden oluşturun:
enable_secure_config.sh --certs
MCS'yi ve Yedekleme Zamanlayıcısını tekrar başlatın:
mcserver.sh --restart --force dpnctl start sched
Bu işlem, istemcilerin, proxy'lerin ve Data Domain'in halihazırda güvendiği orijinal Avamar dahili kök CA'sını eski durumuna getirir.
Sorun giderme
Oturum Güvenliği ayarlarını değiştirmek veya sertifikaları yeniden oluşturmak çoğu zaman kolaydır.
Bu bölümde sertifikalar yeniden oluşturulduktan veya ayarlar değiştirildikten sonra her şeyin nasıl yeniden çalıştırılacağı ele alınmıştır.
Yerel Temizleme İşlemleri
Verifypeer'in etkinleştirildiği senaryoda, tüm Avamar sertifikaları yeniden oluşturulduğunda Avamar sunucusuna ait avtar ve avmgr'nin kullandığı istemci sertifikaları hemen güncelleştirilmez.
Bu, MCS planlı bir boşaltma (MCS yapılandırmasının GSAN'ye yedeklenmesi) çalıştırdığında, TLS tokalaşma hatası nedeniyle başarısız olacağı anlamına gelir. Bunun nedeni, Avamar sunucusu üzerinde çalışan avtar istemci sertifikalarının henüz güncelleştirilmiş Avamar dahili kök CA'sını ve yeni imzalı istemci sertifikaları kümesini almamış olmasıdır.
Daha fazla bilgi için aşağıdaki KB'ye bakın:
000214340 | Avamar: Avtar, Avamar'ın GSAN hizmetine bağlanamıyor, "Kritik sunucu bağlantı sorunu, başlatma iptal ediliyor. Doğru sunucu adresini ve oturum açma kimlik bilgilerini doğrulayın.”
Çoğaltma
Çoğaltma hedefinde verifypeer'in etkinleştirildiği ve sertifikaların hedefte yeniden oluşturulduğu senaryoda, yukarıdaki "Yerel Yıkama İşlemleri" bölümündekine benzer bir yaklaşım izlenmelidir.
Öncelikle, çoğaltma iş emirlerini kabul edebilmesi için çoğaltma hedefi Avagent'in kayıtlı olduğundan emin olun.
Hedefte, aşağıdaki konumdaki Avagent günlüğünü kontrol edin:
/usr/local/avamar/var/client/avagent.log
Sorunsuz bir günlük şöyle görünebilir:
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
Günlükte daha geriye giderken yakın zamanda başarılı bir yeniden kayıt olabilir:
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
Sertifika değişikliklerinin neden olduğu kayıt sorunlarını içeren sorunlu bir günlük aşağıdaki gibi görünebilir:
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.
Bu durumda, Avagent'i MCS'ye hemen yeniden kaydetmek için aşağıdaki adımlar izlenmelidir:
Büyük olasılıkla Avamar FQDN'si olacak MC_SYSTEM hesap adını alın:
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 hesabını devre dışı bırakın:
mccli client edit --name=/MC_SYSTEM/<avamar_fqdn> --activated=false example: mccli client edit --name=/MC_SYSTEM/avamar.lab --activated=false
MC_SYSTEM hesabını yeniden kaydedin:
/etc/init.d/avagent register <avamar_fqdn> /MC_SYSTEM example: /etc/init.d/avagent register avamar.lab /MC_SYSTEM
Kayıt başarılı olduktan sonra Avagent, hedefte çoğaltmayı kabul edebilir.
Artık, çoğaltma hedefi Avamar'da verifypeer etkinleştirilmişse hedef Avamar'a bağlanmak için kullanılan istemci sertifikalarını kaynak Avamar'da yeniden oluşturmamız gerekir.
KB 000214340'a benzer | Avamar: Avtar, Avamar'ın GSAN hizmetine bağlanamıyor, "Kritik sunucu bağlantı sorunu, başlatma iptal ediliyor. Doğru sunucu adresini ve oturum açma kimlik bilgilerini doğrulayın.”
Mevcut hedef Avamar sertifikaları klasörünü kaynak Avamar ssh oturumundan kaldırın:
rm -r /usr/local/avamar/etc/<destination_avamar_ip_address> rm -r /usr/local/avamar/etc/client/<destination_avamar_ip_address>
İstemci sertifikalarını yeniden oluşturun:
/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
Hedef Avamar ile iletişim, Kaynak Avamar ssh komut satırından test edilebilir:
avmgr logn --id=repluser --ap=<destination_repluser_password> --hfsaddr=<destination_avamar_ip_address> --debug --x19=1024 --x30=8192
İstemci Kaydı
Yedeklemeler, Oturum Güvenliği ayarları değiştirildikten veya sertifikalar yeniden oluşturulduktan sonra denenebilir.
Bu, 'Timed-Out Start' (Zaman Aşımına Uğramış Başlangıç) ile yedekleme başarısız olana kadar 'Waiting-Client' (Beklemede-İstemci) durumunda birçok aracı tabanlı istemci bulunmasına neden olabilir.
Yeni sertifikalar yeniden oluşturulduktan sonra istemcinin otomatik olarak yeniden kaydolmayı denemesi yaklaşık 23 saat sürer.
Aracı tabanlı istemcilerin Avamar MCS'ye yeniden kaydolması için bir davet göndermek üzere Avamar sunucusunda aşağıdaki komut kullanılabilir.
mccli client re-register-all
Komut, her bir istemciye sırayla davet göndereceği için bu işlem, istemci sayısına bağlı olarak biraz zaman alabilir. SSH oturumunun zaman aşımına uğraması ihtimaline karşı komutu arka planda çalıştırmayı değerlendirin.
nohup mccli client re-register-all &
Bu işlemin tüm aracı tabanlı istemcileri yeniden kaydetmek için işe yaramayabileceğini ve bazılarının manuel olarak yeniden kaydedilmesi gerekebileceğini unutmayın.
Windows'da bir istemciyi yeniden kaydetmeye yönelik manuel işlem şu şekilde olacaktır:
- Eski istemci sertifikalarını içeren aşağıdaki dizinin içeriğini kaldırın:
-
"C:\Program Files\avs\etc"
-
- "Backup Agent" (Aracı Yedekleme) hizmetini yeniden başlatın
- Eski istemci sertifikalarını içeren aşağıdaki dizinin içeriğini kaldırın:
-
/usr/local/avamar/etc
-
- Avagent hizmetini yeniden başlatın:
-
service avagent restart
-
İstemci makinesini yeniden başlatmak, tam bir yeniden kaydı denemek ve tetiklemek için de yapılabilir.
Oturum Güvenliği etkinleştirildiğinde ad çözümlemesinin istemcilerin kaydedilmesinde önemli bir rol oynadığını göz önünde bulundurun. İstemcilerin, Avamar sunucusunda ileri ve geri DNS araması yapabildiğinden emin olun. Bu, DNS A kayıtlarını yapılandırarak veya istemcideki girişleri barındırarak gerçekleştirilebilir.
Avamar, manuel yeniden kayıt gerçekleştirmek için bağlı her istemciye ulaşabilecek herhangi bir komut dosyası sağlamaz. Daha önce bahsedilen mccli komutu buna en yakın olanıdır.
Proxy Kaydı
Proxy'ler kullanılarak Avamar'a yedeklenen sanal makineler, genellikle aracı tabanlı istemcilerden çok daha az proxy bulunduğundan, oturum sonrası güvenlik değişiklikleri söz konusu olduğunda biraz avantajlıdır.
Proxy'ler de 23 saat içinde otomatik olarak yeniden kaydolmayı denemelidir ancak bunları hemen yeniden kaydetmek daha kolay ve hızlı olabilir.
Proxy'lere yeniden kaydolmaya zorlamak için kullanılabilecek birkaç seçenek vardır.
İlk seçenek, aşağıdaki komutla proxy'leri yeniden başlatmak olabilir:
mccli mcs reboot-proxy --all
İkinci seçenek, proxy'leri yönetmek için Goav aracını kullanmak olacaktır.
Gerektiğinde proxy'lerde oturum açabilmesi için Goav aracının proxy parolasını ayarlayın. Aşağıdaki komut proxy'nin işletim sistemi parolasını değiştirmez, sadece parolayı şifreli olarak saklar. Böylece Goav aracı SSH üzerinden oturum açması gerektiğinde proxy'de oturum açmak için kullanabilir.
./goav proxy set-password
Bağlı tüm proxy'lerde Avagent yeniden başlatma işlemi gerçekleştirin:
./goav proxy exec "service avagent restart"
Yeniden kaydın başarılı olup olmadığını görmek üzere proxy'deki Avagent günlüğünü kontrol etmek için aşağıdaki komutu çalıştırın:
./goav proxy exec "grep -i registration /usr/local/avamarclient/var/avagent.log"
Başarılı bir çıktı aşağıdaki gibi olabilir:
============== 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.
Üçüncü seçenek, proxy'ye SSH göndermek ve başlatma komut dosyasını çalıştırmaktır:
/usr/local/avamarclient/etc/initproxyappliance.sh start
Data Domain Senkronizasyonu
Oturum Güvenliği ayarları değiştirildikten veya Avamar'da sertifikalar yeniden oluşturulduktan sonra Data Domain'in yeniden eşitlenmesi veya SSL bağlantısının yeniden kurulması gerekir.
Aşağıdaki KB makalesinde bu senaryo ve yeni sertifikaların Data Domain ile nasıl değiştirileceği ele alınmıştır.
000197106 | Avamar ve Data Domain Entegrasyonu: DD'nin Avamar AUI'da ve/veya kullanıcı arayüzünde Kırmızı Göstermesiyle İlgili Çözüm Yolu
Avamar ve Data Domain SSL sorun giderme işleminin Goav aracıyla gerçekleştirilmesi önemle tavsiye edilir.
Goav sayesinde Avamar ile Data Domain SSL bağlantısı otomatik olarak tanılanıp çözümlenebilir. Daha fazla bilgi için aşağıdaki KB'ye bakın:
000215679 | Avamar: Goav dd check-ssl özelliği hakkında bilgiler
Avamar ve Data Domain sertifikalarını otomatik olarak düzeltmek için aşağıdaki komutu çalıştırın:
./goav dd check-ssl --fix