Bölüm 44: Ağ İzleme ve Yönetimi

Kararı denetleyici verdi. Ama o kararın tuttuğunu kimse ölçmediyse elde yalnızca bir varsayım var.

Paket geçti gitti. Geçtiği her cihaz onu bir sayaca ekledi ve o sayaçlar bir yere akıyor. Peki o sayacı kim okuyor?

İzlemek yönetimin yalnızca ilk adımı

Tek bir ağ, birbiriyle etkileşen binlerce donanım ve yazılım bileşeninden oluşur. Bu ölçekte hiçbir şey tek tek gözle izlenmez. Klasik tanım da izlemekle yetinmiyor; beş fiili birden sayıyor: izlemek, sınamak, yoklamak, yapılandırmak ve değerlendirmek.

Ağ yönetiminin mimarisi üç parçadan kurulur. En altta yönetilen cihaz durur: switch, router, erişim sunucusu, bridge, hatta sıradan bir bilgisayar. Onun üstünde bir yönetim ajanı çalışır. Ajan cihazın bilgilerini alır, saklar ve merkeze aktarır; merkezden gelen değişikliği de cihaza o uygular. Üçüncü parça merkezdeki yönetim sunucusudur ve soruyu o sorar.

Cihazdan toplanan veriyi üç türe ayırabilirsin. Yapılandırma verisi cihazın nasıl ayarlandığını söyler. İşletim verisi o an ne yaptığını söyler. Sayaçlar üçüncü kümede, cihaz istatistiklerinin içinde durur.

Operatörün önünde üç yol var. 41. bölümde komut satırından interface yapılandırmayı tek bir cihazda yaptın; aynı işi binlerce cihazda elle yapmak ölçeklenmiyor. İkinci yol, SNMP ile sayacı uzaktan sorgulamak ve değer yazmak. Üçüncüsü, NETCONF gibi protokollerle yapılandırmayı ağ genelinde yönetmek.

SNMP bir sayacı hangi adla sorar?

SNMP (Simple Network Management Protocol) bu mimarinin protokol karşılığıdır: ajan uygulama, yönetici uygulama ve ağ yönetim sistemi. Mesajları UDP taşır; ajan 161, trap dinleyen yönetici 162 numaralı portu kullanır. Ölçüm trafiğinin kendisi garantisiz bir taşımaya binmiş durumda ve bu bilinçli bir seçim: ağ sorunluyken TCP bağlantı kurmaya çalışırken takılabilir, tek bir UDP datagramı ise yine de gidebilir.

Bilgi iki kipte taşınır. İstek/yanıt kipinde sunucu sorar, cihaz cevaplar. Trap kipinde cihaz kimse sormadan kendi haber verir. Başlıca mesaj türleri şunlar:

Bu listenin içinde biri protokolün ne olduğunu değiştirir. SetRequest uzaktan bir değeri yazar; SNMP o anda okuma aracı olmaktan çıkar. Trap ise alarmın protokol düzeyindeki karşılığıdır.

Yazma yetkisi olan bir protokolün kimlik doğrulaması da olmalı; olmaması, SNMP’nin uzun süre taşıdığı yaranın kendisiydi. Sürümlerin tarihi bu tek sorunun etrafında dönüyor:

İlk iki sürümdeki topluluk dizesi teknik olarak bir paroladır ama pratikte bir paroladan beklenen hiçbir şeyi yapmaz: pakette düz metin gider, yani hattı dinleyen herkes okur. Üstüne bir de yaygın varsayılanları vardır: okuma için public, yazma için private. Bir ağ tarayıcısının ilk denediği şey bu iki kelimedir; SetRequest yetkisi veren bir dizeyi bulmak cihazı yeniden yapılandırma yetkisi bulmak demektir. İnternete açık bırakılmış public cihazların bir zararı daha var: küçük bir toplu okuma isteği büyük bir cevap ürettiği için saldırganlar onları, sahte kaynak adresli isteklerle kurbanı boğan yükselticiler olarak kullanıyor.

v3 üçünü birden getirdi: göndereni doğrulayan bir kimlik denetimi, mesajın kurcalanmadığını gösteren bir MIC (bütünlük kodu) ve isteğe bağlı şifreleme. Ayrıca tekrar oynatmayı engellemek için her cihazın bir açılış sayacı ve zaman damgası taşıması şart koşuldu.

Buna rağmen sahada hâlâ bol miktarda v2c çalışıyor, çünkü kurulumu kolay ve pek çok cihaz onunla geliyor. Pratik kural şu: SNMP trafiğini ayrı bir yönetim ağında tut ve SetRequest yetkisini gerçekten gerekmedikçe hiç açma.

Başlık da sabittir. PDU türü alanı mesajın hangi aileden geldiğini söyler; get ve set başlığında ayrıca Request ID, Error Status ve Error Index alanları durur.

get / set başlığı
+----------+------------+--------------+-------------+
| PDU türü | Request ID | Error Status | Error Index |
|  0 - 3   |            |    0 - 5     |             |
+----------+------------+--------------+-------------+

