Ağda Değişiklik Penceresi: Ön Kontrol, Geri Dönüş ve Doğrulama

Ağdaki kesintilerin önemli bir kısmı arızadan değil, planlı değişiklikten çıkar: yanlış porta uygulanan bir ACL, “add” kelimesi unutulmuş bir trunk komutu, yönetim erişimini kesen bir rota. Aşağıda değişikliğin teknik yürütmesini anlatıyoruz: değişiklik öncesi durum kaydı, adım adım uygulama planı, Cisco ve diğer platformlarda otomatik geri dönüş mekanizmaları, uzaktan erişimi kaybetmemek için önlemler ve sonrasındaki doğrulama. Onay ve denetim kanıtı tarafı değil, mühendisin pencere içinde konsolda ne yaptığı konu ediliyor.

Ağ değişikliklerinde kesinti riskinin kaynakları

Hangi güvenlik ağının gerektiğini risk belirler. Sahada en sık gördüğümüz kesinti kaynakları şunlar:

• Kendi erişimini kesmek: VTY ACL’i, yönetim SVI’si, varsayılan rota veya yönetim VLAN’ının trunk’tan çıkarılması gibi değişikliklerle uzaktaki cihaza erişimin kaybedilmesi.
• Üzerine yazan komutlar: Cisco’da switchport trunk allowed vlan 30 komutu izin listesini yalnız VLAN 30 yapar; mevcut listeye eklemek için switchport trunk allowed vlan add 30 gerekir. Bir prefix-list veya ACL’i yeniden tanımlamak da mevcut satırları silebilir.
• Kontrol düzlemi yeniden yakınsaması: STP kök köprüsünün değişmesi, OSPF/BGP komşuluklarının düşmesi veya port-channel üyeliklerinin bozulması kısa ama geniş etkili kesintiler yaratır.
• Görünmeyen bağımlılıklar: Kullanılmadığı sanılan bir VLAN’da çalışan eski bir cihaz, bir statik rotaya bağlı bir uygulama.
• Kayıt eksikliği: Önceki durum kaydedilmediği için neyin değiştiğinin ve neye dönüleceğinin bilinmemesi.

Listedeki ilk iki madde, uzak lokasyona gece yarısı konsol kablosuyla gitmeyi gerektiren arızaların başında gelir. İkisi de tek satırlık hatadır.

Değişiklik öncesi temel durum kaydı

Doğrulamanın tamamı “önce” ve “sonra” karşılaştırmasına dayanır. Değişiklikten hemen önce, etkilenecek her cihazda aynı komut seti çalıştırılır ve dosyaya kaydedilir. Cisco IOS/IOS XE için tipik bir set:

terminal length 0
show running-config
show version
show interfaces status
show interfaces trunk
show etherchannel summary
show spanning-tree root
show ip interface brief
show ip route summary
show ip ospf neighbor
show ip bgp summary
show mac address-table count
show logging

Çıktılar değişiklik kaydına eklenir. Değişiklikten sonra aynı set tekrar alınır ve Linux’ta diff -u once.txt sonra.txt ile karşılaştırılır. Sayaç ve uptime gibi doğal olarak değişen alanlar gürültü üretir; karşılaştırmada durum odaklı komutları (komşuluklar, port durumu, rota özeti) öne alın. Konfigürasyon yedeklerinin sürekli ve sürümlü tutulduğu bir ortamda değişiklik öncesi ve sonrası konfigürasyon farkı da otomatik çıkar; bu kurulum Oxidized ile konfigürasyon yedekleme yazısında anlatılıyor.

Uygulama planı şablonu: adım, beklenen sonuç, geri dönüş

İyi bir plan, değişikliği yazan mühendis dışında birinin de takip edebileceği netliktedir. Her adım için dört bilgi yazılır: ne yapılacak (tam komutlar), beklenen sonuç, nasıl doğrulanacak ve başarısız olursa nasıl geri alınacak. Aşağıda bir dağıtım switch’ine yeni VLAN ve SVI eklenmesi için örnek plan var:

