TIE ve DXL bağlantısı: Connected durumundan uçtan uca sağlık kabulüne

ePO üzerinde DXL bağlantısının düzelmesi önemli bir adımdır; ancak TIE hizmetinin ve ilk baştaki endpoint politika sorununun da çözüldüğünü göstermez. Yönetim, broker iletişimi ve uygulama görevleri farklı kabul noktaları olarak ele alınmalıdır.

1. Topolojiyi çıkar
2. Sürümü karşılaştır
3. TLS güvenini incele
4. DXL bağlantısını doğrula
5. TIE görevini sına
6. İlk hatayı yeniden dene

Bileşenleri ve bağımlılıkları haritalayın

ePO, DXL Broker, DXL Client ve TIE sürümleri ayrı kaydedilir. Aynı sanal makinede bulunmaları aynı servis oldukları anlamına gelmez. Hangi istemcinin hangi broker üzerinden bağlandığını belirleyin.

DNS, zaman ve gerekli ağ erişimleri kontrol edilir. İlgili portun açık olması TLS el sıkışmasının başarılı olduğunu kanıtlamaz. Ağ testi ile uygulama bağlantı sonucu ayrı raporlanmalıdır.

TLS ve sürüm uyumluluğunu doğrulayın

Sertifika süresi, güven zinciri, ad eşleşmesi ve desteklenen şifre takımları incelenir. Eski broker ile yeni istemci farklı protokol beklentisine sahip olabilir. Başarısız el sıkışmanın hangi uçta kaydedildiğini araştırın.

Güveni sağlamak için sertifika doğrulamasını kapatmak kalıcı çözüm değildir. Üretici tarafından desteklenen sürüm ve sertifika geçişi tercih edilir. Bir dokümandaki cipher listesini farklı ürün veya sürüme körlemesine uygulamayın.

DXL bağlantısını iki taraftan kontrol edin

ePO DXL Client durumu ile TIE’nin DXL bağlantı sağlığı ayrı incelenir. Konsolda eski durum önbellekte kalmış olabilir; zaman damgası ve yeni bağlantı denemesiyle doğrulayın.

Broker çalışıyor görünse de fabric veya istemci kayıt sorunu bulunabilir. Topoloji görünümü, ürün sürümleri ve bağlantı günlükleri birlikte değerlendirilir. Genel servis restart’ı öncesinde ilk hata kanıtı saklanmalıdır.

TIE işlevini gerçek bir görevle sınayın

Reputation araması, TIE topoloji sağlığı ve uygun veri yönetimi görevinin sonucu kontrol edilir. Bir görevin başlatılması ile Completed olması farklıdır. Başarısız görevde alt hata ve bağımlılık kaydı incelenir.

DXL düzeldiğinde başka bir ENS politika hatası otomatik olarak kapanmış sayılmaz. İlk sorunu oluşturan işlem yeniden denenmeli ve kendi başarı ölçütüyle değerlendirilmelidir. Birden fazla arızayı tek sonuç cümlesinde birleştirmeyin.

Değişiklik etkisini izleyin

Güncelleme veya sertifika değişimi sonrasında bağlantı kararlılığı ve görev süreleri izlenir. Kullanılan geçici istisnalar ve debug ayarları kaldırılır. Kesinleşmeyen kök nedenler raporda olasılık olarak kalmalıdır.

• ePO ve TIE DXL bağlantıları sağlıklı.
• Sertifika zinciri ve saat doğru.
• Sürüm matrisi destekli.
• TIE işlevsel görevi başarılı.
• İlk endpoint hatası ayrıca yeniden sınandı.

İlgili çalışma notları

• ePO açılmıyor veya servis 1053 veriyor: SQL, kimlik ve TLS zinciri
• UTM block neden oluşur? Sertifika, kategori ve FortiGuard hatasını ayırmak
• SQL Server bağlantısı: DNS, port, TLS ve sürüm bilgisini doğru ayırmak