trap başlığı: PDU türü alanı burada 4 değerini taşır

Bir sayacın adresini veren şey ise MIB’dir. MIB, SNMP ile alınabilecek bilginin resmî tanımıdır: hangi sayacın hangi adla ve hangi anlamla durduğunu belge düzeyinde sabitler. Buradaki değişkenler noktalı bir sayı dizisiyle adlandırılır ve dizinin her basamağı ağacın bir dalına karşılık gelir.

1.3.6.1.2.1.7.1   →  udpInDatagrams

Bu kimliğin karşılığı, cihazın aldığı UDP datagramlarını sayan 32 bitlik bir alandır. Yazımı SMI adlı veri tanımlama diline dayanır. Dizinin başı tarihten geliyor: 1 ISO, 3 kuruluşlar, 6 ABD Savunma Bakanlığı, 1 internet. İnternetin bu ağaçtaki yeri hâlâ Savunma Bakanlığı’nın dalının altında.

RFC’lerde tanımlı 400’ü aşkın MIB modülü var ve üreticiye özgü olanların sayısı bundan çok daha fazla. Ethernet benzeri interface’lerin yönetilen nesneleri RFC 3635’te tanımlıdır. Switch’li ağlar için uzaktan izleme modülü ise RFC 2613’te durur ve SMON MIB adıyla anılır. Aynı sorgu böylece farklı markaların switch’lerinden aynı biçimde işletim bilgisi çeker: sıcaklık, bağlı kullanıcı sayısı, bağlantı hızı, cihazın çalışma süresi.

Yapamadığı da var. Bir Set tek cihaza tek değer yazar ve yarıda kalırsa geri alınmaz. NETCONF bir cihazın yapılandırma deposuna atomik commit yapabilir: ya değişikliğin tamamı uygulanır ya hiçbiri. Dikkat et, bu güvence tek cihazın içindedir; birden çok cihazı kapsayan dağıtık bir işlem NETCONF’un verdiği bir söz değil, üstteki düzenleme katmanının çözmesi gereken bir problem. Mesajları XML ile kodlanır ve güvenli bir taşıma üstünden uzak yordam çağrısı olarak gider. <lock> işlemi yapılandırma deposunu kilitler; o sırada başka bir oturum aynı yere yazamaz. YANG ise protokol değil, veri modelleme dilidir.

Bugünkü büyük ağlarda yön de tersine döndü. Sunucu sormayı bırakıyor; cihaz sayaçlarını saniyenin altına inen aralıklarla, YANG modellerine göre kendisi akıtıyor. Adı akış telemetrisi (streaming telemetry), en yaygın protokolü gNMI.

Sayaç kimin geçtiğini bilmez

Port başına paket saymak yararlı grafikler üretir. Ama sayaç ne kadar geçtiğini bilir, kimin nereye gittiğini bilmez.

Cevap flow kavramında. Bir flow; data link, network ve transport layer başlık alanlarının belli bir bileşimiyle tanımlanır. 43. bölümde flow kurallarını merkezî denetleyici yazıyordu; o kuralın yanında duran iki sayaç eşleşen paket ve bayt sayısını tutuyor. Kural birçok başlık alanına birden baktığı için sayacın hangi trafiği saydığı da o alanlarla tanımlanmış oluyor. Routing kararının kendisi ölçümü üretiyor.

Flow bilgisi toplamak için iki ayrı sistem geliştirildi. sFlow serbest lisanslı bir belirtim, NetFlow ise Cisco Systems’in protokolü. NetFlow zamanla IPFIX’e evrildi ve IETF standardı olarak geliştirildi. İkisinin felsefesi farklı: sFlow her N paketten birini örnekleyip başlığını hemen gönderiyor, NetFlow ise cihazın içinde flow’ları biriktirip flow bitince özetini yolluyor.

Flow izleme geçen paketleri flow kaydına çevirir. Kayıt paketin kendisini taşımaz, flow’un özetini taşır. Kapasite planlaması bunun en sıkıcı kullanımı. Asıl değeri, olağandışı trafiği ve başka türlü görünmeyecek saldırı trafiğini fark ettirmesinde.

Switch bu protokolleri desteklemiyorsa trafik dışarıdan alınır. Ayna port bir ya da birkaç portun trafiğini kopyalayıp tek bir porta verir. Oraya bağlanan analizör trafiğin kendisini görür, sayacını değil. Büyük bir üreticideki adı SPAN portudur. Standartlaşmış bir özellik de değildir: yetenek ve sınırlar üreticiye göre değişir, bazıları aynalanan trafiği ağ üstünden uzak bir alıcıya bile gönderir.

Fiber hatlarda ikinci bir yol var. Optik ayırıcı (TAP) ışığın kopyasını çıkarır ve dışarıdaki bir makineye verir. Üçüncüsü prob: bir switch portuna takılır ve sürekli karışık modda çalışarak geçen trafiğin istatistiğini üretir.