Plana ayrıca etkilenen sistemler, değişikliğin tahmini süresi, geri dönüş için ayrılan süre ve geri dönüş kararının ölçütü eklenir (örneğin “adım 4 sonrası test istemcisi gateway’e erişemezse geri dön”). Ölçüt önceden yazılmazsa pencere içinde “biraz daha deneyelim” denir ve süre erir. Karar önceden verilir.

Uzaktan erişimi kaybetmemek: reload in, archive ve configure replace

Uzaktaki bir cihazda erişimi kesebilecek her değişiklikte otomatik bir geri dönüş mekanizması kurulur. Cisco IOS’ta en eski ve en basit yöntem zamanlanmış yeniden başlatmadır:

reload in 15
! değişiklikleri yap, KAYDETME
! erişim devam ediyorsa ve doğrulama tamamsa:
reload cancel
copy running-config startup-config

Mantık şu: değişiklik erişimi keserse cihaz 15 dakika sonra kayıtlı (değişiklik öncesi) konfigürasyonla açılır. Bu yüzden zamanlayıcı iptal edilmeden write memory yapılmaz. Kaydedilmemiş değişiklik varken reload in verildiğinde cihaz “System configuration has been modified. Save?” diye sorabilir; cevap no olmalıdır, aksi halde güvenlik ağı baştan devre dışı kalır. Refleksle “yes” yazmak sahada sık görülen bir hatadır. Yöntemin dezavantajı, geri dönüşün tam bir yeniden başlatma, yani kesinti olmasıdır.

Daha temiz yöntem, Cisco IOS’taki configuration archive ve rollback özellikleridir. Önce arşiv tanımlanır:

archive
 path flash:archive/$h-
 maximum 10
 write-memory
!
configure terminal revert timer 10
! değişiklikleri uygula
! her şey yolundaysa:
configure confirm

configure terminal revert timer ile girilen yapılandırma modunda yapılan değişiklikler, belirtilen süre içinde configure confirm verilmezse cihaz yeniden başlatılmadan arşivdeki önceki konfigürasyona döndürülür. Belirli bir arşiv dosyasına bilinçli olarak dönmek için configure replace flash:archive/<dosya> list kullanılır; list seçeneği uygulanan satırları gösterir. Platform ve sürüm desteğini kendi cihazınızın konfigürasyon kılavuzundan doğrulayın.

Diğer platformlardaki karşılıklar:

Bu mekanizmalara ek olarak kritik lokasyonlarda bağımsız bir out-of-band erişim yolu (konsol sunucusu, ayrı hat üzerinden yönetim) bulunur. Değişiklikten önce bu yolun gerçekten çalıştığı test edilir. Sahada sık karşılaştığımız durum, konsol sunucusunun ilk kez lazım olduğu gece çalışmadığının anlaşılmasıdır. Test edilmeyen yedek yol, yol değildir.

Bakım penceresi seçimi ve iletişim

Pencere seçimi teknik değil, işletme etkisine dayalı bir karardır. Üretim vardiyaları, muhasebe dönem sonu, yedekleme işlerinin saatleri ve veri replikasyon pencereleri kontrol edilir. Örneğin kurumsal ağ altyapısındaki bir değişikliğin gece yedekleme penceresine denk gelmesi, sabah “yedek alınamadı” alarmı olarak geri döner. Pencere süresi; uygulama, doğrulama ve geri dönüş sürelerinin toplamından kısa olamaz.

İletişim planında şunlar yer alır: etkilenecek kullanıcı grupları ve sistemler, beklenen etki (tam kesinti, kısa kesinti, etki beklenmiyor), değişikliği yapan ve karar veren kişiler, pencere sırasında ulaşılabilecek uygulama sahipleri ve gerekiyorsa operatör veya üretici destek iletişimi. Başlangıç, bitiş ve yapıldıysa geri dönüşün nedeni ilgili kanala yazılır.

Değişiklik sonrası doğrulama ve gözlem süresi

