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

Nasıl yapılır: ayrıntılı uygulama

Ortam ve ön koşullar: Trellix TIE / DXL — TIE, DXL broker ve ePO bileşen sürümleriyle desteklenen bağlantı matrisi gerekir.

1. Bileşen ve bağlantı haritasını kaydedin
2. DNS, saat ve TLS ön koşullarını ölçün
3. Sertifika zinciri ve topic yetkisini inceleyin
4. Güvenli sorgu/yanıt kabulü yapın
5. Hata dalı ve geri dönüşü ayırın

1. Bileşen ve bağlantı haritasını kaydedin

ePO’daki DXL broker/TIE sağlık görünümünde kurulu ürün sürümü, broker topology ve ilgili istemcinin son iletişim zamanını okuyun. Broker portlarını kendi sürüm belgesinden alın; varsayılanı körlemesine açmayın.

2. DNS, saat ve TLS ön koşullarını ölçün

Windows pilotta DNS/TCP örneği vardır; port ürün kaydından kullanıcı tarafından girilir. Başarılı TCP, TLS veya yetkilendirme başarısı değildir.

Resolve-DnsName dxl.batuhanyazici.com
$port = [int](Read-Host 'Belgedeki gercek broker TCP portu')
Test-NetConnection dxl.batuhanyazici.com -Port $port
w32tm /query /status

3. Sertifika zinciri ve topic yetkisini inceleyin

TIE/DXL ürün görünümünde certificate validity, trust ve istemci yetki/role bilgilerini karşılaştırın. Farklı broker’a bağlı istemciyi tek broker loguyla temiz saymayın. Özel anahtarı dışarı çıkarmayın.

4. Güvenli sorgu/yanıt kabulü yapın

Ürünce desteklenen güvenli test hash/itibar nesnesiyle talep üretin. Request/response korelasyonu, doğru broker yolu ve yanıtın tazeliğini birlikte okuyun; gerçek zararlı dosya yüklemeyin. Connected göstergesi yayın/abonelik yolunu tek başına kanıtlamaz.

5. Hata dalı ve geri dönüşü ayırın

DNS/TCP yokluğu, TLS trust hatası, topic/rol reddi ve TIE cevap gecikmesini farklı kaydedin. Yalnız değiştirilen sertifika/rol/broker atamasını uyumlu önceki sürüme alın; bütün trust kontrollerini kapatmayın.

Beklenen sonuç: İstemci isteği ilgili TIE/DXL yolundan geçer ve beklenen yanıt, doğru zaman kaydıyla görülür.

Sonuç farklıysa: Connected görünmesine rağmen yanıt yoksa topic/rol/sertifika ve istemci yapılandırmasını ayrı inceleyin.

Geri dönüş: Değiştirilen sertifika veya broker atamasını uyumlu önceki tanıma döndürün; tüm güven denetimini kapatmayın.