Oxidized ile Switch ve Router Konfigürasyon Yedekleme ve Fark Takibi

Bir switch arızalanıp yerine yenisi takıldığında ya da hatalı bir değişiklik dağıtım katmanını erişilemez bıraktığında ilk soru şudur: Cihazın çalışan son yapılandırması nerede? Dosya sunucusunda tarihsiz duran, elle alınmış kopyalar bu soruya güvenilir cevap vermez. Aşağıda açık kaynak Oxidized ile switch, router ve firewall yapılandırmalarını otomatik ve Git ile sürümlü yedeklemeyi, değişiklik farklarını takip etmeyi ve yedekten geri yüklemeyi adım adım anlatıyoruz.

Konfigürasyon yedeği neden otomatik ve sürümlü olmalı?

Kurumsal ağ altyapısında konfigürasyon yedeği üç ayrı ihtiyaca cevap verir:

• Donanım değişimi: Arızalı cihazın yerine gelen cihaza son çalışan yapılandırmanın yüklenmesi.
• Hatalı değişikliğin geri alınması: “Dün çalışıyordu” denen durumda dünkü ile bugünkü yapılandırma arasındaki farkın satır satır görülmesi.
• Denetim ve izlenebilirlik: Hangi değişikliğin ne zaman yapıldığının değişiklik kayıtlarıyla karşılaştırılabilmesi.

Elle alınan yedek bunların yalnız ilkini karşılar; o da yedeğin güncel olduğu varsayımıyla. Sahada en sık karşılaştığımız durum, son elle yedeğin aylar öncesinden kalmış olmasıdır. Otomatik yedekleme güncelliği, Git ise geçmişi ve farkı sağlar. Hedef net: her cihazın yapılandırması belirli aralıklarla alınır, yalnız değiştiğinde yeni sürüm oluşur, her değişiklik bildirilir.

Oxidized mimarisi: kaynak, model, çıktı

Oxidized, Ruby ile yazılmış ve RANCID’e modern bir alternatif olarak geliştirilmiş bir araçtır (proje deposu). Mimarisi dört kavrama dayanır:

Aracın asıl değeri modeldedir. Model, her üretici için hangi komutların çalıştırılacağını (ör. Cisco IOS’ta show version, show inventory, show running-config) ve çıktıdaki değişken satırların (uptime, saat, “Current configuration : … bytes” gibi) nasıl temizleneceğini tanımlar. Bu temizlik olmasa her yedeklemede sahte fark çıkardı; böylece yalnız gerçek yapılandırma değişiklikleri yeni sürüm üretir. Oxidized ayrıca bir REST API ve isteğe bağlı web arayüzü (oxidized-web) sunar; LibreNMS gibi izleme platformları yapılandırmaları bu API üzerinden gösterebilir.

Kurulum ve router.db ile cihaz envanteri

Oxidized, Ruby gem olarak veya resmi Docker imajıyla kurulur. Gem kurulumunda dağıtıma göre derleme bağımlılıkları (Ruby geliştirme paketleri, libssh2, cmake gibi) gerekir; güncel listeyi proje dokümantasyonundan alın. Kurulumu ayrı bir servis kullanıcısıyla yapın:

useradd -m -s /bin/bash oxidized
gem install oxidized oxidized-web
su - oxidized -c "oxidized"   # ilk çalıştırma örnek yapılandırmayı oluşturur

İlk çalıştırmadan sonra ~/.config/oxidized/config dosyası düzenlenir. CSV kaynaklı ve Git çıktılı bir örnek:

---
username: oxidized-ro
password: "GizliParola"
model: ios
interval: 3600
threads: 20
timeout: 30
retries: 2
rest: 127.0.0.1:8888
vars:
  remove_secret: true
input:
  default: ssh
  ssh:
    secure: true
output:
  default: git
  git:
    single_repo: true
    user: Oxidized
    email: oxidized@ornek.local
    repo: "/home/oxidized/.config/oxidized/configs.git"
source:
  default: csv
  csv:
    file: "/home/oxidized/.config/oxidized/router.db"
    delimiter: !ruby/regexp /:/
    map:
      name: 0
      model: 1
      group: 2

router.db dosyasında her satır bir cihazdır; sütunlar yukarıdaki map tanımına göre okunur:

core-sw-01.ornek.local:ios:kampus
dist-sw-02.ornek.local:ios:kampus
dc-leaf-01.ornek.local:nxos:veri-merkezi
fw-01.ornek.local:fortios:guvenlik
sube-rtr-ankara.ornek.local:ios:sube