Doğrulama iki katmanlıdır. Teknik doğrulamada “önce” kaydındaki komut seti tekrar çalıştırılır; farklar yalnızca planlanan değişikliklerle açıklanabilmelidir. Komşuluk sayısı, bağlı port sayısı, port-channel üyeleri ve STP kökü aynı kalmalıdır. Fonksiyonel doğrulamada değişikliğin amacı test edilir: yeni VLAN’daki test istemcisi IP alıyor mu, gateway’e ve kritik sunuculara erişiyor mu, DNS çözümlüyor mu? Uygulama sahiplerinden alınan kısa bir onay, kullanıcı tarafındaki sorunları sabah mesai başlamadan yakalar.

Ardından bir gözlem süresi tanımlanır; bu sürede izleme sistemindeki arayüz hata sayaçları, CPU ve log mesajları takip edilir. Konfigürasyon kaydedilir, eski konfigürasyon arşivde tutulur ve değişiklik kaydı “önce/sonra” çıktılarıyla kapatılır. Yeni VLAN, IP veya port gibi bir bilgi değiştiyse kayıt kapatılmadan ağ dokümantasyonu güncellenir. Denetim tarafında değişiklik kaydında hangi kanıtların bulunması gerektiği değişiklik yönetimi denetim kanıtı rehberinde ele alınıyor.

Go/no-go kontrol listesi

Pencere başlamadan önce aşağıdaki maddelerin tamamı “evet” değilse değişiklik ertelenir. İstisna yok.

• Uygulama planı tam komutlarla yazılı ve ikinci bir mühendis tarafından gözden geçirildi mi?
• Her adımın doğrulama ve geri dönüş yöntemi tanımlı mı?
• Etkilenecek cihazların güncel konfigürasyon yedeği ve “önce” çıktıları alındı mı?
• Out-of-band veya konsol erişimi bu pencere için test edildi mi?
• Otomatik geri dönüş mekanizması (reload in, revert timer, commit confirmed) planda yer alıyor mu?
• Pencere süresi uygulama, doğrulama ve geri dönüş süresini karşılıyor mu?
• Etkilenen kullanıcılar ve uygulama sahipleri bilgilendirildi, pencere içinde ulaşılabilir mi?
• Çakışan başka bir değişiklik veya yedekleme işi yok mu?
• Firmware güncellemesi içeren değişikliklerde imaj doğrulaması ve yükseltme yolu kontrol edildi mi? (Ayrıntı için firmware güncelleme politikası.)

Kritik çekirdek veya WAN değişikliklerinin planlanması ve pencere içinde yürütülmesi için switch, router ve ağ cihazları kurulumu hizmetimizden; düzenli bakım değişikliklerinin aynı disiplinle yürütülmesi için ağ bakım, izleme ve periyodik kontrol hizmetimizden yararlanabilirsiniz.

Sık sorulan sorular

reload in komutu kullanırken en sık yapılan hata nedir?

Zamanlayıcı iptal edilmeden konfigürasyonun kaydedilmesi. Bu durumda zamanlanmış yeniden başlatma hatalı konfigürasyonla açılır ve güvenlik ağı işe yaramaz. Sıra her zaman aynıdır: önce reload cancel, sonra kayıt.

configure terminal revert timer ile reload in arasındaki fark nedir?

reload in, onay gelmezse cihazı yeniden başlatarak kayıtlı konfigürasyona döner ve kesinti yaratır. Revert timer ise archive özelliğini kullanır; onay verilmezse cihazı yeniden başlatmadan önceki konfigürasyona geri döndürür.

Her ağ değişikliği için bakım penceresi gerekir mi?

Hayır. Etkisi tek bir erişim portuyla sınırlı, geri dönüşü kolay standart değişiklikler önceden onaylı şablonlarla işletme saatlerinde yapılabilir. Trunk, yönlendirme, çekirdek ve firmware değişiklikleri pencere içinde ve geri dönüş planıyla yapılır.

Değişiklik sonrası gözlem süresi ne kadar olmalı?

Değişikliğin türüne bağlıdır. Etkisi hemen görülen değişikliklerde kısa bir süre yeterli olabilir; yönlendirme, QoS veya firmware gibi yüke ve zamana bağlı etkisi olan değişikliklerde en az bir tam iş günü gözlem önerilir.