ASA FirePOWER modülünün FMC’ye yönetim rotası yok

FMC modülü ulaşılamaz olarak gösterir, kayıt beklemede kalır ve ASA’nın içinden gelen ping kusursuz çalışır. Mevcut bir ASA FirePOWER kurulumunda bu bileşim normaldir. Modülün kendi yönetim adresi, kendi varsayılan ağ geçidi ve kendi yönlendirme kararları vardır ve bazı platformlarda ASA ile fiziksel yönetim bağlantısını paylaşmak bunları tek bir ağ yığınında birleştirmez. İki cihaz aynı kablo üzerinde iki farklı bakış açısıyla yanıt verir.

Aşağıdakiler hâlihazırda hizmette olan modüller için geçerlidir. Bir kılavuzdaki herhangi bir bağlantı noktası şemasını uygulamadan önce şasi modelini, modül türünü ve desteklenen yazılım sürümünü belirleyin.

Modülü ayrı bir ana bilgisayar olarak çizin

Şemaya modülün yönetim IP’si, maskesi ve varsayılan ağ geçidi, o bağlantıyı gerçekten taşıyan VLAN ve erişilmesi gereken FMC adresiyle başlayın. Ardından ayrı bir kutuda ASA’nın arayüz adreslerini ve tam yönlendirme tablosunu yazın. İki kutu sonunda farklı sahiplerin adreslerini içeren bir alt ağı paylaşırsa sorunun ilginç kısmını bulmuşsunuz demektir.

ASA FirePOWER modülü kılavuzu, bağlantı noktası düzenlerinin platformlar arasında nasıl farklılaştığını, ASA ile modülün aynı segmentte ayrı adresler taşıdığı paylaşılan yönetim kablolaması da dahil olmak üzere gösterir. Bu donanım şeması tasarım için bir girdidir, dipnot değil.

Dönüş yolunun nerede koptuğunu bulun

Çekirdek üzerinden yönlendirilen bir düzen alın. Modül FMC’ye yönelik trafiği bir Layer 3 çekirdeğine gönderir, çekirdek uzak yönetim hedefini ASA’nın iç arayüzüne yönlendirir ve sitenin VPN’i onu diğer tarafa taşır. Ardından uzak sitenin modülün yönetim alt ağına dönüş rotasına ihtiyacı vardır. Bu zincirdeki her adım doğru olabilirken o son rota eksik olabilir, bu yüzden arıza çoğu zaman kopmuş bir tünel gibi görünür.

Herhangi bir şeyi değiştirmeden önce ASA’nın kendi görünümünü okuyun:

show interface ip brief
show route
show running-config interface

Üçüncü komut önemlidir çünkü unuttuğunuz bir arayüz adresi, dönüş yolunun yanlış cihaza inmesine neden olan şeydir.

ASA’nın neyi bağlı saydığını denetleyin

ASA’nın modülün yönetim alt ağında bir adresi varsa, bağlı rotası o öneki sahiplenir. Çekirdeğe doğru statik bir rota bağlı rota sahipliğini yerinden etmez, bu yüzden paket ASA’ya geri döner ve orada durur. Kayıt ardından kimlik bilgileriyle hiçbir ilgisi olmayan bir noktada başarısız olur.

Belirli bir sahtecilik önleme denetiminin paketi düşürdüğü sonucuna varmayın, cihazın kendi gözlemleri önünüzde değilse. Bunun yerine giriş arayüzünü, seçilen hedef rotasını ve o platform için desteklenen yönetim ile veri arasındaki iletim sınırını karşılaştırın. Bu üç olgu genellikle biri kayıt anahtarlarını sıfırlamaya başlamadan önce topoloji çatışmasını ortaya çıkarır.

Modülü bağlı tutan bir düzeltme seçin

ASA’nın adresini o segmentten kaldırmak ile paylaşılan bir bağlantı noktasını fiziksel olarak devre dışı bırakmak eşdeğer eylemler değildir. Modülün aynı fiziksel yönetim bağlantısı üzerinden gittiği platformlarda, bağlantı noktasını devre dışı bırakmak modülün tek bağlantısını kaldırır — yönlendirme sorununu ölü bir cihaza dönüştürmüş olursunuz. Yönetim yönlendirmesinin sahipliğini yeniden atayan değişikliği tercih edin ve ağ sahibinin katılımıyla hazırlayın.

Desteklenen ikinci seçenek, ASA’nın yönetim yoluna kendi segmentini vermek ve böylece modülün yönetim alt ağının tek bir sahibi olmasını sağlamaktır. Bu bir adres ve biraz belgelendirme maliyeti getirir ve belirsizliği kalıcı olarak ortadan kaldırır. Hangi yolu seçerseniz seçin, sonrasında modülün hem FMC’ye hem de DNS veya NTP kaynaklarına erişebildiğini doğrulayın.

Yol tutarlı olduktan sonra kaydolun

Dönüş yolu temizlendikten sonra yönetim bağlantısını ve kayıt parametrelerini eşleşen FMC ve modül sürüm kılavuzundan planlayın. Kayıt sırlarını paylaşılan notlardan ve kayıtlardan uzak tutun ve tanılama adımı olarak yeniden kaydolma cazibesine direnin: kopmuş bir yolda yeni bir anahtar yalnızca aynı hatayı daha yeni bir zaman damgasıyla üretir.

Yolu ASA’dan kaynaklanan bir ping yerine modülün kendi yönetim yığınından kabul edin, çünkü testin kaynağı tam olarak şüphe altındaki şeydir. Modülün sonraki atlamasını, ASA’nın VPN seçimini ve FMC’nin yanıt rotasını kaydedin ve her iki yönetim rolü için bağımsız bir kurtarma yöntemi tutun. Onarılmış bir taşımayı başarılı bir kayıttan ayıran şey o kayıttır.

Modül sonunda FMC’de göründüğünde aynı üç komutu yeniden çalıştırın ve çıktıyı şemanın yanına kaydedin. O yönetim segmentine dokunacak sonraki kişinin ihtiyacı tam olarak bu karşılaştırma olacaktır.