Cihaz adı yerine IP adresi de yazılabilir, ama DNS adı Git geçmişini okunur kılar. input.ssh.secure: true SSH host anahtarı doğrulamasını zorunlu tutar. Güvenli tercih budur; bedeli, cihaz değişiminde anahtarın known_hosts içinde güncellenmesidir. Unutulursa o cihazın yedeği sessizce durur. remove_secret: true parola ve anahtar satırlarını yedekten çıkarır; geri yüklemeye etkisi aşağıda. Cihaz listesini elle tutmak yerine envanter sisteminizden (ör. NetBox) veya izleme platformundan HTTP kaynağıyla çekin; liste ancak böyle güncel kalır.

Salt-okunur yedekleme hesabı ve cihaz tarafı ayarlar

Yedekleme hesabı yalnız okuma yapmalıdır. Tüm ağın yapılandırmasını hem okuyup hem değiştirebilen bir servis hesabı, saldırgan için en değerli hedeftir. Salt-okunur hesap tasarımı ise üreticiye göre değişir:

• Cisco IOS: Düşük yetki seviyesine show running-config atamak yetmez; komut bu seviyede yalnız kullanıcının yapılandırma yetkisi olan bölümleri gösterir ve eksik çıktı üretir. Pratikte en sağlam yöntem, hesaba seviye 15 verip TACACS+ komut yetkilendirmesiyle yalnız show ve terminal komutlarına izin vermektir. Çıktı eksiksiz gelir, yapılandırma komutları reddedilir.
• Juniper Junos: Bir login class ile view ve view-configuration yetkileri verilerek salt-okunur hesap tanımlanır.
• Firewall ve diğer platformlar: Çoğu üreticide salt-okunur yönetici profili bulunur; profilin yapılandırmanın tamamını görebildiğini pilotta doğrulayın.

Cihaz tarafında kontrol edilecekler: Oxidized sunucusu yönetim ağından SSH ile erişebiliyor mu, VTY ACL’lerinde sunucu adresine izin var mı, hesabın her girişi AAA ile loglanıyor mu? Yedekleme hesabının girişleri merkezi loglarda düzenli bir desen oluşturur. Bu desenin dışındaki giriş (farklı saat, farklı kaynak) incelenmelidir. Log toplama tarafı için merkezi syslog sunucusu kurulumu yazısına bakın.

Git çıktısı ile değişiklik farkı takibi ve bildirim

Git çıktısında her cihaz depoda bir dosyadır ve yalnız yapılandırma değiştiğinde yeni commit oluşur. Grup kullanıldığında Oxidized varsayılan olarak her grup için ayrı depo açar; örnekteki single_repo: true tüm grupları tek depoda, grup adlı alt klasörlerde tutar. Geçmişe bakmak için:

cd /home/oxidized/.config/oxidized
git --git-dir=configs.git log --oneline -- kampus/core-sw-01.ornek.local
git --git-dir=configs.git log -p -1 -- kampus/core-sw-01.ornek.local   # son değişikliğin farkı
# log çıktısından seçilen commit’teki sürümü dosyaya çıkarma
git --git-dir=configs.git show 3f2a9c1:kampus/core-sw-01.ornek.local > /tmp/core-sw-01-eski.cfg

Bildirim için Oxidized’ın hook mekanizması kullanılır. Örneğin yedekleme başarısız olduğunda bir betik çalıştırmak için yapılandırmaya şu bölüm eklenir:

hooks:
  yedek_hatasi:
    type: exec
    events: [node_fail]
    cmd: '/usr/local/bin/oxidized-bildir.sh'
    async: true

Betik, cihaz adını OX_NODE_NAME gibi ortam değişkenlerinden alıp e-posta veya sohbet kanalına bildirim gönderebilir. Değişiklik bildirimleri için post_store olayı kullanılır. En büyük risk sessiz başarısızlıktır. Hesabın parolası değiştiğinde ya da bir cihazın SSH erişimi kapandığında yedekleme durur, kimse fark etmez; arıza günü yedeğin üç ay önceden kaldığı anlaşılır. Bu yüzden “son başarılı yedek 48 saatten eski” kontrolünü REST API’den (/nodes.json) veya izleme platformundan düzenli çalıştırın.

Oxidized ve RANCID karşılaştırması

RANCID, uzun yıllardır kullanılan Perl ve Expect tabanlı bir konfigürasyon yedekleme aracıdır. İki araç aynı problemi çözer; işletim modelleri farklıdır:

RANCID’in yerleşik fark e-postası basit ortamlarda pratik bir avantajdır. Oxidized ise API’si, dinamik envanter kaynakları ve izleme platformu entegrasyonu sayesinde yeni kurulumlarda daha sık tercih edilir. Çalışan bir RANCID’i sırf yeni diye değiştirmeyin. Envanter entegrasyonu veya API ihtiyacı doğduğunda geçişi değerlendirin.

Yedekten geri yükleme ve doğrulama adımları

Yedek, geri yüklenebildiği kadar değerlidir. Adımlar Cisco IOS/IOS XE için verilmiştir; diğer platformlarda eşdeğer mekanizmalar kullanılır.

1. Doğru sürümü seçin: Git geçmişinden geri dönülecek commit’i belirleyin ve dosyayı çıkarın.
2. Sırları tamamlayın: remove_secret açıksa yedekte parolalar, SNMP community’leri ve anahtarlar yoktur. Bu değerleri parola kasasından ekleyin. SNMPv3 kullanıcıları zaten running-config’te bulunmaz, ayrıca tanımlanmaları gerekir; ayrıntılar SNMPv3 yapılandırma rehberinde.
3. Dosyayı cihaza aktarın: SCP ile flash’a kopyalayın (cihazda ip scp server enable gerekir).
4. Farkı önceden görün: show archive config differences flash:geri-yukle.cfg system:running-config ile değişecek satırları inceleyin.
5. Uygulayın: Yapılandırmanın tamamını değiştirmek için configure replace flash:geri-yukle.cfg kullanılır. Uzaktan çalışıyorsanız önce reload in 15 ile güvenlik zamanlayıcısı kurun, başarıdan sonra reload cancel ile iptal edin. Sırları tamamlanmamış bir dosyayla configure replace çalıştırmak cihazdaki parola ve anahtar satırlarını da siler. 2. adımı atlamayın.
6. Doğrulayın: Arayüz durumlarını, komşulukları (show cdp neighbors, yönlendirme komşulukları), VLAN ve trunk durumlarını önceden alınmış çıktılarla karşılaştırın; ardından write memory ile kalıcı hale getirin.

Donanım değişiminde yeni cihazın yazılım sürümünün yedeklenen yapılandırmayla uyumlu olduğunu da kontrol edin; arayüz adlandırması farklı bir modelde yapılandırma birebir uygulanamaz. Yılda en az bir kez test cihazına geri yükleme yaparak yedeklerin kullanılabilir olduğunu doğrulayın. Test edilmemiş yedek, yedek değildir. Planlı değişikliklerin yürütülmesi ve geri dönüş adımları için ağda değişiklik penceresi planlama yazısı tamamlayıcıdır.

Konfigürasyon yedekleme altyapısının izleme sistemiyle birlikte kurulması ağ bakım, izleme ve periyodik kontrol, cihaz yapılandırma standartlarının oluşturulması ise switch, router ve ağ cihazları kurulumu hizmeti kapsamındadır.

Sık sorulan sorular

Oxidized yapılandırmayı ne sıklıkla yedekler?

Yedekleme aralığı yapılandırmadaki interval parametresiyle saniye cinsinden belirlenir; örnekteki 3600 değeri saatte bir yedek alır. Yeni Git sürümü yalnız yapılandırma gerçekten değiştiğinde oluşur, bu yüzden sık yedekleme depoyu gereksiz büyütmez.

Yedekte parolaların bulunması güvenli mi?

remove_secret açıkken parola, community ve anahtar satırları yedekten çıkarılır. Güvenlik artar ama geri yüklemede sırları parola kasasından eklemeniz gerekir. Seçenek kapalıysa Git deposu en az cihazların kendisi kadar korunmalıdır.

Cisco’da salt-okunur yedekleme hesabı nasıl tanımlanır?

Düşük yetki seviyesine show running-config atamak eksik çıktı üretir. Daha sağlam yöntem, TACACS+ komut yetkilendirmesiyle hesabı yalnız show ve terminal komutlarıyla sınırlamaktır.

RANCID kullanıyorsak Oxidized’a geçmeli miyiz?

Çalışan bir RANCID kurulumunu yalnızca yenilemek için değiştirmek gerekmez. Dinamik envanter kaynağı, REST API veya izleme platformu entegrasyonu ihtiyacı doğduğunda Oxidized’a geçişi değerlendirin.