Eşik olmadan veri bilgi olmaz

Bir ölçüm sisteminin ilk kararı zaman ölçeğidir. Birçok analizör yükü varsayılan olarak 1 saniyelik ortalamayla gösterir. Bu kısa bir pencere gibi durur ama değildir. Sonuna kadar dolu bir 10 Mbit/s Ethernet kanalı o saniyede kuramsal olarak 14.880 frame taşır. Gigabit Ethernet 1.488.000 frame’e çıkar, tam 100 kat. 100 Gbit/s sistemde sayı 148.800.000 olur.

İzlenmesi gereken asgari küme üç kalemden ibaret: port kullanım oranı, broadcast ve multicast hızı, bir de CRC hatası gibi temel hata istatistikleri. Hata sayacı, sorun yaşayan cihazı adres vermeden işaret eder.

Klasik kılavuzlar aşırı yük eşiklerini şöyle koyar: sekiz saatlik iş günü ortalamasında %20, günün en yoğun saatinde %30, on beş dakikalık ortalamalarda %50. Bu sınırlar paylaşılan Ethernet günlerinden kalma ve bugünkü switch’li ağlar için temkinli; yine de mantıkları geçerli. Onları önce switch’leri çekirdeğe bağlayan upstream portlarında izlersin; darboğaz oradadır. 40. bölümde kuyruk trafiğin ortalamasıyla değil değişkenliğiyle büyüyordu; eşikler o değişkenliği yakalamak için farklı pencerelere konur.

Çok sayıda switch’ten düzenli istatistik toplayıp hepsine tek tek bakmayı denersen veride boğulursun. Toplamak kolay, yorumlamak zor. Bazı üreticiler bunun için sağlık raporu üretir ve yalnızca yeterince ciddi hata görülen cihazları listeler. Eşik, veriyi bilgiye çeviren şeydir.

Arıza tespiti ayrı bir hattan yürür. Sistem cihazlara düzenli aralıklarla yoklama paketi yollar; cihaz belli sayıda denemeden sonra cevap vermezse düştü işaretlenir ve haber verilir. IP ağlarında en basit biçimi ping’dir: yankı isteği gider, kaç tanesinin döndüğü sayılır. Cihazın kendi olay mesajları ise syslog olarak akar; logging buffered bellekte tutar, show logging gösterir, logging <host> başka bir makineye yollar.

Aynı fikri kendi makinende de görebilirsin. netstat komutu TCP/IP bağlantılarını, gönderilen ve alınan paket ayrıntılarını, routing tablosunu ve interface istatistiklerini basar. Windows’ta netstat -e interface sayaçlarını verir:

C:\> netstat -e
Interface Statistics

                           Received            Sent

Bytes                    3176407056      1960446992
Unicast packets            15058536         4590630
Non-unicast packets           57006          134256
Discards                          0               0
Errors                            0               0
Unknown protocols                 0

Bu tablo bir switch portunun küçük kopyası. MRTG, aynı sayaçları SNMP ile yoklayıp tarayıcıda görülebilen grafiklere çeviren eski ve yaygın bir yazılım; bugün aynı işi çoğu zaman Prometheus ile Grafana ikilisi yapıyor. iperf ise ters yönde çalışır: ağı yüksek veri hızıyla zorlayan aktif bir sınayıcıdır. Wireshark ise canlı trafiği ya da kaydedilmiş bir pcap dosyasını okuyup istatistik çıkarır. Sayaç düzeyinde bakmakla paket düzeyinde bakmak birbirinin yerine geçmez, tamamlar.

Özet

• Ağ yönetimi izlemekten geniştir: sınamak, yoklamak, yapılandırmak ve değerlendirmek aynı işin fiilleridir; mimari de yönetilen cihaz, ajan ve sunucudan kurulur.
• SNMP sayaçlara ortak bir ad verir: MIB hangi değerin hangi nesne kimliğiyle duracağını sabitler, bu yüzden aynı sorgu farklı markalardan aynı bilgiyi çeker.
• Trap alarmın protokol karşılığıdır: olağandışı olayı ajan kendi başlatır ve SetRequest protokolü okumanın yanında bir yazma aracına çevirir.
• Flow izleme sayacın söyleyemediğini söyler: kayıt paketi taşımaz, flow’un özetini taşır ve trafiğin neyden oluştuğunu görünür kılar.
• Eşik veriyi bilgiye çevirir: ham grafik tek başına bir şey söylemez, anlamı hangi pencerede hangi oranın aşıldığına konan sınır üretir.

Buraya kadar ölçülen her şey tek bir yönetimin altındaydı: sayaçlar aynı merkeze aktı, eşiği de alarmı da aynı ekip yönetti. Bu ağdaki herkes birbirine güveniyor; peki paket bu sınırdan çıktığında ne o güven kalıyor ne de ortak bir harita; yolunu neye bakarak seçiyor?