Bu yazı Kurumsal WiFi serisinin bir parçasıdır.

Kurumsal kablosuz ağa yeni misiniz? Genel bakışla başlayın: Kurumsal WiFi Mimarisi: Standartlardan Deployment’a

Pazarlama Sayılarının Sorunu

Her WiFi nesli etkileyici teorik verim rakamlarıyla gelir. 802.11ac 3,5 Gbps vaat etti. 802.11ax 9,6 Gbps vaat ediyor. Pratikte, gerçek bir ortamdaki tek bir istemci WiFi 5’te nadiren 400–600 Mbps’i ve WiFi 6’da 800 Mbps–1,2 Gbps’i aşar.

Bu bir aldatmaca değildir — ideal koşullar altında teorik hızlar matematiksel olarak doğrudur. Teori ile pratik arasındaki boşluk şundan kaynaklanır:

• Teorik hızlar, aynı anda maksimum kanal genişliği (160 MHz), maksimum uzamsal akış (8) ve maksimum modülasyon (1024-QAM) varsayar
• Gerçek istemcilerin 8 değil, 1–2 uzamsal akışı vardır
• Kanal genişliği, düzenleyici kurallar ve girişimden kaçınma ile sınırlıdır
• Sinyal zayıflaması, artan mesafeyle birlikte modülasyonu daha düşük hızlara düşürür

Kurumsal kablosuz seçiminde gerçekte önemli olan, zirve verim değildir — standardın yük altında, yoğun istemci ortamlarında ve tıkalı RF koşullarında nasıl davrandığıdır. Nesiller gerçekte burada farklılaşır.

802.11n (WiFi 4): Temel

2009’da yayınlandı. Temel olmaya devam eden iki teknolojiyi tanıttı:

MIMO (Multiple Input, Multiple Output): Hem AP’de hem de istemcide birden fazla anten, aynı kanalda eş zamanlı olarak iletim ve alım yapar. 2×2 MIMO AP, 2 verici ve 2 alıcı anten kullanarak tek antenli (SISO) tasarımlara kıyasla verimi etkili biçimde ikiye katlar. Kurumsal AP’ler yaygın olarak 3×3 veya 4×4 MIMO kullanır.

5 GHz desteği: 802.11n hem 2,4 GHz hem de 5 GHz üzerinde çalışan ilk standarttır. 5 GHz bandı, daha fazla örtüşmeyen kanala sahiptir (çoğu bölgede 2,4 GHz’deki 3’e karşılık 25) ve komşu ağlardan ve mikrodalga fırınlardan daha az girişim yaşar.

Kanal bağlama: 40 MHz kanallar (iki 20 MHz kanalın bağlanması), kanal kullanılabilirliği pahasına teorik verimi ikiye katladı.

2026’daki pratik gerçeklik: 802.11n donanımı kullanım ömrünü tamamlamış. Herhangi bir yeni deployment, en azından 802.11ac kullanmalıdır. 802.11n’yi anlamak, birçok kurumsal ortamda hâlâ mevcut olan eski cihazları yönetmek için önemlidir.

802.11ac (WiFi 5): 5 GHz’e Geçiş

2013’te (Wave 1), 2016’da (Wave 2) yayınlandı. 802.11n üzerinde önemli iyileştirmeler:

Yalnızca 5 GHz: 802.11ac yalnızca 5 GHz üzerinde çalışır. Bu, 2,4 GHz bandını eski/IoT kullanımına zorlayarak yüksek verimli istemcileri daha az tıkalı 5 GHz spektrumuna taşıdı.

Daha geniş kanallar: 80 MHz kanallar (Wave 1) ve 160 MHz kanallar (Wave 2). 80 MHz kanal, 20 MHz kanalın yaklaşık 4× veri hızını sağlar — ancak 4× spektrum tüketir. Çok sayıda AP’li yoğun deployment’larda, 80 MHz kanallar ciddi aynı kanal girişimine neden olur. Birçok kurumsal deployment, kanal kullanılabilirliğini korumak için 40 MHz kullanır.

256-QAM: 802.11n’nin 64-QAM’inden daha yüksek modülasyon yoğunluğu. Aynı sinyal gücünde sembol başına daha fazla bit — ancak daha iyi sinyal kalitesi gerektirir.

MU-MIMO (Wave 2): 802.11ac Wave 2, çok kullanıcılı MIMO‘yu aşağı yön için tanıttı. Bir seferde tek bir istemciye iletmek (SU-MIMO) yerine, AP farklı istemcilere yönlendirilmiş farklı destekler kullanarak aynı anda 4 istemciye iletim yapabilir.

MU-MIMO sınırlılığı: Wave 2 MU-MIMO yalnızca aşağı yönde (AP’den istemciye) çalışır. Yukarı yön (istemciden AP’ye) hâlâ tek kullanıcılıdır. İstemcilerin MU-MIMO’nun etkili çalışması için uzamsal olarak farklı konumlarda olması gerekir — pratikte fayda genellikle teorikten daha az dramatiktir.

Pratik etki: WiFi 5, en yaygın deploy edilen kurumsal standart olmaya devam ediyor. 2016 ile 2021 arasında deploy edilen kurumsal AP’lerin çoğu 802.11ac Wave 2’dir. Tipik ofis iş yükleri için performans mükemmeldir.

802.11ax (WiFi 6): Yoğunluk İçin Tasarlandı

2019’da yayınlandı. WiFi 6, öncelikle daha hızlı tek istemci verimi değil — yüksek yoğunluklu ortamlarda verimlilik hedefledi. Bu temel ayrımdır.

OFDMA: En Önemli WiFi 6 Özelliği

802.11n ve 802.11ac’da kanal, bir seferde bir istemciye tahsis edilir. Bir istemcinin yalnızca küçük bir onaylama göndermesi gerekmesi durumunda bile, diğer istemciler beklerken kanalı tutar:

WiFi 5 (OFDM — zaman bölmesi):
  Zaman: |─ İstemci A ─|─ İstemci B ─|─ İstemci C ─|─ İstemci A ─|
  Kanal: Bir seferde bir istemciye %100 tahsis edilmiş

WiFi 6, LTE/5G hücresel ağdan ödünç alınan OFDMA‘yı (Orthogonal Frequency Division Multiple Access) tanıttı. Kanal, Kaynak Birimleri (RU) adı verilen alt kanallara bölünür ve birden fazla istemci farklı RU’larda eş zamanlı olarak hizmet alabilir:

WiFi 6 (OFDMA — frekans + zaman bölmesi):
  Zaman: |─────────── Tek TXOP ────────────|
         | İstemci A | İstemci B | İstemci C |
         | (küçük)   | (küçük)   | (büyük veri) |
  Kanal: birden fazla istemci arasında eş zamanlı olarak alt bölünmüş

Neden pratikte önemlidir:

• IoT cihazları, telefonlar ve tabletler sık sık küçük paketler gönderir (onaylamalar, yaşatma mesajları, sensör verileri). WiFi 5 altında, bu küçük iletimlerin her biri tam kanalı tutar.
• OFDMA, AP’nin bu küçük iletimleri bir araya getirerek, tek bir WiFi 5 iletiminin alacağı sürede birden fazla istemciye hizmet vermesine olanak tanır.
• Yoğun ortamlarda (konferans odaları, sınıflar, açık ofisler), bu, kanal tıkanmasını önemli ölçüde azaltır ve tüm istemciler için genel verimi iyileştirir.

OFDMA, WiFi 5’in yalnızca aşağı yön MU-MIMO’sunun aksine, WiFi 6’da hem aşağı yöne hem de yukarı yöne uygulanır.

BSS Boyama: Aynı Kanal Girişimini Azaltma

Yoğun AP deployment’larında, komşu AP’ler çoğunlukla kanalları paylaşır. 802.11n/ac altında, bir istemci cihazı kanalında etkinlik algıladığında beklemek zorundadır — o etkinlik kesinlikle girişim yapamayacak bitişik binalardaki bir AP’den gelse bile.

WiFi 6 BSS Boyama, her Temel Servis Setine bir “renk” (sayısal etiket) atar. Cihazlar, kendi BSS’lerinden gelen iletimler ile aynı kanalı paylaşan diğer BSS’lerden gelen iletimler arasında ayrım yapabilir:

BSS Boyama olmadan:
  İstemci AP-1'i duyar (kendi ağı) → bekler
  İstemci AP-2'yi duyar (komşu)    → da bekler (gereksiz)

BSS Boyama ile:
  İstemci AP-1'i duyar (aynı renk)     → bekler (ilgili)
  İstemci AP-2'yi duyar (farklı renk, düşük RSSI) → iletim yapar (yeniden kullanım)

Pratikte, BSS Boyama yoğun deployment’larda uzamsal yeniden kullanımı iyileştirir — daha fazla AP, aşırı girişime neden olmadan örtüşen kanallarda çalışabilir.

Target Wake Time (TWT): IoT Pil Ömrü

WiFi 6, AP’lerin IoT ve pil güçlü cihazlar için belirli uyanma zamanları planlamasına olanak tanıyan TWT’yi tanıttı. Cihazlar, veri bekleyerek radyolarını sürekli aktif tutmak yerine, yalnızca planlanan aralıklarda uyuyup uyanır.

Kurumsal ilgi: Binalar, WiFi bağlantılı sensörleri, kameraları, erişim kontrol okuyucularını ve varlık takip etiketlerini giderek artan oranda bünyesinde barındırıyor. TWT, bu cihazların işlevselliğini etkilemeden pil ömrünü dramatik biçimde uzatır.

1024-QAM ve Daha Yüksek Verim

WiFi 6, 1024-QAM (WiFi 5’in 256-QAM’ına karşılık) destekler — sembol başına 8 bit yerine 10 bit kodlar. Yakın mesafede mükemmel sinyal kalitesiyle yaklaşık %25 verim iyileştirmesi. Çoğu deployment için OFDMA’dan daha az önemli.

802.11ax (WiFi 6E): 6 GHz Bandı

WiFi 6E, 6 GHz bandına (çoğu bölgede 5,925–7,125 GHz) genişletilmiş 802.11ax’tır. 6 GHz bandı şunları sağlar:

• 1.200 MHz yeni spektrum — 5 GHz’de mevcut 500 MHz’e kıyasla
• 59’a kadar örtüşmeyen 20 MHz kanalı — 5 GHz’de 25’e karşılık (bölgeye bağlı)
• Eski cihaz yok: 6 GHz bandı yalnızca WiFi 6E/7. 802.11n veya 802.11ac cihazı orada yok. Eski protokollerden girişim yok.
• Tıkanma olmadan geniş kanallar: 160 MHz kanallar, 5 GHz’de neden oldukları kanal tükenmesi olmadan 6 GHz’de pratiktir.

Sınırlılık: 6 GHz, daha yüksek frekans zayıflaması nedeniyle 5 GHz’den daha kısa menzile sahiptir. AP’lerin istemcilere yakın olduğu yüksek yoğunluklu iç mekân ortamları için mükemmeldir. Açık hava veya uzun menzilli deployment’lar için daha az kullanışlıdır.

İstemci benimsenmesi: WiFi 6E yetenekli istemciler (akıllı telefonlar, dizüstü bilgisayarlar) 2026 itibarıyla giderek daha yaygın hale geliyor. 6E destekli kurumsal AP’ler tipik olarak üç bantlı çalışır: 2,4 GHz (eski), 5 GHz (ana akım) ve 6 GHz (yüksek verim, düşük tıkanıklık).

802.11be (WiFi 7): Ortaya Çıkıyor

802.11be / WiFi 7, 2024’te tamamlandı ve 2026 itibarıyla erken kurumsal deployment aşamasında. Temel yenilikler:

Çok Bağlantılı Çalışma (MLO): Tek bir istemci bağlantısı aynı anda birden fazla bant ve kanalı kullanabilir — örneğin 5 GHz ve 6 GHz üzerinde eş zamanlı iletim. Bu, verim toplamayı iyileştirir ve bağlantı kesilmesi olmadan bantlar arasında kesintisiz roaming sağlar.

320 MHz kanallar: 6 GHz’de mevcut. WiFi 6E’nin 160 MHz maksimumunun kanal genişliğini ikiye katlar.

4096-QAM: Mükemmel sinyal koşulları gerektiren daha yüksek modülasyon. Yakın mesafede 1024-QAM üzerinde yaklaşık %20 verim iyileştirmesi.

Kurumsal hazırlık: WiFi 7 AP’ler Cisco, Aruba ve diğerlerinden temin edilebilir. İstemci desteği büyüyor ancak henüz evrensel değil. Yeni deployment’lar için WiFi 7 AP’ler, WiFi 5 ve WiFi 6 istemcilerle uyumlu kalırken altyapıyı geleceğe hazırlar.

Kanal Planlaması: Teori Gerçeklikle Buluşuyor

Standartları anlamak yalnızca yarı resimdir. Kanalları nasıl yapılandırdığınız, WiFi 6 deployment’ınızın WiFi 5 deployment’ınızı geride bırakıp bırakmayacağını belirler.

2,4 GHz: Yalnızca 3 Kullanılabilir Kanal

Çoğu bölgede 2,4 GHz’in 14 kanalı tanımlı ancak yalnızca 3 örtüşmeyen kanalı var (kanal 1, 6, 11). Kanal 2, 3, 4, 5 üzerindeki herhangi bir AP, kanal 1 ve 6 ile kısmen örtüşür — girişime neden olur.

Yoğun deployment’larda 2,4 GHz bandı, yüksek verimli istemciler için esasen kullanılamaz. Eski cihazlar ve IoT için ayırın ve yetenekli istemcileri 5 GHz veya 6 GHz’e yönlendirin.

5 GHz: Kanal Genişliği Takasları

5 GHz, 25 örtüşmeyen 20 MHz kanala sahiptir (bölgeye bağlı). Kanal genişlikleri:

20 MHz kanallar:   25 örtüşmeyen kanal mevcut
40 MHz kanallar:   12 örtüşmeyen kanal
80 MHz kanallar:    6 örtüşmeyen kanal
160 MHz kanallar:   3 örtüşmeyen kanal

Bir kampüsü kapsayan 20 AP’li bir deployment’da, 80 MHz kanallar kullanmak yalnızca 6 benzersiz kanalın mevcut olduğu anlamına gelir — her AP, komşusunun da kullandığı bir kanaldadır. Aynı kanal girişimi performansı düşürür.

Kurumsal öneri: Yoğun deployment’larda, kanal kullanılabilirliğini korumak için 5 GHz’de 40 MHz kanallar kullanın. 80 MHz+‘yı düşük yoğunluklu alanlar veya spektrumun bol olduğu 6 GHz için ayırın.

Otomatik Kanal Ataması (ACA)

Kurumsal controller’lar (Cisco RRM, Aruba ARM), RF ortamı ölçümlerine dayalı olarak kanalları otomatik olarak atar ve iletim gücünü ayarlar. Bu, genellikle başlangıç deployment’ı için güvenilirdir, ancak deployment sonrası survey ile doğrulanmalıdır — otomatik algoritmalar bazen karmaşık RF ortamlarında suboptimal seçimler yapar.

Deployment’ınız İçin Doğru Standardı Seçme

Önemli not: WiFi 6 AP’ler tüm önceki istemcileri destekler — 802.11n, 802.11ac, 802.11ax istemcilerin tamamı aynı AP’ye bağlanır. AP, her istemciyle karşılıklı desteklenen en iyi yetenekleri müzakere eder.

Temel Çıkarımlar

• Pazarlama verim rakamları pratikte elde edilemez — standartları zirve hızlarına değil, yoğunluk ve verimlilik iyileştirmelerine göre değerlendirin.
• OFDMA, kurumsal deployment’lar için WiFi 6’nın en etkili yeniliğidir — kanalın yüksek yoğunluklu ortamlarda nasıl paylaşıldığını dönüştürür.
• BSS Boyama, komşu AP’ler arasındaki gereksiz kanal çakışmasını azaltır.
• WiFi 6E’nin 6 GHz bandı, tıkanmamış spektrum ve pratik geniş kanallar sağlar — yoğun iç mekân ortamları için en önemli deployment iyileştirmesi.
• Kanal genişliği planlaması, standart kadar önemlidir — 5 GHz’deki 160 MHz kanallar, yoğun deployment’larda genellikle yardımdan çok zarar verir.
• WiFi 7 / 802.11be MLO’yu tanıtıyor ve erken deployment aşamasında — yeni altyapı yatırımları için değerlendirmeye değer.

Bu Seri

• 📖 Kurumsal WiFi Mimarisi Genel Bakış ← Buradan başlayın
• 🏢 Kurumsal Controller Mimarisi: Cisco ve Aruba
• 🏨 KOBİ, Oteller ve Muayenehane İçin WiFi Tasarımı
• 🔐 WiFi Güvenliği: WPA3, 802.1X, Sahte AP, Site Survey

İlgili Yazılar

• 🔐 802.1X Kimlik Tabanlı Mimari Sahada — Kablosuz güvenlik için kimlik katmanı
• 🏗️ IT Altyapısı Ürünler Koleksiyonu Değildir — Kablosuz tasarım için sistem düşüncesi

Bu yazı Kurumsal WiFi serisinin bir parçasıdır.

Kurumsal kablosuz ağa yeni misiniz? Genel bakışla başlayın: Kurumsal WiFi Mimarisi: Standartlardan Deployment’a

Ortam Türü Neden Ekipman Markasından Daha Önemlidir

Herhangi bir büyük satıcının WiFi 6 AP’si, bir laboratuvarda WiFi 5 AP’sini geride bırakır. Gerçek bir binada, iyi bir deployment ile başarısız bir deployment arasındaki farkın AP donanımıyla neredeyse hiçbir ilgisi yoktur — ortama özgü tasarım kararlarına bağlıdır.

Otelin gereksinimleri, muayenehaneden temel olarak farklıdır. Lojistik deposu, bir hukuk bürosundan tamamen farklı bir yaklaşım gerektirir. AP yalnızca bir radyodur — tasarım, ortamına hizmet edip etmediğini belirler.

Bu yazı, belirli tasarım desenleri, yaygın hatalar ve gerçek deployment’lardan saha notlarıyla üç yaygın deployment senaryosunu ele alır.

Bölüm 1: KOBİ WiFi Tasarımı

“Sadece Erişim Noktası Ekle” Tuzağı

En yaygın KOBİ WiFi başarısızlığı: biri internet kapsama haritalarına dayanarak iki ya da üç AP kurar, “WiFi her yerde var” diye raporlar ve üç ay sonra herkes WiFi’nin yavaş olduğundan şikayet eder.

Neredeyse her zaman kök nedenler:

• Kabloların çalıştırılmasının kolay olduğu yerlere AP yerleştirme, kapsama alanının gerekli olduğu yerlere değil
• Kullanılabilir veri hızlarında çok büyük bir alanı kapsamaya çalışan tek AP (sinyal gücü ≠ verim)
• Band yönlendirme yok — eski telefonlar ve yazıcılar 2,4 GHz’i monopolize ediyor
• QoS yok — tek bir kullanıcının dosya yedeklemesi, 10 diğer kullanıcının beklediği bant genişliğini tüketiyor
• Misafir/personel ayrımı yok — misafirler kurumsal ağda

KOBİ İçin Kapsama Planlaması

Tipik ofis ortamları için kaba bir başlangıç noktası:

Bunlar başlangıç noktaları, kural değil. Kapsama alanını doğrulamanın tek yolu site survey — deployment öncesi tahmine dayalı, sonrasında doğrulama.

Ağ Segmentasyonu Taban Çizgisi

Her KOBİ deployment’ı en azından üç VLAN’a eşlenen üç SSID’ye sahip olmalıdır:

SSID: ŞirketAğı     → VLAN 10 (kurumsal cihazlar, tam LAN erişimi)
SSID: MisafirWiFi    → VLAN 20 (yalnızca internet, VLAN 10'dan izole)
SSID: IoT/Yazıcılar  → VLAN 30 (yazıcılar, kameralar, izole)

Misafir VLAN’ı firewall ile zorunlu kılınan izolasyon olmalıdır — aralarında firewall olmadan yalnızca farklı alt ağ değil. Misafir cihaz internet’e ulaşabilmeli ve başka hiçbir şeye ulaşamamalıdır. Firewall kuralı açıktır: VLAN 20 → yalnızca internet, VLAN 20 → VLAN 10 reddet.

Band Yönlendirme ve QoS

KOBİ ortamlarında band yönlendirme: AP’leri mümkün olduğunda istemcileri 5 GHz’e yönlendirecek şekilde yapılandırın. Modern iş dizüstü bilgisayarları ve telefonların çoğu 5 GHz’e yeteneklidir. Yazıcılar ve eski IoT cihazları çoğunlukla yalnızca 2,4 GHz’i destekler — onları özel IoT SSID’sine yerleştirmek, diğer kullanıcıları etkilemeden bunu yönetir.

KOBİ için temel QoS:

• VoIP/video trafiğini işaretleyin veya önceliklendirin (ses için DSCP EF, video için AF41)
• Misafir VLAN’ında kullanıcı başına bant genişliği sınırları belirleyin (örn. cihaz başına 10 Mbps indirme / 5 Mbps yükleme)
• AP platformunuz destekliyorsa uygulama farkında QoS’u değerlendirin (Meraki, Aruba)

KOBİ İçin Platform Önerisi

Bölüm 2: Otel WiFi Tasarımı

Otel WiFi Zorluğu

Oteller, en zorlu WiFi ortamlarından biridir:

• Yüksek cihaz yoğunluğu: Her misafir odası 3–5 cihaza sahip (telefon, dizüstü, tablet, akıllı TV, akıllı saat). 200 odalı bir otel, yoğun kullanım döneminde 600–1000 istemci cihaza sahiptir.
• Değişken talep: Kullanım; check-in, akşam yemeği sonrası ve sabahın ilk saatlerinde zirveye çıkar — gündüz çok düşük kullanımla. Ağ, ortalama yükü değil, zirve yükü karşılamalıdır.
• Gelir bağımlılığı: “WiFi çalışmıyor”, otel incelemelerinde en çok şikayet edilen konudur. Kötü WiFi, misafir memnuniyeti puanlarını doğrudan etkiler.
• Karma teknik yeterlilik: Ağ, hem bir teknoloji yöneticisi hem de tatile gelen bir gezgin için sorunsuz çalışmalıdır.

AP Yerleşimi: Koridor veya Oda İçi

İki temelden farklı yaklaşım:

Koridor AP’leri:

• Koridorlara monte AP’ler, odaları duvarların arasından kapsıyor
• Daha az AP sayısı, daha düşük kurulum maliyeti
• Sinyal, misafirlere ulaşmak için 2–3 duvar geçmek zorunda
• Bitişik odaları kapsayan koridor AP’leri arasında aynı kanal girişimi

Oda İçi AP’ler:

• Her odada veya diğer her odada AP
• Daha fazla AP sayısı ve kurulum maliyeti
• Mükemmel sinyal kalitesi (AP istemciyle aynı odada)
• Odalar arasında daha iyi izolasyon (daha az girişim)
• Daha karmaşık kablolama

Saha deneyimi: Beton duvarlar ve metal çerçeveli odalara sahip modern otel yapısında, koridor AP’leri şaşırtıcı derecede kötü kapsama sağlayabilir — duvarlar 5 GHz sinyallerini önemli ölçüde zayıflatır. Oda içi veya diğer oda AP yerleşimi tipik olarak dramatik biçimde daha iyi misafir deneyimi sunar. Mevcut kablolama ile tadilat projelerinde, WiFi 6 ve dikkatli kanal planlamasıyla koridor AP’leri çoğunlukla pragmatik seçimdir.

Bant Genişliği Yönetimi: En Kritik Otel Özelliği

Kullanıcı başına bant genişliği yönetimi olmadan, üç cihazda 4K video izleyen bir misafir, 20 diğer misafirin beklediği bant genişliğini tüketir. Misafir deneyimi tamamen aynı anda çevrimiçi olan kişilere bağlı hale gelir.

Kurumsal otel WiFi controller’ları kullanıcı ve cihaz başına hız sınırlamasını destekler:

Misafir SSID Politikası:
  Cihaz başına indirme sınırı:  25 Mbps
  Cihaz başına yükleme sınırı:  10 Mbps
  Oda başına maksimum:          75 Mbps (3 cihaz × 25 Mbps)

Bu sınırlar, tipik kullanımda kullanıcılar fark etmeden adilliği sağlar — cihaz başına 25 Mbps, HD video akışı, video görüşmeler ve normal tarama için yeterlidir. 4K akışı 15–25 Mbps gerektirir, hâlâ sınır içinde.

Premium WiFi kademeleri (ek ücretli) daha yüksek sınırlara sahip olabilir:

Standart Misafir:  Cihaz başına 25 Mbps
Premium Misafir:   Cihaz başına 50 Mbps
Kurumsal VLAN:     Sınırsız (personel ağı)

Misafir Portalı ve Kimlik Doğrulama

Otel misafir portalları üç işleve hizmet eder: tanımlama, şartlar kabul ve süre yönetimi.

Yaygın kimlik doğrulama modelleri:

• Açık kayıt: Misafir ad ve e-posta girer, şartları kabul eder, erişim alır. Basit, personel müdahalesi yok.
• Oda numarası doğrulama: Misafir oda numarası girer (ve isteğe bağlı olarak soyad). Aktif rezervasyonu doğrulamak için PMS ile entegre olur.
• Kupon tabanlı: Resepsiyon kupon kodu sağlar. Günlük ziyaretçiler, konferans katılımcıları için kullanışlı.

PMS (Otel Yönetim Sistemi) entegrasyonu, oteller için profesyonel standarttır. WiFi sistemi, oda numarasının dolu olduğunu ve rezervasyonun aktif olduğunu doğrulamak için PMS’yi sorgular. Check-out’ta misafirin WiFi erişimi otomatik olarak iptal edilir. Manuel müdahale gerekmez.

WiFi entegrasyonlu yaygın PMS sistemleri: Opera, Protel, Mews, Cloudbeds — tümü büyük WiFi platformları için belgelenmiş entegrasyon API’lerine sahiptir (Aruba, Cisco, Ruckus).

Otellerde Ağ Segmentasyonu

SSID: OtelMisafir    → VLAN 100 (yalnızca internet, hız sınırlı)
SSID: OtelPremium    → VLAN 101 (internet, daha yüksek hız sınırı)
SSID: OtelPersonel   → VLAN 200 (kurumsal LAN, PMS erişimi)
SSID: OtelArkaOfis   → VLAN 300 (yönetim sistemleri, POS)
SSID: OtelIOT        → VLAN 400 (TV'ler, termostatlar, kilitler)

Firewall kuralları: Misafir VLAN’ları (100, 101) → yalnızca internet. Personel VLAN’ı (200) → LAN + internet. Misafir ve personel ağları arasında katı izolasyon — istisna yok.

Konferans ve Etkinlik WiFi’si

Konferans tesisi olan oteller ayrı bir zorlukla karşı karşıyadır: 200’den fazla kişinin cihazlarıyla bir odada olduğu etkinlikler için geçici yüksek yoğunluk deployment’ları.

Geçici taşınabilir AP’ler, bu etkinlikler için kalıcı kapsama alanını destekleyebilir — ancak etkinlik sırasında değil, etkinlikten önce önceden yapılandırılmış ve test edilmiş olmalıdır. Beklenen istemci sayısı ve kullanım desenleri için (hafif tarama, video akışı veya sunum araçları) etkinlik organizatörüyle koordine edin.

Bölüm 3: Muayenehane WiFi Tasarımı

Sağlık Hizmetlerine Özgü Gereksinimler

Muayenehanelerin, tipik KOBİ değerlendirmelerinin ötesine geçen WiFi gereksinimleri vardır:

Cihaz çeşitliliği: Klinik ortamlar alışılmadık bir cihaz karışımına sahiptir — kurumsal ağdaki HP dizüstü bilgisayarlar, EHR erişimi için iPad’ler, tıbbi cihazlar (infüzyon pompaları, hasta monitörleri, taşınabilir görüntüleme ekipmanı), misafir WiFi’sindeki hasta akıllı telefonları ve bina yönetim sistemleri.

Uyumluluk: ABD’de HIPAA (Sağlık Sigortası Taşınabilirlik ve Hesap Verebilirlik Yasası) — ve Almanya’da (DSGVO) ve AB’de eşdeğer düzenlemeler — hasta sağlık bilgilerinin (PHI) aktarım sırasında korunmasını gerektirir. PHI taşıyan ağlar için WiFi güçlü şifreleme kullanmalıdır (WPA2-Enterprise veya WPA3). Misafir WiFi’si, klinik ağlardan tamamen izole edilmelidir.

Erişilebilirlik: Klinik iş akışları ağ erişimine bağlıdır. Yoğun bir muayenehanede başarısız WiFi ağı gerçek operasyonel aksamaya neden olur — doktorlar hasta kayıtlarına erişemez, EHR sistemleri zaman aşımına uğrar ve personel kağıt çözümlerine başvurur.

Muayenehaneler İçin Ağ Segmentasyonu

SSID: KlinikPersonel  → VLAN 10  (EHR, klinik uygulamalar, tam erişim, WPA2-Enterprise)
SSID: TibbiCihazlar   → VLAN 20  (tıbbi cihazlar, izole, WPA2-PSK)
SSID: HastaWiFi       → VLAN 30  (yalnızca internet, tamamen izole)
SSID: BinaYönetimi    → VLAN 40  (HVAC, erişim kontrolü, izole)

Tıbbi cihaz VLAN’ı (VLAN 20) özellikle önemlidir. Birçok tıbbi cihaz dahili olarak şifresiz protokoller kullanır — genel personel veya hasta cihazlarıyla hiçbir zaman ağ segmentini paylaşmamalıdır.

Tıbbi Cihaz Değerlendirmeleri

WiFi’ye bağlı tıbbi cihazlar çoğunlukla alışılmadık özelliklere sahiptir:

• Eski işletim sistemleri: Bazı tıbbi cihazlar gömülü Windows XP veya Windows 7 çalıştırır. Güncellenemezler. Klinik kullanım için ağa erişilebilir olmaları gerekir ancak her şeyden izole edilmelidir.
• Statik IP’ler: Pek çok tıbbi cihaz, DHCP yerine statik IP atamaları gerektirir. Bunları dikkatli biçimde belgeleyin.
• Frekans duyarlılığı: Bazı eski tıbbi cihazlar yalnızca 2,4 GHz’de çalışır ve 5 GHz’e yetenekli değildir.
• Düzenleyici sertifikasyon: WiFi’li tıbbi cihazlar, üreticilerinin sertifikalandırdığı şekilde kullanılmalıdır. WiFi ağını cihaz bağlantısını etkileyen biçimlerde değiştirmek sertifikasyonu geçersiz kılabilir ve uyumluluk yükümlülüğü yaratabilir. Değişiklikleri her zaman cihaz üreticisiyle doğrulayın.

HIPAA Kablosuz Uyum Kontrol Listesi

ABD muayenehaneleri için (HIPAA) — ve AB için eşdeğer (DSGVO):

• ✅ Klinik ağlarda WPA2-Enterprise veya WPA3-Enterprise (bireysel kullanıcı kimlik bilgileri, paylaşılan PSK değil)
• ✅ Klinik VLAN, misafir/hasta WiFi’sinden tamamen izole
• ✅ Klinik ağlardaki kablosuz trafik aktarım sırasında şifreli
• ✅ Kablosuz controller’da sahte AP tespiti etkin
• ✅ Kimlik doğrulama logları saklanıyor (kim bağlandı, ne zaman, nereden)
• ✅ Tıbbi cihaz ağı, klinik ve misafir VLAN’larından izole
• ✅ Misafir WiFi hizmet şartları belgelenmiş

Tüm Ortamlarda Yaygın Hatalar

1. Site survey yapmama RF ölçümü olmadan kat planlarına dayanarak AP yerleşimi planlamak tahmindir. Duvarlar, mobilyalar, ekipmanlar ve komşu ağlar tümü kapsama alanını kat planlarının yakalayamayacağı biçimlerde etkiler. Kurulumdan önce her zaman tahmine dayalı survey, sonrasında doğrulama survey yapın.

2. Profesyonel ortamlarda tüketici ekipmanı kullanma Tüketici AP’leri (WiFi’li ev router’ları), band yönlendirmeden, uygun roaming desteğinden, kullanıcı başına QoS’tan, VLAN segmentasyonundan ve yönetim görünürlüğünden yoksundur. Başlangıçta çalışıyor gibi görünür ve yük altında veya zamanla sınırlarını ortaya koyarlar.

3. VLAN segmentasyonu olmadan deployment Kurumsal cihazlarla aynı ağda misafir cihazlar, gerçekleşmeyi bekleyen bir güvenlik başarısızlığıdır. Bu, profesyonel ortamlarda isteğe bağlı değildir.

4. İzleme yok Gecenin ortasında yeniden başlayan AP, bir hafta boyunca yanlış AP’ye bağlı kalan istemci, girişime neden olan kanal değişikliği — bunların hiçbiri kablosuz izleme olmadan görünür değildir. AP kullanılabilirliği, istemci sayısı anomalileri ve kanal kullanımı için uyarılar kurun.

5. Power over Ethernet (PoE) planlamasını görmezden gelme Kurumsal AP’ler PoE gerektirir. Birden fazla radyolu bir Cisco veya Aruba WiFi 6 AP, 20–25 watt çeker. Tüm portlar 25W sağlayan 48 portlu bir switch, switch’in toplam PoE bütçesini aşar. Donanım satın almadan önce PoE kapasitesini planlayın.

Temel Çıkarımlar

• WiFi tasarımı ortama özgüdür. Otel için tasarım desenleri temel olarak ofisten farklıdır; bu da muayenehaneden farklıdır.
• Kullanıcı başına bant genişliği yönetimi, konaklama ortamlarında pazarlık konusu değildir — onsuz adillik imkânsızdır.
• PMS entegrasyonu, otellerde personel müdahalesi olmadan misafir erişim yaşam döngüsünü otomatikleştirir.
• VLAN segmentasyonu, her profesyonel ortam için taban çizgisidir — misafir, kurumsal, IoT ve yönetim ağları izole edilmelidir.
• Tıbbi cihaz WiFi’si özel yönetim gerektirir — eski işletim sistemi, statik IP’ler, düzenleyici sertifikasyon kısıtlamaları.
• Site survey isteğe bağlı değildir — deployment’ın güvenilmeden önce çalışacağını doğrulamanın tek yoludur.

Bu Seri

• 📖 Kurumsal WiFi Mimarisi Genel Bakış ← Buradan başlayın
• 📡 802.11 Standartları Deep Dive
• 🏢 Kurumsal Controller Mimarisi: Cisco ve Aruba
• 🔐 WiFi Güvenliği: WPA3, 802.1X, Sahte AP, Site Survey

İlgili Yazılar

• 📡 NAS Yedekleme ve AWS S3 — KOBİ’ler için Veri Güvenliği — WiFi’nin yanında KOBİ veri koruma
• 🔐 802.1X Kimlik Tabanlı Mimari Sahada — Kurumsal kablosuz için kimlik katmanı
• 🏗️ IT Altyapısı Ürünler Koleksiyonu Değildir — Ağ tasarımında sistem düşüncesi

Bu yazı F5 BIG-IP serisinin bir parçasıdır.

F5’e yeni misiniz? Önce platform genel bakışıyla başlayın: F5 BIG-IP Bir Load Balancer Değil — Uygulama Teslim Platformudur

Büyük resmi zaten anlıyorsanız ve WAF’a derinlemesine inmek istiyorsanız — güvenlik modelleri, OWASP kapsamı, bot savunması ve deployment stratejisi — doğru yerdesiniz.

WAF Nereye Oturur — Nereye Oturmaz

En yaygın yanlış anlama: “Firewall’umuz var, uygulama katmanında korunuyoruz.”

Yeni nesil bir firewall, bazı L7 protokol farkındalığıyla L3/L4’te çalışır. Port taramalarını, bilinen kötü IP’leri, C2 iletişimini ve açık metin protokollerindeki tanınan exploit’leri engeller. Ancak bir HTTPS POST isteğinin gövdesini inceleyip username alanının ' OR 1=1 -- içerip içermediğini belirleyemez.

WAF’ın doldurduğu boşluk budur:

NGFW:  IP filtreleme, port kuralları, VPN, stateful inspection, protokol anomalisi
WAF:   HTTP/HTTPS içerik incelemesi — SQL injection, XSS, parametre tampering,
       bot trafiği, credential stuffing, uygulama katmanı DoS

F5 WAF, LTM virtual server’ı üzerinde inline çalışır. Trafik LTM’nin full proxy’sinden geçer, SSL sonlandırılır ve ardından WAF backend’e ulaşmadan önce şifresi çözülmüş içeriği inceler. Bu konumlama temel avantajdır — WAF, istemciden başlayarak şifrelenmiş trafik dahil her şeyi görür.

ASM ve Advanced WAF Karşılaştırması

F5, BIG-IP’te iki WAF katmanı sunar:

ASM (Application Security Manager) — orijinal modül. Öncelikle imza tabanlı. OWASP Top 10, parametre zorunluluğu, çerez koruması ve temel bot tespitini kapsar. Birçok standart BIG-IP lisansına dahildir.

Advanced WAF (AWAF) — ASM’nin sahip olmadığı davranışsal yeteneklere sahip yeni modül:

Dahili kurumsal uygulamalar için ASM sağlam kapsam sağlar. Yüksek bot maruziyeti, credential stuffing riski veya agresif L7 DoS olan kamuya açık uygulamalar için Advanced WAF önemli ölçüde daha etkilidir.

Güvenlik Politikası Modelleri

Negatif Güvenlik Modeli (Kara Liste Yaklaşımı)

Bilinen kötü kalıpları engelle. Geri kalanına izin ver.

F5 WAF, bilinen exploit kalıplarıyla eşleşen binlerce saldırı imzasıyla gelir:

İmza: SQL Injection (Genel)
  Saldırı Türü:  SQL Injection
  Risk:          Kritik
  Kalıp:         SELECT...FROM, INSERT...INTO, OR 1=1, vb. ile eşleşir

Bir istek bir imzayla eşleştiğinde, WAF onu engeller (engelleme modunda) veya loglar (şeffaf modda).

Avantajlar: Hızlı deployment, düşük başlangıç yanlış pozitifi, bilinen güvenlik açıkları için iyi kapsam.

Dezavantajlar: Tanım gereği sıfır-gün saldırılarını tespit edemez. Kararlı saldırganlar bazen kodlama varyasyonları veya parçalanmış payload’lar aracılığıyla imzaları atlayabilir.

Pozitif Güvenlik Modeli (Beyaz Liste Yaklaşımı)

Yalnızca açıkça tanımlanmış girdilere izin ver. Geri kalanını engelle.

Pozitif güvenlikte, uygulamanızın tam olarak neyi kabul ettiğini tanımlarsınız:

Parametre: username
  Tür:         Alfanümerik
  Maks Uzunluk: 64
  Zorunlu:     Evet

Parametre: user_id
  Tür:         Tamsayı
  Min Değer:   1
  Maks Değer:  999999

username=admin' OR 1=1-- içeren bir istek engellenir çünkü tek tırnak ve boşluklar Alfanümerik karakter setinde değildir. Saldırgan, katı bir beyaz listeyi atlayacak bir payload hazırlayamaz.

Avantajlar: Sıfır-gün ve bilinmeyen saldırı varyantlarını engeller. İmza eşleştirmesinden temel olarak daha güçlü.

Dezavantajlar: Önemli ayarlama çabası gerektirir. Karmaşık, dinamik parametre setlerine sahip uygulamaları doğru biçimde modellemek zordur. Başlangıçta yüksek yanlış pozitif oranı.

Hibrit Model: Üretim Ortamlarının Gerçekte Kullandığı

Çoğu üretim deployment’ı bir kombinasyon kullanır:

• Uygulamanın büyük bölümü için negatif model — düşük bakım yüküyle imzalar
• Yüksek riskli endpoint’ler için pozitif model — kimlik doğrulama, ödeme işleme, ayarlama yatırımının değerini kanıtladığı yönetim fonksiyonları

Saldırı İmzaları: Yönetim ve Güncellemeler

F5, saldırı kategorisi ve uygulama platformuna göre düzenlenmiş imzalarla gelir:

İmza Setleri:
  Genel Tespit İmzaları (SQL Injection, XSS, Komut Enjeksiyonu)
  Apache Struts İmzaları
  WordPress / Joomla İmzaları
  CVE'ye özgü imzalar (hedeflenmiş exploit payload'ları)
  Yüksek Doğruluk İmzaları (minimum yanlış pozitif için ayarlanmış)

F5 düzenli olarak imza güncellemeleri yayınlar. Güncel olmayan imzalar, son açıklanan güvenlik açıklarına karşı WAF etkinliğini önemli ölçüde azaltır.

İmza staging’i — yeni imzalar zorunluluktan önce staging moduna alınmalıdır:

Yeni İmza Durumu: Staging
  Davranış: İhlalleri logla, engelleme
  Amaç:     Zorunluluğu etkinleştirmeden önce yanlış pozitif olmadığını doğrula
  Süre:     Minimum 1–2 hafta üretim trafiği gözlemi

Staging, yeni imzaları üretim kullanıcılarını etkilemeden önce uygulamanıza özgü trafik karşısında doğrulamanıza olanak tanır.

OWASP Top 10 Kapsamı

F5 WAF, imzalar ve politika zorunluluğunun kombinasyonu aracılığıyla tüm on OWASP Top 10 kategorisini ele alır:

A01 — Kırık Erişim Kontrolü: URL erişim kalıplarını zorla, yetkisiz kaynaklardan yönetim yollarına yönelik istekleri engelle.

A02 — Kriptografik Hatalar: Yanıtlarda hassas veri kalıplarını tespit et (kredi kartı numaraları, SSN’ler); kazara açığa çıkmayı engelle.

A03 — Enjeksiyon (SQL, Komut, LDAP, XSS): İmza tespitinin birincil gücü. Tüm enjeksiyon türlerinde enjeksiyon payload’larını özellikle hedef alan yüzlerce imza.

A04 — Güvensiz Tasarım: Beklenen uygulama akışlarını zorla; tanımlı gezinme yolları dışındaki URL’lere zorla gezinmeyi engelle.

A05 — Güvenlik Yanlış Yapılandırması: Varsayılan yönetici arayüzlerine, yedek dosyalara, yapılandırma endpoint’lerine ve sürüm ifşa sayfalarına erişimi tespit et ve engelle.

A06 — Savunmasız Bileşenler: Popüler framework’lerdeki bilinen CVE’ler için imza kapsamı (Apache Struts, Spring, Log4j, vb.).

A07 — Kimlik Doğrulama Hataları: Advanced WAF, credential stuffing koruması ekler — otomatik kimlik bilgisi test saldırılarını tespit edip hız sınırlar.

A08 — Yazılım ve Veri Bütünlüğü Hataları: Sınırlı doğrudan WAF kapsamı — öncelikle bir uygulama tasarımı endişesi. WAF, seri kaldırma işlemini kullanan bazı enjeksiyon girişimlerini tespit edebilir.

A09 — Loglama ve İzleme Hataları: WAF, merkezi görünürlük için SIEM’e entegre olan ayrıntılı istek loglama ve ihlal takibi sağlar.

A10 — SSRF (Sunucu Tarafı İstek Sahteciliği): İmzalar, istek parametrelerindeki ve başlıklardaki yaygın SSRF kalıplarıyla eşleşir.

Bot Savunması (Advanced WAF)

İnternet trafiğinin önemli bir bölümü otomatiktir. Tüm botlar kötü niyetli değildir — arama motoru tarayıcıları, izleme sistemleri ve RSS okuyucuları meşrudur. Advanced WAF’ın bot savunması bunları birbirinden ayırır.

Tespit Katmanları

İmza tabanlı bot tespiti: Bilinen bot User-Agent dizelerini F5’in bot veritabanıyla eşleştir. Hızlı ama User-Agent başlığını değiştirerek kolayca atlanabilir.

JavaScript challenge: Yanıta şeffaf bir JavaScript challenge’ı ekle. Meşru tarayıcılar bunu sessizce yürütür; JavaScript render etmeyen temel botlar challenge’ı başarısız geçer. Yalnızca imza eşleştirmesinden önemli ölçüde daha etkili.

CAPTCHA challenge: JS challenge’ı başarısız geçen veya şüpheli kalıplarla eşleşen trafik için bir CAPTCHA sun. İkincil challenge olarak kullanılır — birincil savunma olarak değil (normal trafik için çok rahatsız edici).

Davranışsal analiz: Zaman içinde istek kalıplarını izle. /api/auth/login‘e saniyede 500 istek yapan bir istemci neredeyse kesinlikle bir bottur — JavaScript challenge’ını geçip geçmediğinden bağımsız olarak.

Tarayıcı parmak izi: Advanced WAF, gerçek tarayıcıları baş olmayan otomasyon araçlarından (Puppeteer, Playwright, Selenium) ayırt etmek için tarayıcı özelliklerini toplar (canvas render, JavaScript motor zamanlaması, TCP/TLS parmak izi).

Bot Kategorileri ve Yanıtları

Bot Kategorisi         Yanıt
────────────────────────────────────────
Arama motorları        İzin ver (DNS ters arama ile doğrulanmış)
İzleme araçları        İzin ver (IP ile beyaz listeye alınmış)
Bilinmeyen botlar      JS challenge
Şüpheli botlar         CAPTCHA challenge
Bilinen kötü niyetli   Hemen engelle
Credential stuffers    Engelle + uyar

L7 DoS Koruması

Katman 7 DoS saldırıları büyük trafik hacmine ihtiyaç duymaz. Yavaş bir endpoint’i hedef alan az sayıda istek, sunucu kaynaklarını tüketebilir:

Saldırı örneği:
  /reports/generate?type=full adresine 100 eş zamanlı istek
  Her biri 30 saniyelik bir veritabanı sorgusu tetikler
  Veritabanı CPU → %100
  Diğer tüm kullanıcılar: zaman aşımları
  Tüketilen ağ bant genişliği: minimal
  Geleneksel DDoS tespiti: olağandışı bir şey görmez

Advanced WAF’ın L7 DoS tespiti:

Stres tabanlı tespit: Backend sunucu yanıt gecikmesini birincil sinyal olarak izler. Gecikme temel seviyenin üzerine çıktığında WAF otomatik olarak hız sınırlaması uygular. Bu uyarlanabilirdir — yalnızca istek hacmi eşiklerine değil, gerçek sunucu stresine yanıt verir.

TPS tabanlı tespit: Kaynak IP başına veya URL başına saniyedeki istek sınırlarını zorlar.

Davranışsal temel: Zaman içinde URL başına normal trafik kalıplarını öğrenir. Bir URL öğrenilen temel çizgisinden önemli ölçüde saptığında otomatik uyarı — normalde dakikada 20 istek alan bir URL’nin aniden 5.000 alması, mutlak sayılardan bağımsız olarak anormaldir.

Deployment Stratejisi: Şeffaftan Engellemeye Geçiş

En yaygın WAF deployment başarısızlığı, doğrudan engelleme moduna geçmektir. Engelleme modundaki her yanlış pozitif meşru bir kullanıcının iş akışını bozar, helpdesk ticket’ı üretir ve WAF değerini kanıtlamadan önce organizasyonel güveni yok eder.

Doğru yaklaşım her zaman aşamalıdır:

Faz 1 — Şeffaf Mod (1–4. Haftalar)

Zorunluluk Modu: Şeffaf
İhlalde eylem: Yalnızca logla — engelleme yok

Deploy edin ve toplayın. İhlal loglarını her gün gözden geçirin. Şunları tespit edin:

• İmzaları tetikleyen meşru uygulama davranışı (yanlış pozitifler)
• Tespit edilen gerçek saldırılar (doğru pozitifler)
• Her uygulama parametresi için tipik değerler ve kalıplar

Faz 2 — Politika Ayarlama (2–6. Haftalar, Faz 1 ile çakışıyor)

Şeffaf mod verilerine dayanarak politikayı ayarlayın:

Onaylanan yanlış pozitifler için istisnalar ekleyin:

Parametre: search_query
  İzin ver: Özel karakterler (%, *, ?)
  Neden: Uygulama meşru olarak joker karakter arama operatörlerini kabul ediyor

Sorunlu imzaları devre dışı bırakmak yerine staging’e alın:

İmza: XSS Genel (bu uygulama için yüksek yanlış pozitif oranı)
  Durum: Staging → logla ama engelleme
  Gözden geçir: 2 ek hafta veri sonrasında

Kritik endpoint’ler için pozitif güvenlik kuralları oluşturun:

URL: /api/auth/login
  username  → Alfanümerik, maks 64 karakter
  password  → Herhangi, maks 128 karakter, değeri asla loglama
  mfa_code  → Yalnızca sayısal, tam olarak 6 karakter

Faz 3 — Seçici Engelleme (6. Hafta+)

Engelleme modunu kademeli olarak etkinleştirin — en yüksek güvenilirlikli imzalarla başlayın:

Zorunluluk Modu: Engelleme
Yüksek güvenilirlikli imzalar: Engelle
Orta güvenilirlikli imzalar: Yalnızca alarm (logla + uyar, engelleme yok)
Yeni/yakın zamanda eklenen imzalar: Staging

Bu, şeffaftan engellemeye geçişte bir yanlış pozitif dalgasını önler. İmzaları güven arttıkça şu hattı izleyerek ilerletin: Staging → Alarm → Engelleme.

Faz 4 — Süregelen Bakım

WAF bir kere ayarla unut aracı değildir:

• Aylık: F5 imza güncellemelerini uygula; staging’deki yeni imzaları gözden geçir
• Her uygulama deployment’ında: Yeni parametreler, URL’ler veya değişen uygulama davranışı için WAF politikasını güncelle
• Haftalık: İhlal log eğilimlerini gözden geçir; ani artışları ve yeni saldırı kalıplarını araştır
• Üç aylık: Tam yanlış pozitif denetimi; bayatlamış istisnaları kaldır; bot trafik eğilimlerini gözden geçir

Loglama ve SIEM Entegrasyonu

WAF, her ihlal için ayrıntılı loglar üretir — olay müdahalesi, uyumluluk ve tehdit istihbaratı için gerekli:

Zaman Damgası:      2026-03-14 09:23:41 UTC
İstemci IP:         203.0.113.42
İstek:              POST /api/auth/login HTTP/1.1
İhlal Edilen Param: username
İhlal:              SQL Injection
Eşleşen İmza:       200000007 (SQL Injection Generic)
Saldırı Türü:       SQL Injection
Önem Derecesi:      Kritik
Eylem:              Engellendi
Destek ID:          12345678901234

Bankacılık ortamında WAF logları Splunk’a iletildi:

• SOC tarafından görülebilen gerçek zamanlı saldırı panoları
• Firewall ve IPS olaylarıyla korelasyon — aynı anda WAF ihlallerini VE IPS alarmlarını tetikleyen bir IP yüksek önceliklidir
• Kritik önem dereceli ihlaller için otomatik çağrı
• Aylık PCI DSS uyumluluk raporlaması

Temel Çıkarımlar

• WAF L7’de korur — NGFW’lerin uygulamaya özgü saldırılar için etkili biçimde inceleyemediği katman.
• ASM standart kurumsal ihtiyaçları karşılar. Advanced WAF, bot maruziyeti, credential stuffing riski veya L7 DoS tehditlerine sahip kamuya açık uygulamalar için haklı kılınır.
• Hiçbir zaman doğrudan engelleme moduna gitmeyin. Şeffaf → ayarlama → seçici engelleme → tam engelleme, tek güvenilir yoldur.
• Negatif model hızlı deploy edilir. Pozitif model daha güçlüdür ancak önemli ayarlama yatırımı gerektirir — yüksek riskli endpoint’lere seçici olarak uygulayın.
• WAF süregelen bakım gerektirir — imza güncellemeleri, uygulama değiştiğinde politika değişiklikleri, düzenli yanlış pozitif gözden geçirme.
• SIEM entegrasyonu WAF’ı bir engelleme aracından tüm güvenlik operasyon fonksiyonu için bir istihbarat kaynağına dönüştürür.

Bu Seri

• 📖 F5 BIG-IP Platform Genel Bakış — Tüm Modüller ← F5’e yeniyseniz buradan başlayın
• 🔧 F5 LTM Deep Dive
• 🌐 F5 GTM ve GSLB Deep Dive

İlgili Yazılar

• 🔐 Zero Trust Zihniyeti: Güvenliği Bir Mimari Olarak Mühendislemek — WAF’ın Zero Trust’taki yeri
• 🛡️ 802.1X Kimlik Tabanlı Mimari Sahada — Ağ katmanlarında derinlemesine savunma
• 📊 İzleme Doğru Yapıldığında — WAF loglarını proaktif izlemeye entegre etmek
• 🛡️ Network Packet Broker (NPB) Masterclass — WAF ile birlikte tam trafik görünürlüğü

Bu yazı Kurumsal WiFi serisinin bir parçasıdır.

Kurumsal kablosuz ağa yeni misiniz? Genel bakışla başlayın: Kurumsal WiFi Mimarisi: Standartlardan Deployment’a

Controller Mimarisi Neden Önemli

Bir erişim noktası yalnızca bir radyo vericisidir. Onu kurumsal bir ağın parçası yapan — tutarlı politika, kesintisiz roaming, merkezi yönetim ve güvenlik entegrasyonu ile — arkasındaki controller mimarisiddir.

Controller mimarisini yanlış kurarsanız şunları elde edersiniz:

• Binalar veya katlar arasında roaming başarısızlıkları
• Farklı AP gruplarında tutarsız güvenlik politikaları
• İstemci bağlantılarını yavaşlatan kimlik doğrulama darboğazları
• Rutin değişiklikleri çok adımlı operasyonlara dönüştüren yönetim karmaşıklığı

Doğru kurarsanız, kablosuz ağ kablolu altyapının bir uzantısı gibi davranır — tutarlı, yönetilebilir ve kimlik ve güvenlik sistemleriyle entegre.

Üç Mimari Model

Model 1: Merkezi Controller (Geleneksel)

Tüm zeka controller’da bulunur. AP’ler “ince"dir — RF iletir ve tüm trafiği controller’a yönlendirir:

[AP] ──CAPWAP veri tüneli──→ [WLC] → Çekirdek Switch → Ağ
[AP] ──CAPWAP veri tüneli──→ [WLC]
[AP] ──CAPWAP veri tüneli──→ [WLC]

CAPWAP (Control and Provisioning of Wireless Access Points), AP’ler ile controller arasındaki protokoldür. Şunları taşır:

• Kontrol düzlemi: AP kaydı, yapılandırma, RF yönetimi, roaming kararları
• Veri düzlemi: İstemci trafiği (merkezi modda, tüm istemci verisi controller’dan geçer)

Avantajlar:

• Tüm istemciler ve trafik üzerinde merkezi görünürlük
• Controller alanı içinde kesintisiz roaming — istemci durumu controller’da kalır, AP’de değil
• Tutarlı politika uygulaması — her istemci aynı controller’dan geçer

Dezavantajlar:

• WLC tek hata noktasıdır (HA çifti gerektirir)
• Trafik hairpin gecikme ve controller bant genişliği tüketimi ekler
• Ölçeklendirme controller kapasitesi eklemeyi gerektirir

Kullanıldığı yer: Şirket içi altyapıya sahip büyük kampüs deployment’ları, yerel trafik kontrolü gerektiren düzenlenmiş ortamlar.

Model 2: Dağıtık / FlexConnect

Controller’ın yapılandırma ve politikayı yönettiği, ancak istemci veri trafiğinin AP’de veya şube switch’inde yerel olarak anahtarlandığı hibrit bir model:

Merkezi Site:               Şube Sitesi:
[WLC]                       [AP FlexConnect] ──yerel switch──→ LAN
  │                          │
  └──WAN──────────yalnızca CAPWAP kontrolü──

FlexConnect modunda, AP şubede mevcut olan VLAN’lar için yerel anahtarlama yapar. WAN bağlantısı başarısız olursa, istemciler yerel kaynaklara erişmeye devam edebilir — AP önbelleğe alınmış yapılandırmayla bağımsız modda çalışır.

Kullanıldığı yer: Tüm trafiği genel merkeze yönlendirmenin pratik olmayacağı, merkezi bir WLC’ye WAN üzerinden bağlı şube ofisleri.

Model 3: Bulut Yönetimli

Yönetim ve yapılandırma bir bulut platformu tarafından yönetilir. Veri trafiği doğrudan yerel ağa gider — hairpin yok:

[AP] ──veri──→ Yerel switch → Ağ (doğrudan, controller hairpin yok)
[AP] ──yönetim tüneli──→ Bulut Panosu (yapılandırma, izleme)

AP’ler yapılandırma ve telemetri için bulutla iletişim kurar, ancak istemci verisi asla yerel ağı terk etmez. Bulut bağlantısı kesilirse, AP’ler son bilinen yapılandırmalarıyla çalışmaya devam eder.

Kullanıldığı yer: Her sitede özel ağ personeli olmayan çok siteli organizasyonlar, KOBİ ortamları, perakende zincirleri, konaklama.

Cisco Kablosuz Mimarisi

Geleneksel: Cisco WLC + Lightweight AP’ler

Klasik Cisco kurumsal kablosuz mimarisi:

• Cisco WLC (Wireless LAN Controller): Donanım cihazları (9800 serisi, eski 5508, 8540) veya sanal (C9800-CL). Modele bağlı olarak binlerce AP’ye kadar yönetir.
• Lightweight AP’ler (LWAPP/CAPWAP): CAPWAP modunda çalışan Cisco Catalyst ve Aironet AP’ler.

HA yapılandırması: WLC çiftleri, Stateful Switchover (SSO) ile Aktif-Yedek modunda çalışır. İstemci oturumları yedek WLC’ye yansıtılır — failover istemcilere şeffaftır.

WLC-Birincil (Aktif)  ←── HA bağlantısı ──→  WLC-İkincil (Yedek)
       │                                              │
    [AP'ler]                                       [AP'ler]

Mobilite Grubu: Aynı kampüsteki birden fazla WLC, Mobilite Grubu oluşturur — istemciler, farklı WLC’ler tarafından yönetilen AP’ler arasında kesintisiz Katman 2 veya Katman 3 mobilitesiyle dolaşabilir.

Modern: Cisco DNA Center + Catalyst Center

Cisco’nun mevcut kurumsal platformu:

• Catalyst Center (eski adıyla DNA Center): Yönetim, otomasyon ve güvence platformu. Özel donanım cihazları üzerinde çalışır.
• SD-Access: Cisco’nun kampüs fabric teknolojisi — kablosuz ve kablolu portlar, tutarlı VLAN ve SGT (Security Group Tag) atamasıyla aynı politika fabric’ine katılır.
• AI geliştirilmiş RRM: Tarihsel RF verilerine dayalı kanal ve güç atamalarını optimize etmek için makine öğrenmesi kullanan Radyo Kaynak Yönetimi.

ISE entegrasyonu: Cisco Identity Services Engine, 802.1X kimlik doğrulaması ve politika sağlar. Bir istemci bağlandığında, ISE onu doğrular, bir güvenlik grubu atar ve DNA Center karşılık gelen ağ politikasını uygular — istemci kablolu veya kablosuz olsun tutarlı.

Cisco Meraki: Bulut Yönetimli Sadelik

Meraki, Cisco’nun kurumsal esneklik yerine operasyonel sadelik için tasarlanmış bulut yönetimli platformudur:

• Pano: Tüm yönetim tek bir bulut portalı üzerinden. Sıfır şirket içi controller donanımı.
• Otomatik sağlama: Yeni AP’ler bağlandığında otomatik olarak sağlanır — manuel yapılandırma yok.
• Entegre güvenlik: Meraki AP’ler yerleşik IDS/IPS, içerik filtreleme ve trafik analitiği içerir.
• MX entegrasyonu: Meraki kablosuz, Meraki MX güvenlik cihazlarıyla yerel olarak entegre olur — kablolu ve kablosuz arasında birleşik politika.

Takas noktaları: Karmaşık kurumsal politikalar için Catalyst Center’dan daha az esnek. Tüm yönetim bulut bağlantısı gerektirir (AP’ler çevrimdışı olsa da çalışmaya devam eder, ancak yapılandırılamaz). Abonelik tabanlı lisanslama.

Meraki’nin üstün olduğu yer: Çok siteli perakende, konaklama, KOBİ, şube ofisleri — operasyonel sadelik ve hızlı deployment’ın derin kurumsal özelleştirmeden daha önemli olduğu herhangi bir senaryo.

Aruba Kablosuz Mimarisi

Geleneksel: Aruba Mobility Master + Mobility Controller’lar

Aruba’nın şirket içi kurumsal mimarisi:

• Mobility Master (MM): Üst düzey yönetim ve orkestrasyon platformu. Veri trafiğini iletmez — yalnızca kontrol düzlemi.
• Mobility Controller’lar (MC): Yerel AP’leri için AP yönetimini, istemci kimlik doğrulamasını ve veri iletimini yöneten dağıtık controller’lar.
• AP’ler: Atanmış controller’larına bağlı, “kampüs AP” modunda Aruba erişim noktaları.

[Mobility Master]
        │
   ┌────┴────┐
[MC-1]     [MC-2]      ← Dağıtık controller'lar
  │           │
[AP'ler]   [AP'ler]

Mobility Master hiyerarşisi, yönetim karmaşıklığını veri düzlemi ölçeğinden ayırır. MM, küresel politikayı, yazılım yönetimini ve RF planlamasını yönetir. Controller’lar yerel AP yönetimini ve istemci verilerini yönetir. Bu mimari, büyük, çok binali kampüsler için iyi ölçeklenir.

Küme mobilitesi: Aynı kümede bulunan controller’lar istemci durumunu paylaşır. Aynı kümedeki farklı controller’lardaki AP’ler arasında roaming kesintisizdir — istemcinin kimlik doğrulaması ve oturumu onunla birlikte taşınır.

Modern: Aruba CX + AOS 10

Aruba’nın mevcut mimarisi (AOS 10) dağıtık, fabric entegre bir modele doğru kayıyor:

• AP’lerin daha fazla yerel zekası var — kimlik doğrulama ve politika uygulaması, her paket için controller katılımı olmadan AP’de gerçekleşebilir
• Birleşik kablolu/kablosuz politika için Aruba CX switching fabric ile entegrasyon
• Yönetim düzlemi olarak Aruba Central — bulut tabanlı, birçok deployment için şirket içi Mobility Master’ın yerini alıyor

Aruba Central: Bulut Yönetimli Kurumsal

Cisco Meraki’den farklı olarak (sadelik için tasarlanmış), Aruba Central kurumsal kaliteli bulut yönetimi olarak konumlandırılmıştır:

• Bulut yönetimi aracılığıyla tam kurumsal politika yetenekleri
• AI destekli ağ içgörüleri ve anomali tespiti
• 802.1X kimlik doğrulaması için ClearPass entegrasyonu (yalnızca şirket içi değil, bulut bağlantılı)
• Çok büyük deployment’lar için destek (binlerce AP, yüzlerce site)

ClearPass entegrasyonu, Aruba’nın en güçlü farklılaştırıcısıdır: 802.1X, cihaz profillemesi, misafir portalı, posture değerlendirmesi ve dinamik VLAN atamasını yöneten özel bir NAC platformu. ClearPass, kapsamlı kimlik tabanlı ağ erişimi için Active Directory, LDAP ve üçüncü taraf MDM sistemleriyle entegre olur.

Roaming Mimarisi: Kritik Tasarım Kararları

Katman 2 Roaming

İstemci AP-1’den AP-2’ye geçer, her ikisi de aynı VLAN’da ve aynı controller tarafından yönetilir. İstemcinin IP adresi değişmez. Roaming hızlı ve şeffaftır.

AP-1 (VLAN 10) ──→ İstemci dolaşır ──→ AP-2 (VLAN 10)
Aynı alt ağ, aynı controller, istemci IP değişmez

Katman 3 Roaming

İstemci alt ağlar arasında geçer — farklı controller’lardaki veya binalardaki farklı VLAN’lar. Özel yönetim olmadan, istemcinin yeni bir IP adresine ihtiyacı olur ve aktif oturumlar kesilir.

Kurumsal controller’lar, mobilite tüneli aracılığıyla Katman 3 roaming’i yönetir — orijinal controller (“anchor”) istemcinin orijinal IP adresini korur ve trafiği istemcinin mevcut controller’ına (“foreign”) tünel üzerinden iletir:

İstemci AP-1'e bağlanır (Bina A, VLAN 10, Controller-1)
İstemci AP-2'ye dolaşır (Bina B, VLAN 20, Controller-2)

Controller-2 (foreign) ──mobilite tüneli──→ Controller-1 (anchor)
İstemci IP: hâlâ VLAN 10'dan 192.168.10.x
Oturum: kesintisiz

Bu ek yük ekler — dolaşan istemcinin trafiği controller’lar arası tüneli geçmek zorundadır. Çoğu uygulama için bu ihmal edilebilir düzeydedir. Gecikmeye duyarlı uygulamalar (VoIP, gerçek zamanlı video) için anchor-to-foreign tünel uzunluğunu en aza indirin.

Hızlı Roaming: 802.11r/k/v

Standartlar yazısında ele alındığı gibi, kurumsal deployment’ların tüm üç hızlı roaming protokolünü etkinleştirmesi gerekir. Controller perspektifinden:

• 802.11r: Controller, istemci mevcut AP’den bağlantısını kesmeden önce hedef AP ile istemciyi önceden doğrular. Controller düzeyinde koordinasyon gerektirir.
• 802.11k: Controller, komşu AP bilgilerini istemcilere sağlar. İstemciler bunu daha iyi roaming kararları vermek için kullanır.
• 802.11v: Controller, bir istemcinin belirli bir AP’ye dolaşmasını önerebilir veya talep edebilir — yük dengeleme ve yapışkan istemci yönetimi için kullanışlı.

Opportunistic Key Caching (OKC): WPA2-Enterprise (802.1X) kullanan ağlar için OKC, istemcinin yeni bir AP’ye dolaşırken önbelleğe alınmış bir PMK’yı (Pairwise Master Key) yeniden kullanmasına olanak tanır ve tam 802.1X yeniden doğrulamasını önler. 802.1X ağlarında roaming süresini önemli ölçüde azaltır.

Radyo Kaynak Yönetimi

Kurumsal controller’lar, Radyo Kaynak Yönetimi (RRM) aracılığıyla RF ortamını sürekli olarak optimize eder:

İletim Gücü Kontrolü

Controller, AP’ler arasında RSSI’yi (sinyal gücü) izler. Bir AP komşulardan güçlü sinyaller algılarsa, iletim gücünü azaltır — bitişik hücrelerle girişimi azaltırken kapsama alanını korur.

Kapsama boşluğu tespiti: Bir istemci düşük RSSI bildirirse, controller kapsama boşluklarını önlemek için AP’nin iletim gücünü artırabilir. Bu kapsama boşluklarını önler ancak komşu AP’lerle girişim karşı dengelenmelidir.

Dinamik Kanal Atama

Controller RF ortamını tarar ve aynı kanaldaki girişimi en aza indirmek için kanallar atar:

• AP’ler komşu AP sinyallerini ve istemci girişimini raporlar
• Controller bir RF topoloji haritası oluşturur
• Kanallar, aynı kanaldaki AP’ler arasındaki ayrımı en üst düzeye çıkarmak için atanır

Cisco’da bu RRM (Radyo Kaynak Yönetimi)‘dir. Aruba’da ise ARM (Adaptive Radio Management). Her ikisi de özerk çalışır, ancak bilinen RF zorluklarında manuel geçersiz kılmadan yararlanır.

İstemci Yük Dengeleme

Birden fazla AP aynı alanı kapladığında (örtüşen hücreler), controller istemcileri AP’ler arasında dağıtabilir:

• Her ikisi de kapsama alanındayken yeni istemcileri daha az yüklü AP’ye yönlendirin
• Aşırı yüklü AP’lerden daha az yüklü komşulara istemci taşıyın

Bu dikkatli ayarlama gerektirir — agresif yük dengeleme istemcilerin gereksiz yere dolaşmasına neden olur.

Controller Mimarisinde HA ve Yedeklilik

WLC HA (Cisco)

Cisco 9800 WLC’ler, High Availability SSO (Stateful Switchover) destekler:

WLC-Aktif ──RP (Yedeklilik Portu)──→ WLC-Yedek
     │                                      │
Yapılandırma yansıtıldı              İstemci oturumları yansıtıldı

Aktif WLC başarısız olduğunda, yedek tam istemci oturum durumuyla devralır — istemciler yeniden bağlanmaz. AP’ler CAPWAP tünellerini korur; geçiş şeffaftır.

N+1 yedeklilik: Büyük deployment’larda, birden fazla WLC AP yükünü paylaşır. Biri başarısız olursa, AP’leri kalan WLC’lere yeniden kaydeder. AP geri dönüş önceliklerini yapılandırmayı gerektirir.

Aruba Controller HA

Aruba, birden fazla controller’ın AP ve istemci yükünü paylaştığı Aktif-Aktif küme yapılandırmalarını destekler:

[MC-1] ←─ küme ─→ [MC-2] ←─ küme ─→ [MC-3]
  │                   │                   │
[AP'ler]           [AP'ler]           [AP'ler]

MC-1 başarısız olursa, AP’leri MC-2 ve MC-3’e dağıtır. İstemci oturumları küme durum paylaşımı aracılığıyla korunur.

Bulut Yönetimi Dayanıklılığı

Bulut yönetimli AP’ler (Meraki, Aruba Central), bulut bağlantısı kesilmesi sırasında çalışmaya devam eder:

• AP’ler son bilinen yapılandırmayı korur
• İstemciler normal şekilde bağlanıp dolaşabilir
• Yönetim operasyonları (yapılandırma değişiklikleri, izleme) bulut bağlantısı gerektirir

İnternet bağlantısından bağımsız olarak garantili yönetim erişimi gerektiren ortamlar için, şirket içi controller mimarisi daha uygun olmaya devam eder.

Kimlik Sistemleriyle Entegrasyon

Cisco ISE Entegrasyonu

802.1X için Cisco ISE kullanan deployment’lar için:

İstemci WiFi'ye bağlanır
      ↓
AP, ISE'ye RADIUS isteği gönderir (WLC aracılığıyla)
      ↓
ISE, Active Directory'e karşı doğrular
      ↓
ISE döndürür: VLAN ataması + Security Group Tag
      ↓
WLC politikayı uygular: istemci doğru VLAN'a yerleştirilir
      ↓
DNA Center, SGT tabanlı politikayı uçtan uca uygular

ISE posture değerlendirmesi, tam ağ erişimi vermeden önce cihaz uyumluluğunu da kontrol edebilir (AV durumu, işletim sistemi yama seviyesi) — kablolu ve kablosuz istemciler için özdeş davranış.

Aruba ClearPass Entegrasyonu

ClearPass, Aruba deployment’ları için eşdeğer yetenekler sağlar:

• RADIUS aracılığıyla 802.1X kimlik doğrulaması
• 802.1X supplicant’ı olmayan cihazlar için MAC Authentication Bypass (MAB)
• Cihaz profilleme — DHCP, HTTP User-Agent ve CDP/LLDP sinyallerine dayalı cihaz türünü (telefon, dizüstü, yazıcı, IoT) tanımlama
• Misafir portalı — kendi kendine kayıt veya sponsor onayı iş akışları
• Kullanıcı kimliğine, cihaz türüne ve posture’a dayalı dinamik VLAN ve rol ataması

ClearPass’ın OnGuard ajanı posture değerlendirmesi yapar — kurumsal dizüstü bilgisayarların güncel AV, gerekli yamalar ve onaylı yazılıma sahip olup olmadığını kontrol eder.

Temel Çıkarımlar

• Controller mimarisi roaming kalitesini, politika tutarlılığını ve operasyonel karmaşıklığı belirler — yalnızca yönetim kolaylığını değil.
• Merkezi WLC, trafik hairpin ve tek hata noktası riski pahasına kesintisiz roaming ve tutarlı politika sağlar (HA ile hafifletilir).
• Bulut yönetimi (Meraki, Aruba Central), şirket içi donanım olmadan operasyonel sadelik ve çok siteli ölçek sunar.
• Hızlı roaming (802.11r/k/v + OKC), ses ve video uygulamaları için controller düzeyinde etkinleştirilmelidir — varsayılan yapılandırma nadiren optimaldir.
• ISE/ClearPass entegrasyonu, kablosuzu “bir ağ"dan “kimlik bilincine sahip bir politika uygulama noktası"na dönüştürür — kablolu ve kablosuz için tutarlı davranış, hepsi kimin ve neyin bağlandığına dayalı.

Bu Seri

• 📖 Kurumsal WiFi Mimarisi Genel Bakış ← Buradan başlayın
• 📡 802.11 Standartları Deep Dive
• 🏨 KOBİ, Oteller ve Muayenehane İçin WiFi Tasarımı
• 🔐 WiFi Güvenliği: WPA3, 802.1X, Sahte AP, Site Survey

İlgili Yazılar

• 🔐 802.1X Kimlik Tabanlı Mimari Sahada — 802.1X deployment’ına derinlemesine bakış
• 🏗️ IT Altyapısı Ürünler Koleksiyonu Değildir — Kablosuz için sistem düşüncesi
• 📊 İzleme Doğru Yapıldığında — Kablosuz altyapıyı proaktif olarak izleme

Bu yazı F5 BIG-IP serisinin bir parçasıdır.

F5’e yeni misiniz? Önce platform genel bakışıyla başlayın: F5 BIG-IP Bir Load Balancer Değil — Uygulama Teslim Platformudur

Büyük resmi zaten anlıyorsanız ve GTM’e derinlemesine inmek istiyorsanız — iQuery, Wide IP’ler, topoloji routing, TTL stratejisi ve çok DC tasarımı — doğru yerdesiniz.

GTM’in Çözdüğü Sorun

LTM, uygulama trafiğini tek bir veri merkezi içinde yönetir. Bağlantıları backend sunucular arasında dağıtır, sağlığı izler ve tek bir sitede HA sağlar. Ancak LTM’nin veri merkezinin dışında ne olduğuna dair görünürlüğü yoktur — siteler arasında trafik yönlendiremez.

GTM’in doldurduğu boşluk tam olarak budur. Bir organizasyonun iki veri merkezi, birincil bir DC ve bir DR sitesi ya da küresel olarak dağıtılmış altyapısı olduğunda soru şudur: İstemciler hangi veri merkezine bağlanacaklarını nasıl bilir ve biri çevrimdışı olduğunda ne otomatik olarak gerçekleşir?

GTM olmadan yanıt genellikle manuel DNS değişiklikleridir — yavaş, hatalara açık ve otomatik failover için tamamen uygunsuz. GTM bunu DNS katmanında çözer.

DNS Akışı: GTM Nasıl Karar Verir

GTM, uygulama zone’larınız için yetkili DNS sunucusu olarak davranır. Bir istemci webapp.sirket.com‘u çözümlediğinde, sorgu standart bir DNS sunucusu yerine GTM’e ulaşır:

1. İstemci: "webapp.sirket.com için IP nedir?"
2. Sorgu GTM'e ulaşır (sirket.com zone'u için yetkili)
3. GTM gerçek zamanlı olarak değerlendirir:
   → DC-1 LTM sağlıklı mı? (iQuery aracılığıyla)
   → DC-2 LTM sağlıklı mı? (iQuery aracılığıyla)
   → Hangi load balancing politikası geçerli?
   → Bu istemci coğrafi olarak nerede?
4. GTM yanıtlar: "webapp.sirket.com = 10.10.1.100" (DC-1 VIP)
5. İstemci 10.10.1.100'e bağlanır → LTM buradan devralır

Zeka 3. adımdadır. GTM statik bir kayıt döndüren pasif bir DNS sunucusu değildir — bir sorguyu her yanıtladığında mevcut altyapı sağlığına ve politikaya dayalı gerçek zamanlı bir karar verir.

GTM Nesne Hiyerarşisi

GTM, DNS yapısını yansıtan dört seviyeli bir hiyerarşi kullanır:

Veri Merkezi  →  Sunucu  →  Virtual Server  →  Wide IP (Pool Member)

Veri Merkezi: Fiziksel bir site için mantıksal gruplama (DC-Istanbul, DC-Frankfurt). O konumdaki tüm GTM kayıtlı sunucuları içerir.

Sunucu: GTM’e kayıtlı bir BIG-IP cihazı (genellikle bir LTM). GTM, gerçek zamanlı sağlık verileri için iQuery aracılığıyla onunla iletişim kurar.

Virtual Server: Kayıtlı bir sunucudaki belirli bir LTM virtual server’ı (VIP). GTM’in trafiği yönlendirebileceği gerçek endpoint.

GTM Pool’u: Bir veya birden fazla LTM genelinde virtual server’lardan oluşan bir grup. GTM, DNS yanıtlarını pool member’lar arasında dağıtır.

Wide IP: İstemcilerin çözümlediği DNS adı (webapp.sirket.com). Bir Wide IP, bir veya daha fazla GTM pool’una referans verir ve çözümleme politikasını tanımlar.

iQuery: GTM’in Gerçekte Uygulama Sağlığını Neden Anladığı

iQuery, GTM’e gerçek uygulama farkındalığı veren özel F5 protokolüdür. Bu, GTM’i yalnızca bir VIP’e ping atan veya TCP erişilebilirliğini kontrol eden harici DNS load balancer’lardan ayıran şeydir.

iQuery olmadan GTM yalnızca bir IP adresinin probe’a yanıt verip vermediğini bilir. iQuery ile GTM şunları bilir:

• LTM virtual server’ının etkin ve aktif olup olmadığı
• O virtual server’ın arkasındaki pool’un sağlıklı, aktif member’lara sahip olup olmadığı
• LTM’deki mevcut aktif bağlantı sayısı
• Mevcut CPU ve bellek kullanımı

Kritik sonuç: Bir backend uygulaması başarısız olduğunda ve LTM pool’unu down olarak işaretlediğinde, iQuery bunu GTM’e anında iletir — herhangi bir istemcinin bozuk bir endpoint’e bağlanma şansı olmadan. GTM, o DC’nin VIP’ini hemen DNS sorgularına yanıt olarak vermeyi durdurur.

GTM’den bir VIP IP’sine TCP sağlık probe’u bu durumu hiçbir zaman tespit edemezdi — VIP IP’si, arkasındaki uygulama tamamen bozuk olsa bile erişilebilir kalmaya devam eder. Farkı yaratan iQuery’dir.

GTM’e LTM Kaydetme

Sunucu: ltm-dc1
  Ürün:          BIG-IP (iQuery'yi etkinleştirir)
  Adres:         10.10.0.1 (LTM yönetim IP'si)
  Veri Merkezi:  DC-Istanbul
  Virtual Server'lar: [iQuery aracılığıyla otomatik keşfedilir]
    - vs_webapp_443  (10.10.1.100:443)
    - vs_api_443     (10.10.1.101:443)
    - vs_admin_443   (10.10.1.102:443)

Kaydedildikten sonra GTM, o LTM’deki tüm virtual server’ları otomatik olarak keşfeder ve izler. GTM’de manuel virtual server yapılandırması gerekmez — iQuery keşfi yönetir.

Wide IP’ler ve GTM Pool’ları

Bir Wide IP, bir DNS adını bir çözümleme politikasına bağlar:

Wide IP: webapp.sirket.com (tür: A)
  Pool: gtm_pool_webapp_primary
    Load Balancing Yöntemi: Global Availability
    Member'lar:
      - ltm-dc1 / vs_webapp_443  (Sıra: 1)
      - ltm-dc2 / vs_webapp_443  (Sıra: 2)
  Fallback Pool:    gtm_pool_webapp_dr
  Last Resort Pool: [tüm pool'lar tükenirse SERVFAIL döndür]

Bir Wide IP’nin öncelik sırasına göre birden fazla pool’u olabilir. Birincil pool’un kullanılabilir member’ı yoksa GTM otomatik olarak bir sonraki pool’u dener. Bu, manuel müdahale olmadan kademeli failover mimarisi sağlar.

Load Balancing Yöntemleri

GTM load balancing, DNS yanıt seviyesinde çalışır — her yöntem, belirli bir sorgu için hangi pool member’ın IP’sinin döndürüleceğini belirler.

Global Availability

Her zaman ilk kullanılabilir member’ın IP’sini döndürür. Yalnızca mevcut kullanılamadığında bir sonraki member’a geçer:

Member'lar (öncelik sırasına göre):
  1. ltm-dc1 / vs_webapp_443  ← sağlıklıyken tüm trafik
  2. ltm-dc2 / vs_webapp_443  ← yalnızca DC-1 başarısız olduğunda trafik

En iyisi: Birincil/DR mimarileri. Tüm trafik birincil sitede çalışır; DR yalnızca gerçek kesintiler sırasında etkinleşir. Bankacılık ortamındaki standart yöntem buydu — uygun maliyetli, hakkında düşünmesi basit ve arıza altında öngörülebilir.

Round Robin

DNS yanıtlarını pool member’lar arasında dönüşümlü olarak verir:

Sorgu 1 → DC-1 VIP
Sorgu 2 → DC-2 VIP
Sorgu 3 → DC-1 VIP

En iyisi: Her sitede eşit kapasiteli aktif-aktif çok DC mimarileri. Her iki sitenin de sürekli olarak yükü paylaşması gereken büyük ölçekli web uygulamalarında yaygın.

Ratio

Ağırlıklı dağılım:

ltm-dc1 / vs_webapp_443  Ratio: 7  ← DNS yanıtlarının %70'i
ltm-dc2 / vs_webapp_443  Ratio: 3  ← DNS yanıtlarının %30'u

En iyisi: Veri merkezlerinin farklı kapasitelere sahip olduğu aktif-aktif. Kapasiteyle orantılı yük dağılımı sağlar.

Topology

DNS yanıtlarını istemcinin DNS çözümleyici IP’sinin coğrafi konumuna göre yönlendirir:

Topoloji Kayıtları (yukarıdan aşağıya değerlendirilir, ilk eşleşme kazanır):
  alt ağ 10.0.0.0/8         → DC-Istanbul   (tüm dahili kullanıcılar)
  ISP: Turk Telekom         → DC-Istanbul
  bölge: Avrupa             → DC-Frankfurt
  bölge: Orta Doğu          → DC-Istanbul
  varsayılan               → DC-Frankfurt

En iyisi: Birden fazla bölgedeki kullanıcılara sahip global uygulamalar. Kullanıcıları en yakın DC’ye yönlendirerek gecikmeyi azaltır. Ayrıca veri yerleşimi uyumluluğunu sağlar — AB kullanıcılarının isteklerinin AB veri merkezlerinde işlenmesini garanti eder.

GTM, çözümleyici IP’lerini bölgelere eşleştirmek için bir IP coğrafi konum veritabanı kullanır. Bu veritabanını güncel tutun — ISP’ler IP aralıklarını düzenli olarak yeniden tahsis eder ve güncel olmayan coğrafi konum verileri kullanıcıları yanlış bölgelere gönderir.

Least Connections

iQuery aracılığıyla gerçek zamanlı olarak elde edilen en az aktif bağlantıya sahip pool member’a yönlendirir:

iQuery aracılığıyla mevcut durum:
  ltm-dc1: 4.521 aktif bağlantı
  ltm-dc2: 3.102 aktif bağlantı
  → GTM bir sonraki sorgu için DC-2 VIP'ini döndürür

En iyisi: Statik ağırlıklar yerine gerçek bağlantı sayılarına dayalı dinamik load balancing’in tercih edildiği aktif-aktif mimariler.

DNS TTL Stratejisi: En Çok Yanlış Anlaşılan Konu

TTL, DNS çözümleyicilerin GTM’nin yanıtını ne kadar süre önbelleğe alacağını belirler. Bu yaygın biçimde yanlış anlaşılır:

TTL, adı zaten çözümlemiş istemciler için failover hızını kontrol etmez. 10 saniye önce webapp.sirket.com‘u çözümleyen bir istemci, TTL sona erene kadar önbelleğe alınan IP’yi kullanmaya devam eder — GTM’nin şu anda neye yanıt verdiğinden bağımsız olarak.

TTL, yeni DNS sorgularının mevcut altyapı durumunu ne kadar hızlı yansıtacağını kontrol eder.

TTL Takas Değerlendirmeleri

Bankacılık ortamında:

• Ödeme işleme ve kimlik doğrulama servisleri için 30 saniye
• Genel bankacılık uygulamaları için 60 saniye
• Dahili panolar ve izleme araçları için 300 saniye

Minimum Etkin Failover Süresini Hesaplama

En kötü durum failover süresi ≈ Sağlık kontrolü aralığı + TTL

5 saniyelik iQuery kontrol aralığı ve 30 saniyelik TTL ile: en kötü durum ~35 saniyedir. Bazı istemciler arıza tespitinden sonra saniyeler içinde yeni DC’ye geçer; diğerleri TTL süresinin dolmasını bekler.

Katı RTO gereksinimleri olan uygulamalar için geçiş penceresini zarif biçimde yönetmek için düşük TTL’yi uygulama düzeyinde yeniden deneme mantığıyla birleştirin.

Çok DC Mimari Desenleri

Aktif-Yedek (Birincil / DR)

Normal:
  GTM → DC-1 LTM → Uygulama Sunucuları (DC-1)
  DC-2 sıcak yedektir — çalışıyor, senkronize, trafik yok

DC-1 arızası:
  iQuery: DC-1 LTM virtual server'ı down olarak işaretlendi
  GTM: DC-1 VIP'ini hemen yanıt olarak vermeyi durdurur
  Yeni DNS sorguları: DC-2 VIP'ini alır
  Trafik kayması: TTL penceresi içinde

Gereksinimler:

• Her iki DC’de özdeş uygulama deployment’ı
• Veritabanı replikasyonu (sıfır RPO için senkron, daha düşük RPO için asenkron)
• GTM yöntemi: Global Availability

Aktif-Aktif (Yük Paylaşımı)

Normal:
  GTM → DC-1 (DNS yanıtlarının %50'si)
  GTM → DC-2 (DNS yanıtlarının %50'si)

DC-1 arızası:
  GTM, %100'ünü DC-2'ye yönlendirir

Gereksinimler:

• DC’ler arasında paylaşılan oturum durumu veya durumsuz uygulama tasarımı
• Her DC’nin bağımsız olarak %100 trafiği karşılayabilmesi gerekir (bu kapasite için plan yapın)
• Her iki DC’den aynı anda yazılabilir veritabanı
• GTM yöntemi: Round Robin, Ratio veya Least Connections

Aktif-aktif, daha iyi kaynak kullanımı ve daha hızlı etkin failover sağlar (soğuk başlatma DR sitesi yok). Mimari karmaşıklık daha yüksektir — özellikle veritabanı yazma çakışmaları ve oturum durumu yönetimi konusunda.

Topoloji Tabanlı Coğrafi Dağılım

AB kullanıcıları    → Avrupa'daki çözümleyici IP   → DC-Frankfurt
MENA kullanıcıları  → Orta Doğu'daki çözümleyici IP → DC-Istanbul
Dahili             → RFC1918 kaynak                → DC-Istanbul (en yakın)
Varsayılan         → DC-Frankfurt

Her DC, normal koşullarda kendi bölgesinin trafiğini yönetir. Fallback topoloji kayıtları, kesinti sırasında tüm bölgeleri hayatta kalan DC’ye yönlendirir.

Bu desen performans avantajlarını (daha düşük gecikme) uyumluluk gereksinimleriyle (veri yerleşimi) ve kapasite optimizasyonuyla (her DC kendi bölgesi için boyutlandırılmış) birleştirir.

GTM Monitor’ları ile iQuery: Her Biri Ne Zaman Kullanılır

iQuery (BIG-IP LTM’ler için):

• LTM’den gerçek zamanlı uygulama sağlık verileri
• Ek izleme trafiği yok
• Yalnızca IP erişilebilirliğini değil uygulama sağlığını bilir
• Otomatik virtual server keşfi
• Tüm BIG-IP LTM endpoint’leri için kullanın

GTM yerel monitor’ları (BIG-IP olmayan endpoint’ler için):

• GTM kendi sağlık probe’larını doğrudan endpoint’lere gönderir
• TCP, HTTP, HTTPS, ICMP destekler
• Hibrit ortamlarda üçüncü taraf load balancer’lar, bulut endpoint’leri, kaynak sunucular için kullanın

Çoğu kurumsal deployment’ta iQuery, tüm BIG-IP’ten BIG-IP’e izlemeyi yönetir. GTM yerel monitor’ları, bazı endpoint’lerin F5 cihazı olmadığı hibrit mimariler için ayrılmıştır.

GTM’de DNS Persistence

GTM TCP durumunu korumaz — yalnızca DNS yanıtlarını etkiler. Ancak, aynı çözümleyiciden tekrarlanan sorguların yapılandırılabilir bir süre boyunca aynı IP’yi döndürmesini sağlamak için DNS persistence destekler:

Wide IP Persistence:
  Etkin: Evet
  TTL:   300 saniye
  Tür:   Kaynak IP'ye göre (çözümleyici IP)

Persistence etkinleştirildiğinde GTM, load balancing yönteminden bağımsız olarak 300 saniye boyunca aynı çözümleyiciye aynı VIP’i döndürür. Bu, istemciler sık sık yeniden çözümlediğinde oturum kesintisini azaltır.

Önemli uyarı: DNS persistence, son istemci IP’sine değil çözümleyici IP’sine dayanır. Birçok son kullanıcı tek bir ISP özyinelemeli çözümleyiciyi paylaştığında, hepsi GTM için aynı “istemci” olarak görünür. Persistence, bu durumlarda orantısız trafiği bir DC’ye yoğunlaştırabilir. Etkinleştirmeden önce persistence’ın gerçekten yardımcı olup olmadığını değerlendirin.

Temel Çıkarımlar

• GTM, çok DC DNS failover’ını çözer — LTM’nin tek başına ele alamayacağı sorun.
• iQuery, GTM’nin en önemli özelliğidir: yalnızca IP erişilebilirliği değil, gerçek uygulama sağlık farkındalığı. LTM bir uygulama pool’unu down olarak işaretlediğinde GTM anında tepki verir.
• Global Availability, birincil/DR için doğru yöntemdir. Aktif-aktif için Round Robin veya Ratio.
• Topology routing, global deployment’lar için gecikmeyi azaltır ve veri yerleşimi uyumluluğunu sağlar.
• TTL yalnızca yeni aramaları kontrol eder — mevcut bağlantıları değil. Minimum etkin failover = sağlık kontrolü aralığı + TTL.
• BIG-IP LTM’ler için iQuery kullanın; üçüncü taraf endpoint’ler için GTM yerel monitor’larını kullanın.

Bu Seri

• 📖 F5 BIG-IP Platform Genel Bakış — Tüm Modüller ← F5’e yeniyseniz buradan başlayın
• 🔧 F5 LTM Deep Dive
• 🛡️ F5 WAF Deep Dive

İlgili Yazılar

• 🏗️ IT Altyapısı Ürünler Koleksiyonu Değildir — Çok DC tasarımı için sistem düşüncesi
• 🔐 Zero Trust Zihniyeti — Dağıtık altyapıda kimlik bilincine sahip erişim
• 📊 İzleme Doğru Yapıldığında — GTM ve LTM sağlığını proaktif olarak izleme

Birkaç yıldan fazla ağ mühendisliği yapıyorsanız, muhtemelen terminal istemcisinin içinde binlerce saat geçirmişsinizdir. Bir switch’e SSH, birkaç show komutu, değişiklik yap, sonraki cihaza geç. İşin en tekrar eden iş akışı — ve doğru araç bunu önemli ölçüde daha az acı verici kılar.

Çoğu mühendis PuTTY ile başlar. Çalışır, ücretsizdir ve söylediğini yapar. Ancak terminal iş akışını işlevsel olmaktan gerçekten verimli olmaya taşıyan iki araç vardır: SecureCRT (profesyonel standart) ve SuperPutty (PuTTY kullanıcılarının ihtiyaç duyduğunu bilmediği ücretsiz yükseltme).

Bu yazı her ikisini de kapsar — gerçekte ne yaptıklarını, günlük ağ çalışmasında önemli olan özellikleri ve her birinin ne zaman mantıklı olduğunu.

Neden Düz PuTTY Sonunda Yetmez

PuTTY sağlam bir araçtır. Ara sıra bağlantılar için mükemmel biçimde yeterlidir. Ancak günlük ağ mühendisliği çalışmasında — düzinelerce cihazı yönetmek, birden fazla oturumda aynı anda sorun gidermek, hangi komutların ne zaman çalıştırıldığının kayıtlarına ihtiyaç duymak — düz PuTTY sürtünme yaratır:

• Sekme yok: Her bağlantı ayrı bir penceredir. 15 cihazı aynı anda yönetmek, görev çubuğunda 15 pencere ve sürekli doğru olanı aramak demektir.
• Otomatik loglama yok: Bir şeyler ters giderse ve 20 dakika önce hangi komutların çalıştırıldığını bilmeniz gerekiyorsa, oturumdan önce loglama’yı manuel olarak yapılandırmadıysanız PuTTY bu kaydı tutmaz. Olay baskısı altında bu nadiren yapılır.
• Oturum taşınabilirliği yok: PuTTY oturumları Windows Registry’de saklanır. Yeni bir dizüstü bilgisayara geçmek, kaydedilmiş her oturumu manuel olarak yeniden oluşturmak veya registry anahtarlarını dışa aktarıp hiçbir şeyin bozulmamasını ummak demektir.
• Oturum başına kimlik bilgisi depolama yok: Bir ana bilgisayar adı ve port kaydedebilirsiniz, ancak kimlik bilgilerini değil. Her oturum kullanıcı adı ve şifre yazmayı (veya yapıştırmayı) gerektirir.

Bu sınırlamalar beş cihaz yönetirken yönetilebilirdir. Yüzlerce cihaz yönetirken, gerçek ek yüke dönüşürler.

SecureCRT: Profesyonel Standart

SecureCRT, VanDyke Software tarafından yapılan ticari bir terminal istemcisidir. On yıllardır profesyonel ağ mühendisliği ortamlarında tercih edilen araç olmuştur. Bunun nedeni arayüz değildir — gerçek mühendislik çalışmasında önemli olan operasyonel özelliklerdir.

Otomatik Oturum Loglama

Bu, günlük iş akışını en çok değiştiren özelliktir.

SecureCRT, her oturum için otomatik olarak bir log dosyası oluşturacak şekilde yapılandırılabilir — cihaza göre adlandırılmış, zaman damgalı, seçtiğiniz bir klasör yapısında saklanmış. Bunu düşünmenize gerek yok. Bir cihaza bağlanırsınız ve SecureCRT her şeyi zaten diske yazıyordur:

Logs/
  2026-03/
    core-sw-01_20260314_143022.log
    fw-dc1_20260314_151437.log
    router-edge-01_20260314_162005.log

Pratikte neden önemlidir:

Bir ağ olayı sırasında, tam olarak hangi komutların çalıştırıldığını, hangi sırayla ve cihazın ne yanıt verdiğini bilmeniz gerekir. Baskı altında manuel bellek güvenilmezdir. Otomatik loglar, ekstra adım gerektirmeden her oturumun eksiksiz, zaman damgalı kaydını verir.

Düzenlenmiş ortamlarda (bankacılık, sağlık hizmetleri) değişiklik yönetimi için, oturum logları çoğunlukla bir uyumluluk gereksinimidir. SecureCRT bunu mühendislerin logulamayı etkinleştirmeyi hatırlamasına güvenmek yerine otomatik olarak yönetir.

“Geçen Perşembe bu cihazda ne değişti” sorunun yanıtı için — log klasörünüzde grep yapın.

SecureCRT’de otomatik loglamayı yapılandırma:

Options → Global Options → Log File — değişkenler kullanarak log dosya adı deseni ayarlayın:

%D\%H_%Y%M%D_%h%m%s.log

%H ana bilgisayar adı, %Y%M%D tarih, %h%m%s saattir. SecureCRT dizinler mevcut değilse otomatik olarak oluşturur.

Loglama’yı oturum başına veya oturum grubu başına da yapılandırabilirsiniz — farklı müşteri ortamları için farklı log konumları istiyorsanız kullanışlıdır.

Oturum Yönetimi ve Taşınabilirlik

SecureCRT tüm oturumları, Windows Registry değil, taşınabilir dosya tabanlı bir formatta saklar. Bu, PuTTY’den temel bir farktır.

Oturum klasörleri ve organizasyonu:

Oturumlar bir ağaç yapısında düzenlenir — tıpkı dosya gezgini gibi. Birden fazla müşteri veya ortam yöneten bir ağ mühendisi için tipik organizasyon:

Oturumlar/
  Müşteri-A/
    Çekirdek/
      core-sw-01
      core-sw-02
    Dağıtım/
      dist-sw-zemin1
      dist-sw-zemin2
    Firewall'lar/
      fw-birincil
      fw-ikincil
  Müşteri-B/
    ...
  Lab/
    ...

Her oturum şunları saklar: ana bilgisayar adı/IP, port, protokol, kullanıcı adı, bağlantı ayarları ve isteğe bağlı olarak şifre (şifreli). Bir oturum klasörü açtığınızda, tüm cihazlarınızı ağınızın yapılandırıldığı gibi organize edilmiş görürsünüz.

Taşınabilirlik — yeni makineye geçiş:

Oturumlar dosya tabanlı olduğundan, yeni bir dizüstü bilgisayara geçmek basittir:

1. SecureCRT oturumlar klasörünü yeni makineye kopyalayın (veya bulut depolama / ağ paylaşımı aracılığıyla senkronize edin)
2. SecureCRT’yi klasöre yönlendirin
3. Tüm oturumlar, organizasyon ve ayarlar hemen kullanılabilir

Birden fazla mühendisli ortamlarda, ortak bir ağ sürücüsü ortak bir oturum veritabanını tutabilir — herkes aynı cihaz listesine erişir ve bir mühendis tarafından yapılan eklemeler hemen diğerlerine görünür.

Dışa aktarma ve yedekleme:

File → Export Settings tüm oturum veritabanını tek bir dosyaya dışa aktarır. Dizüstü bilgisayar yenilemesinden önce kişisel yedek isteyen mühendisler için bu 30 saniye alır.

Kimlik Bilgisi Depolama ve Otomatik Giriş

SecureCRT, oturum başına kullanıcı adları ve şifreler depolamayı, şifreleri seçtiğiniz algoritmayla (AES-256) şifrelenmiş olarak destekler.

Otomatik giriş dizisi:

Kimlik bilgileri saklamanın ötesinde, SecureCRT giriş scriptleri veya otomatik giriş desenleri kullanarak giriş otomasyonunu destekler. Standart giriş dizisi olan cihazlar için (kullanıcı adı istemi → şifre istemi → isteğe bağlı etkinleştirme şifresi istemi), şunları yapılandırırsınız:

Oturum Özellikleri → Bağlantı → SSH2:
  Kullanıcı Adı: admin
  Şifre: [saklanmış, şifreli]

Oturum Özellikleri → Terminal → Emülasyon → Expect Scriptleri:
  "Username:" isteminde kullanıcı adı gönder
  "Password:" isteminde şifre gönder
  ">" isteminde etkinleştirme şifresi gönder

Yapılandırıldıktan sonra, bir oturum açmak otomatik olarak bağlanır ve giriş yapar. Yüzlerce cihaz yöneten bir ağ mühendisi için, kimlik bilgilerini tekrar tekrar yazmaktan kurtarılan zaman önemlidir — ancak daha da önemlisi, yanlış pencereye kimlik bilgisi yazma riskini ortadan kaldırır.

Kimlik bilgisi güvenliği hakkında bir not:

SecureCRT’nin şifre depolama özelliği, saklanan şifreleri şifrelemek için bir ana şifre (veya Windows kimlik bilgisi deposu entegrasyonu) kullanır. Şifreli şifre dosyası, ana şifre olmadan bir saldırgan için kullanışlı değildir. Katı kimlik bilgisi yönetimi politikalarına sahip ortamlar için SecureCRT, SSH anahtar tabanlı kimlik doğrulamayla da entegre olur — bu, yüksek güvenlikli ortamlarda saklanan şifrelerden tercih edilir.

Sekmeli Arayüz ve Çok Oturum Yönetimi

SecureCRT birden fazla oturumu tek bir pencere içinde sekmeler olarak görüntüler. Ağ geçişi sırasında 20 eş zamanlı oturumu yönetene kadar bu küçük bir şeymiş gibi görünür:

[core-sw-01] [core-sw-02] [dist-sw-01] [fw-birincil] [router-edge] [+]

Çok oturumlu çalışma için önemli özellikler:

Oturum döşemesi: Pencereyi birden fazla oturumu aynı anda görüntülemek için bölün. Bir yük devretme testi sırasında, biri aktif cihazı ve diğeri yedeği gösteren iki bölme isteyebilirsiniz — ikisini aynı anda izlemek.

Sekmede bağlan: Kaydedilmiş herhangi bir oturuma sağ tıklayın → “Sekmede Bağlan.” Yeni pencereler olmadan ihtiyaç duyduğunuz kadar oturum açın.

Birden fazla oturuma komut gönder: SecureCRT’nin “Sohbet Penceresi” ve “Tüm Sekmelere Gönder” özelliği, birden fazla oturuma aynı anda aynı komutu göndermeyi sağlar. Bir grup switch genelinde tutarlı bir değişiklik uygulamak için aynı komutu 10 kez yeniden yazmaya gerek yoktur.

Scripting ve Otomasyon

SecureCRT, VBScript, JScript ve Python destekli yerleşik bir scripting motoru içerir. Scriptler, terminal oturumuyla programatik olarak etkileşime girer — komutlar gönderir, çıktı okur, yanıtlara dayalı kararlar verir.

Scripting’in sağladıkları:

• Otomatik konfigürasyon yedekleme: cihaz listesine bağlanın, show running-config çalıştırın, çıktıyı cihaz başına bir dosyaya kaydedin
• Toplu konfigürasyon değişiklikleri: bir grup cihaz genelinde aynı değişikliği uygulayın, her birinin çıktısını loglayın
• Veri toplama: birden fazla cihazdan arayüz istatistikleri, yönlendirme tablosu girdileri veya VLAN bilgisi toplayın ve bir raporda derleyin
• Etkileşimli otomasyon: bir sonraki komutu göndermeden önce belirli çıktıyı bekleyen scriptler

Basit Python örneği — cihaz listesinden show version toplama:

# SecureCRT Python scripti
import time

def main():
    tab = crt.GetScriptTab()
    devices = ["10.0.0.1", "10.0.0.2", "10.0.0.3"]

    for device in devices:
        crt.Session.Connect("/SSH2 /L admin /PASSWORD pass " + device)
        tab.Screen.WaitForString("#")
        tab.Screen.Send("terminal length 0\n")
        tab.Screen.WaitForString("#")
        tab.Screen.Send("show version\n")
        tab.Screen.WaitForString("#")
        output = tab.Screen.ReadString("#")

        with open(f"C:\\logs\\{device}_version.txt", "w") as f:
            f.write(output)

        crt.Session.Disconnect()
        time.sleep(1)

main()

Daha karmaşık otomasyon için (tam ağ envanteri, konfigürasyon uyumluluk kontrolü, toplu VLAN değişiklikleri), Python ile birleştirilmiş SecureCRT scripting, tam bir Ansible veya Netmiko kurulumuna gerek kalmadan yetenekli bir otomasyon platformu sunar.

SecureFX Entegrasyonu

SecureFX, VanDyke’ın SFTP/FTP istemcisidir — ayrı satılır ancak SecureCRT ile sıkıca entegre edilmiştir. Entegrasyon şunlar için kullanışlıdır:

• Ağ cihazlarından yerel sunucuya konfigürasyon yedekleri aktarma
• Cihazlara yazılım yükleme
• Ağ cihazlarından merkezi bir depoya log dosyaları taşıma

SecureCRT içinden, aynı oturum kimlik bilgilerini kullanarak SecureFX’i başlatabilirsiniz — ayrı giriş gerekmez. Cisco IOS cihazları için, SecureCRT (CLI etkileşimi için) ve SecureFX (dosya aktarımı için) kombinasyonu tam operasyonel iş akışını kapsar.

Protokol Desteği

SecureCRT, bir ağ mühendisinin düzenli olarak kullandığı tüm protokolleri destekler:

• SSH1 / SSH2 — modern ağ cihazları için birincil protokol
• Telnet — eski cihazlar, lab ortamları
• Seri (COM portu) — ilk cihaz kurulumu veya kurtarma için konsol kablosu bağlantıları
• RDP — Uzak Masaüstü bağlantıları, Windows sunucularını aynı oturum yöneticisinde ağ cihazlarıyla birlikte yönetmek için kullanışlı
• SFTP / FTP (SecureFX entegrasyonu aracılığıyla)

Seri bağlantı desteği, ağ mühendisleri için özellikle değerlidir. Konsol kablosuyla bir cihaza bağlanmak, SSH ile aynı oturum yöneticisi arayüzünü kullanır — bir konsol oturumunu ve aynı cihaza birden fazla SSH oturumunu aynı anda açabilirsiniz, hepsi aynı pencerede.

SuperPutty: PuTTY Kullanıcılarının Bilmediği Ücretsiz Yükseltme

PuTTY’yi günlük kullanıyorsanız, SuperPutty’yi hiç duymamış olma ihtimaliniz yüksektir. Yeterince pazarlanmaz, arkasında büyük bir şirket yoktur ve ilk bakışta — başka bir PuTTY penceresi gibi görünür. Ancak PuTTY’nin kendisini değiştirmeden PuTTY’nin en büyük günlük kullanım sınırlılıklarını çözer.

SuperPutty Gerçekte Nedir

SuperPutty, PuTTY için bir oturum yöneticisi ve sekmeli arayüz sarmalayıcısıdır. PuTTY’nin yerini almaz — SuperPutty’nin çalışması için PuTTY kurulu olmalıdır. SuperPutty’nin eklediği şey, PuTTY’nin ciddi çok oturumlu çalışma için eksik olan her şeydir:

• Tek pencerede birden fazla PuTTY oturumuyla sekmeli arayüz
• Klasör organizasyonuyla kalıcı oturum kitaplığı
• Mevcut PuTTY oturumlarının içe aktarılması — mevcut yapılandırmanız kaybolmaz
• Döşenmiş düzen — birden fazla oturum aynı anda görünür
• Hızlı bağlantı çubuğu
• Oturum arama

Tamamen ücretsiz ve açık kaynaklıdır.

PuTTY Oturumlarınızı İçe Aktarma

SuperPutty kurulduktan sonra yapılacak ilk şey: mevcut PuTTY oturumlarınızı içe aktarın.

Tools → Import Sessions → From PuTTY Settings

SuperPutty, Windows Registry’den PuTTY oturum verilerini okur ve kendi oturum veritabanında ilgili oturumları oluşturur. Kaydedilmiş tüm ana bilgisayar adları, port ayarları ve bağlantı tercihleri otomatik olarak içe aktarılır. Sıfırdan başlamazsınız.

İçe aktarmadan sonra PuTTY oturumlarınız SuperPutty’nin oturum ağacında görünür — hemen kullanıma hazır. PuTTY kendisi normal şekilde çalışmaya devam eder; SuperPutty ve PuTTY bir arada bulunur.

Sekmeli Arayüz ve Oturum Organizasyonu

Oturumlar içe aktarıldıktan (veya doğrudan SuperPutty’de oluşturulduktan) sonra, bir cihaza bağlanmak onu sekme olarak açar:

[core-sw-01] [fw-birincil] [router-edge] [dist-sw-02] [+]

Oturumlar klasörlerde düzenlenebilir — SecureCRT’de kullandığınız aynı yapı, yalnızca ticari lisans maliyeti olmadan.

Döşenmiş düzen: SuperPutty pencereyi bir oturum bölmesi ızgarasına bölmeyi destekler. Birden fazla cihazı aynı anda izlediğiniz bakım pencereleri sırasında kullanışlıdır.

Otomatik yeniden bağlanma: SuperPutty, düşen oturumları otomatik olarak yeniden bağlayabilir — bağlantı zaman aşımlarının yaygın olduğu uzun süreli izleme oturumları için kullanışlıdır.

SuperPutty’nin Sahip Olmadığı Şeyler

Sınırlılıklar hakkında doğrudan olmak için:

• Otomatik loglama yok: SuperPutty oturumları otomatik olarak loglamaz. Her oturum için PuTTY’nin yerleşik loglamasını yapılandırabilirsiniz, ancak SecureCRT’nin özelliğine eşdeğer küresel “her şeyi otomatik logla” yoktur.
• Yerleşik scripting motoru yok: SuperPutty’nin SecureCRT’nin VBScript/Python scripting’ine eşdeğeri yoktur. Otomasyon için ayrı araçlar kullanırsınız (Netmiko, Paramiko, Ansible).
• Kimlik bilgisi şifrelemesi yok: SuperPutty, şifreleri SecureCRT’nin sağladığı şifreleme seçenekleri olmadan oturum veritabanında saklar. Katı kimlik bilgisi yönetimine sahip üretim ortamları için bu bir değerlendirmedir.
• Daha az cilalı: SuperPutty, gönüllüler tarafından sürdürülen bir açık kaynak projesidir. İyi çalışır, ancak ticari bir ürünün cilasından ve aktif geliştirmesinden yoksundur.

SecureCRT vs. SuperPutty: Ne Zaman Hangisi

SecureCRT kullanın:

• Otomatik oturum loglaması gerektiğinde (uyumluluk, olay müdahalesi)
• Otomasyon veya toplu işlemler için script çalıştırdığınızda
• Yüzlerce cihaz yönetiyor ve sağlam, güvenilir bir oturum yöneticisine ihtiyaç duyuyorsanız
• Organizasyonunuz şifreli kimlik bilgisi depolama gerektirdiğinde
• Oturum kayıtlarının zorunlu olduğu düzenlenmiş ortamlarda çalışıyorsanız

SuperPutty kullanın:

• Zaten PuTTY kullanıcısıysanız ve araçları değiştirmeden sekmeli oturumlar istiyorsanız
• Maliyet bir kısıtsa (bireysel kullanım, küçük ekip)
• Otomasyon ihtiyaçlarınız ayrı araçlar (Ansible, Netmiko) tarafından karşılanıyorsa
• Ticari bir araça bağlanmadan önce oturum yöneticisinin iş akışınızı iyileştirip iyileştirmediğini değerlendirmek istiyorsanız

Dürüst değerlendirme: Günlük üretim altyapısını yöneten çalışan bir ağ mühendisiyseniz, SecureCRT’nin otomatik loglaması tek başına lisans maliyetini haklı kılar. Oturum loglarının bir olay veya değişiklik sonrası inceleme sırasında tam olarak ihtiyaç duyulan kaydı sağladığı zamanların sayısı küçük değildir. SuperPutty, düz PuTTY üzerinde gerçek bir yükseltmedir ve hiçbir şeye mal olmaz — ancak loglama ve scripting’e güvenen mühendisler için SecureCRT’nin yerini tutmaz.

Pratik Kurulum: Günlük Kullanım için SecureCRT Yapılandırması

Günlük kullanımdan birkaç yapılandırma önerisi:

Küresel loglama kurulumu: Options → Global Options → Log File

Log dosya adı: C:\NetworkLogs\%H_%Y%M%D_%h%m%s.log
Bağlantıda:    Logu başlat
Log verisi:    Zaman damgaları dahil tüm oturum verisi

Oturum klasörü yapısı: En üst düzeyde müşteri veya ortama göre düzenleyin, ardından cihaz rolüne göre. Tutarlı adlandırma (çekirdek, dağıtım, erişim, firewall, router), yüzlerce oturum olsa bile gezinmeyi hızlı kılar.

Oturum grubu başına renk şemaları: SecureCRT, oturum veya klasör başına farklı terminal renk şemalarını destekler. Üretim ve lab ortamları için farklı bir renk kullanmak, yanlış pencere hatasını önler — lab’da olduğunuzu sanırken yanlışlıkla üretim cihazında komut çalıştırmak.

SSH anahtar kimlik doğrulaması: Üretim ortamları için, saklanan şifreler yerine SSH anahtar kimlik doğrulamasını yapılandırın: Oturum Özellikleri → Bağlantı → SSH2 → PublicKey Özel anahtar dosyanıza işaret edin. Anahtar bağlantıda otomatik olarak kullanılır — şifre istemi yok, saklanan şifre yok.

Anahtar sözcük vurgulama: Options → Global Options → Advanced → Keyword Sets %Error, down, FAIL, alarm gibi anahtar sözcükleri kırmızı görünecek şekilde yapılandırın. Kritik hata mesajları yoğun bir çıktı akışında hemen göze çarpar.

Temel Çıkarımlar

• Düz PuTTY işlevseldir ancak gerçek sınırlılıkları vardır — sekme yok, otomatik loglama yok, oturum taşınabilirliği yok.
• SecureCRT’nin otomatik loglaması, en operasyonel açıdan değerli özelliğidir — her oturum, her komut, her yanıt, ekstra adım gerektirmeden otomatik olarak zaman damgalı ve saklanmış.
• SecureCRT’de oturum taşınabilirliği, yeni bir dizüstü bilgisayara geçişin yeniden yapılandırma değil kopyalama işlemi olduğu anlamına gelir. Paylaşılan oturum veritabanları ekip tutarlılığı sağlar.
• Otomatik girişle kimlik bilgisi depolama, tekrarlayan yazmayı ortadan kaldırır ancak hassas ortamlarda ana şifre veya anahtar tabanlı kimlik doğrulamayla birleştirilmelidir.
• SecureCRT scripting’i, aksi takdirde ayrı bir araç gerektiren otomasyona olanak tanır — toplu işlemler ve konfigürasyon toplama için kullanışlı.
• SuperPutty doğru yanıttır — PuTTY’yi bilen ve sekmeli oturumlar, oturum organizasyonu ve PuTTY oturum içe aktarma isteyen mühendisler için — sıfır maliyetle.
• Şu an düz PuTTY kullanıyorsanız ve SuperPutty’yi hiç denemediyseniz: bugün kurun. Mevcut oturumlarınızı iki dakikada içe aktarın. Sekme arayüzü tek başına iş akışınızı değiştirecek.

İlgili Yazılar

• 🛠️ Ağın Arka Kapısı: Yeni Nesil Console Server Mimarisi — SSH başarısız olduğunda bant dışı erişim
• 🔐 802.1X Kimlik Tabanlı Mimari Sahada — SSH erişim kontrolünün arkasındaki kimlik doğrulama çerçevesi
• 📊 İzleme Doğru Yapıldığında — Manuel CLI çalışmasını proaktif izlemeyle tamamlamak

Kurumsal IT alanında çalışan herkes için yararlı bir düşünce deneyi: 2010 yılında bir şehirdeki konferans odasını başka bir şehirdeki konferans odasına bağlamak için ne gerekiyordu? Şimdi bugün ne gerektiğiyle karşılaştırın.

2010’da her iki uçta da özel bir codec cihazı, çağrı ayarlarını yapılandırmak için nitelikli bir video konferans mühendisi, sağlanmış bir ISDN hattı veya dikkatle yapılandırılmış IP altyapısı ve toplantıdan önce bağlantıyı test etmek için önemli bir hazırlık süresi gerekiyordu. Codec yazılım sürümleri uyuşmadıysa, firewall portları tam olarak doğru değilse veya karşı taraftaki IT ekibi yapılandırmasını farklı yapmışsa çağrı bağlanmıyordu.

Bugün, biri bir Webex veya Teams linki oluşturuyor, bunu bir takvim davetine ekliyor ve herkes bulunduğu yerden — dizüstü bilgisayar, telefon, özel toplantı odası sistemi — tek tıklamayla katılıyor. Toplantı odası donanımı otomatik olarak ne yapacağını biliyor.

Bu iki nokta arasında yaşananlar, son yirmi yılda kurumsal IT’deki en önemli mimari dönüşümlerden birini oluşturuyor. Bu yazı o dönüşümü izliyor.

Bölüm 1: IP Telefon Dönemi — Telefon Bir Ağ Cihazına Dönüştüğünde

Analogdan IP’ye Geçiş

IP telefondan önce, kurumsal telefon sistemleri PBX (Private Branch Exchange — Özel Şube Santrali) altyapısı üzerinde çalışıyordu — veri ağından tamamen ayrı, özel amaçlı donanım. IT ekibi veri ağını yönetiyordu; tesisler veya telefon ekibi PBX’i yönetiyordu. Bunlar paralel dünyalardı.

IP telefon bunu köklü biçimde değiştirdi. Telefon bir ağ uç noktasına dönüştü — özel bir ses devresine değil, veri ağına bağlanan IP adresi olan başka bir cihaz. PBX’in yerini standart donanım üzerinde çalışan bir çağrı işleme sunucusu aldı.

Cisco için bu, tüm çağrı yönlendirmeyi, çevirme planı yönetimini, sesli posta entegrasyonunu ve telefon sağlamayı yöneten Cisco Unified Communications Manager (CUCM) anlamına geliyordu. Bir Cisco IP telefonu açılıyor, TFTP aracılığıyla CUCM’den yapılandırmasını alıyor, SCCP veya SIP aracılığıyla CUCM’e kaydoluyor ve çağrı yapmaya hazır hale geliyordu — tamamen veri ağı üzerinden.

Pratikte CUCM Nasıl Görünüyordu

Tipik bir orta ölçekli kurumsal CUCM deployment’ı:

CUCM Publisher (birincil)
CUCM Subscriber x2 (yedeklilik için)
CUCM IM & Presence (anlık mesajlaşma)
Unity Connection (sesli posta)
Cisco Emergency Responder
Cisco IP Telefonlar (7900 serisi, 8800 serisi)

Çevirme planı — çağrıların nasıl yönlendirildiğini, hangi numaraların dahili olduğunu, hangilerinin trunk erişimi gerektirdiğini, diğer sitelere yapılan çağrıların nasıl işlendiğini belirleyen kurallar bütünü — tamamen CUCM yapılandırmasında yaşıyordu. Bu güçlüydü ama önemli bir uzmanlık gerektiriyordu. 3 ülkede 10 ofisi olan bir şirket için çevirme planı yüzlerce rota deseni, çeviri deseni, arama grubu ve çağrı yönlendirme kuralı içerebiliyordu.

CUCM yükseltmeleri başlı başına bir proje niteliğindeydi. Her büyük sürüm dikkatli yükseltme öncesi testler, bir bakım penceresi ve çoğunlukla bir geri alma planı gerektiriyordu. Cisco CUCM yükseltme süreci — sürümleri doğrulama, yükseltme sihirbazını çalıştırma, abone node’ların senkronize olmasını bekleme, tüm telefonların yeniden kaydolduğunu doğrulama — büyük bir küme için saatler alabiliyordu. Hazırlık adımlarını atlamanın sorunların başladığı yer olduğunu yeterince deneyimledim.

MPLS ve VPN: Çok Siteli Sesi Ücretsiz Kılmak

IP telefonun en zorlayıcı erken iş gerekçelerinden biri siteler arası aramayı oldu. Daha önce İstanbul ofisinden Ankara ofisine yapılan bir çağrı PSTN üzerinden gidiyordu — diğer çağrılar gibi dakika başına ücretlendiriliyordu.

Kurumsal WAN üzerinden IP telefonla aynı çağrı tamamen ağın içinde kalıyordu: İstanbul telefonu → İstanbul CUCM → MPLS/VPN bağlantısı → Ankara CUCM → Ankara telefonu. Sıfır PSTN maliyeti. Düzinelerce ofisi ve günlük yüzlerce siteler arası araması olan şirketler için bu tek başına IP telefon geçişini haklı kılıyordu.

MPLS bu dönemde baskın WAN teknolojisiydi — özel, düşük gecikmeli, öngörülebilir. MPLS siteleri hub-and-spoke veya tam örgü topolojisinde birbirine bağlıyor, ses trafiği kaliteli hizmet (QoS) açısından önceliklendiriliyordu.

IPsec VPN, MPLS’in çok pahalı olduğu küçük siteler için kullanılıyordu — bir şube ofisi genel merkezine internet üzerinden IPsec aracılığıyla bağlanabilir, merkezdeki CUCM şubedeki telefonlara hizmet verebilirdi.

Bunun için gereken yapılandırma küçümsenmeyecek boyuttaydı. QoS politikaları, ses trafiğinin geçtiği her ağ segmentinde tutarlı olmak zorundaydı. Codec seçimi (G.711 - G.729) çağrı kalitesini bant genişliği tüketimiyle dengelemek zorundaydı. Çağrı Kabul Kontrolü, çok fazla eş zamanlı aramanın bir WAN bağlantısını doyurmasını engellemek zorundaydı. Bunların tümü manuel olarak yapılandırılıyor, yönetilip gideriliyordu.

Bölüm 2: Video Sahneye Giriyor — Ve Beraberinde Karmaşıklık Getiriyor

Donanım Video Konferans Dönemi

Kurumlarda video konferans yazılımla başlamadı. Özel amaçlı codec cihazlarıyla başladı — video kodlama/kod çözmeyi yöneten, büyük ekranlara bağlanan ve H.323 veya SIP video protokollerini kullanan ISDN veya IP üzerinden iletişim kuran, özel amaçlı donanım.

Baskın satıcılar Cisco (TelePresence), Polycom ve Tandberg’di (Cisco 2010’da satın alarak teknolojisini TelePresence ürün hattına entegre etti).

Ürün hattının üst ucundaki Cisco TelePresence IX5000 toplantı odası sistemi, uzaktaki katılımcıların karşısında oturma hissini yaratmak için tasarlanmış üç ekranlı sürükleyici bir kurulumdu. Etkileyici bir mühendislikti. Aynı zamanda son derece pahalıydı: donanım tek başına oda başına yüz binlerce dolara çıkıyor, üstüne özel ağ altyapısı ve IT destek sözleşmeleri geliyordu.

Daha yaygın kullanılan orta segment sistemlerdi — Cisco SX80, Polycom Group Series, Tandberg C serisi uç nokta. Bunlar hâlâ özel donanımdı: bir codec birimi, bir veya iki ekran, bir kamera ve bir mikrofon dizisi. Her odanın kendi cihazı, kendi IP adresi, video altyapısına kendi kaydı vardı.

Videonun Arkasındaki Altyapı

Kurumsal video aramalarının çalışması için uç nokta donanımından daha fazlası gerekiyordu:

Cisco VCS (Video Communication Server): Video için çağrı kontrolü platformu — CUCM’nin video uç noktalar için eşdeğeri. VCS Expressway işletmeden işletmeye aramaları ve harici video bağlantısını yönetiyordu. VCS Control dahili uç noktaları yönetiyordu.

MCU (Multipoint Control Unit): İkiden fazla uç noktanın aynı video aramasında olması gerektiğinde, ses ve video akışlarını karıştırmak için MCU gerekiyordu. Cisco Codian MCU, daha sonra MSE 8000 serisi bunu yönetiyordu. Her MCU’nun belirli sayıda eş zamanlı port için lisansı vardı — MCU kapasitesinin tükenmesi daha fazla konferans köprüsü olmadığı anlamına geliyordu.

Harici bağlantı altyapısı: Kuruluşunuzun video altyapısının dışındaki birine arama yapmak, geçiş sunucuları, firewall geçiş yapılandırması ve çoğunlukla kuruluşlar arasında federasyon anlaşmaları gerektiriyordu.

Yapılandırma karmaşıklığı: 2012’de bir video konferans odası araması planlamak için şunları yapmanız gerekebilirdi: MCU konferans köprüsünü rezerve etmek, her uç nokta için çevirme dizisini yapılandırmak, önceki gün bağlantıyı test etmek, codec uyumluluğunu doğrulamak ve bir şeyler ters gittiğinde arama sırasında hazır bekleyen bir IT personeli bulundurmak.

Bu mühendislerin ne yaptıklarını bilmemesinden değildi — sistemin karmaşıklığı gerçekten bunu gerektiriyordu.

Kalite Sorunu

Bu dönemde internet üzerinden video görüşme de vardı — tüketiciler için Skype, çeşitli erken kurumsal araçlar. Ancak gerçek kalite gereksinimlerine sahip kurumsal organizasyonlar video için halka açık internete güvenmiyordu. Siteler arası aramalar için özel MPLS ağlarını ve harici aramalar için ISDN kullanıyorlardı. İnternet kalitesi öngörülemezdi, gecikme değişkendi ve paket kaybı video aramalarını izlenemez hale getiriyordu.

Bu iki katmanlı bir gerçeklik yarattı: resmi toplantılar için yüksek kaliteli, pahalı, altyapıya bağımlı video; gayri resmi kullanım için güvenilmez tüketici araçları. İkisi de tatmin edici değildi.

Bölüm 3: Bulut Geçişi — Her Şey Neden Taşındı

Tetikleyici: İnternet İyileşti

İş birliği altyapısının buluta göçü tek bir kararla veya teknoloji atılımıyla gerçekleşmedi. Halka açık internetin güvenilir biçimde sunabildiği şeylerdeki kademeli bir değişimle gerçekleşti.

İnternet bağlantıları hem kurumlarda (standart hale gelen 100 Mbps ile 1 Gbps WAN bağlantıları) hem de uzak çalışanlar için daha hızlı, güvenilir ve tutarlı hale geldikçe, özel ağ videosu ile internet tabanlı video arasındaki kalite farkı azaldı. Dizüstü bilgisayarlardaki yazılım istemcileri değişken ağ koşullarına uyum sağlamada daha iyi hale geldi. Video codec’leri (H.264, ardından VP9, ardından H.265) daha verimli oldu.

İnternet video kalitesi iş kullanımı için gerçekten kabul edilebilir hale geldiğinde hesap değişti. Pahalı şirket içi altyapı — CUCM kümeleri, VCS sunucuları, MCU köprüleri — zorunluluk yerine yük gibi görünmeye başladı.

Ekonomik Argüman

Şirket içi unified communications altyapısının önemli süregelen maliyetleri vardı:

• Sunucu donanımı yenileme döngüleri (her 4–5 yılda bir)
• Yazılım lisanslaması (kullanıcı başına, cihaz başına CUCM lisansları)
• Cisco ile destek sözleşmeleri (SmartNet)
• Sistemi yönetmek, yükseltmek ve sorunları gidermek için IT personeli
• Sunucular için veri merkezi alanı, güç ve soğutma

Bulut tabanlı iş birliği bunu kullanıcı başına aylık aboneliğe dönüştürdü. Donanım yenileme yok. Yükseltme projeleri yok. Otomatik özellik güncellemeleri. Azaltılmış IT operasyonel yükü.

500 çalışan ekleyen bir şirket için geleneksel model daha fazla CUCM sunucu kapasitesi, daha fazla lisans, daha fazla telefon satın almak anlamına geliyordu. Bulut modeli aboneliğe 500 lisans eklemek anlamına geliyordu.

Webex’in Dönüşümü

Cisco’nun Webex’i web konferans ürünü olarak başladı — çevrimiçi toplantılar için ekran paylaşımı ve ses. IP telefon dünyasından tamamen ayrıydı.

Cisco birkaç yıl içinde bu dünyaları sistematik olarak birleştirdi:

• Webex Meetings + CUCM entegrasyonu: kullanıcılar Cisco IP telefonlarından video aramalar başlatabiliyordu
• Webex Teams (şimdi Webex App): ekip mesajlaşması ve arama birleşti
• Webex Calling: birçok organizasyon için şirket içi CUCM’nin yerini alan bulut tabanlı arama hizmeti — çevirme planları, sesli posta, dahili numaralar, tümü bulutta yönetiliyor
• Birleşik Webex App: arama, toplantılar, mesajlaşma ve dosya paylaşımı için tek uygulama

Sonuç: Daha önce şirket içinde CUCM, video için VCS ve sesli posta için Unity Connection’a sahip bir şirket, Webex Calling’e geçerek üçünün de yerine geçen tek bir bulut hizmeti kullanabiliyordu — web portalı üzerinden yönetilen, bakım yapılacak sunucu yok.

Bölüm 4: Çok Platformlu Gerçeklik — Teams, Zoom ve Diğerleri

Microsoft Teams: Rakip

Microsoft Teams 2017’de bir Slack rakibi olarak piyasaya çıktı. Üç yıl içinde baskın kurumsal iş birliği platformu haline geldi — her boyutuyla teknik açıdan üstün olduğu için değil, zaten orada olduğu için. E-posta ve Office uygulamaları için Microsoft 365 kullanan organizasyonlar Teams’i dahil olarak aldı. Ayrı tedarik, yeni satıcı ilişkisi, ek IT altyapısı gerektirmiyordu.

Teams, PSTN arama özelliği ekledi (Teams Phone, eski adıyla Phone System) — organizasyonların PBX’lerini Teams ile değiştirmesine, Microsoft bulutu aracılığıyla normal telefon aramaları yapıp almasına olanak tanıdı.

Birlikte çalışabilirlik sorusu: Farklı organizasyonlardan bir Webex kullanıcısı ve bir Teams kullanıcısı video toplantısı yapmak istiyor. Her ikisi de kendi platformuna sahip. Nasıl bağlanırlar?

Başlangıçta yanıt “bir platform diğerini misafir olarak davet eder"di — işe yarıyordu ama sorunsuz değildi. Bu durum önemli ölçüde gelişti. Cisco ve Microsoft, Webex ile Teams arasında doğrudan birlikte çalışabilirlik geliştirdi. Bir Cisco toplantı odası sistemi Teams toplantısına yerel olarak katılabilir. Teams kullanıcısı herhangi bir şey yüklemeden Webex toplantısına katılabilir.

Zoom: Sadelik Hamlesi

Zoom, 2020 yılında kurumsal farkındalığa önemli ölçüde girdi. Teknik güçleri — değişken internet bağlantıları üzerinde gerçekten güvenilir video kalitesi, misafirler için hesap gerektirmeyen basit katılım deneyimi — mevcut araçları yetersiz kalan organizasyonlar için çekici hale getirdi.

Zoom’un gösterdiği şey, kullanım kolaylığının özellik derinliği kadar önemli olduğuydu. “Sadece linke tıkla” deneyimi, tüm iş birliği araçları için standart beklenti haline geldi.

Avaya, 3CX ve Orta Pazar

Her organizasyon Cisco veya Microsoft ölçeğine ihtiyaç duymuyordu. Orta pazarın kendi oyuncuları var:

Avaya on yıllardır önemli bir kurumsal telefon satıcısı olmuştur — Aura platformu kurumsal deployment ölçeğinde CUCM ile rekabet eder. Avaya son yıllarda önemli finansal zorluklardan geçti (birden fazla iflas başvurusu), bu da platformundaki müşteriler için belirsizlik yarattı.

3CX, yazılım tabanlı bir PBX olarak KOBİ ve orta pazarda popüler hale geldi — Windows veya Linux’a kurulabilir, CUCM lisanslamasından düşük maliyetli, makul özellik seti.

RingCentral, 8x8, Vonage (şimdi Ericsson): Platformlarını başından beri bulutta inşa etmiş, şirket içi miras olmayan bulut tabanlı UCaaS sağlayıcıları.

Bölüm 5: Modern Toplantı Odası

En Çok Ne Değişti

Toplantı odası, dönüşümün en görünür olduğu yerdir. Karşılaştırın:

2012 toplantı odası:

• Özel codec (Cisco SX80 veya Polycom Group): 15.000–50.000 dolar
• Duvara monte büyük ekran(lar)
• Pan-tilt-zoom kamera, tavan veya masa üstü mikrofon dizisi
• IT tarafından yönetilen altyapı kaydı
• Harici aramaya katılmak: çevirme dizisini araştırın, manuel girin, karşı tarafın doğru cevap vermesini umun
• Webex veya Skype toplantısına katılmak: mümkün ama belirli yapılandırma gerektiriyordu ve çoğunlukla güvenilir biçimde çalışmıyordu

2024 toplantı odası:

• Toplantı odası sistemi (Cisco Room Bar, Webex Board, Logitech Rally Bar, Poly Studio): 1.500–8.000 dolar
• Tek dokunuşla katılım: toplantı odası ekranı yaklaşan takvim toplantılarını gösteriyor; katılmak için dokunun
• Webex, Teams, Zoom ile çalışıyor — çoğunlukla bir yazılım ayarıyla üçü birden
• Toplantıya katılmak için IT müdahalesi gerekmiyor
• Herhangi bir dizüstü bilgisayardan kablosuz içerik paylaşımı
• AI özellikleri: gürültü engelleme, arka plan bulanıklaştırma, aktif konuşmacıyı takip eden otomatik çerçeveleme

Maliyet azalması önemlidir. Operasyonel sadelik iyileşmesi dönüştürücüdür.

Webex Board ve Akıllı Tahta Özellikleri

Cisco’nun Webex Board’u (şimdi Webex Desk ve Room ürün hattının bir parçası), bağımsız video konferansın hiçbir zaman sahip olmadığı bir özellik ekledi: dijital tahta.

Webex Board aynı anda dokunmatik ekran, video konferans sistemi ve tahta. Bir toplantıda katılımcılar doğrudan tahta yüzeyine çizebilir. Uzak katılımcılar tahtayı gerçek zamanlı görür. Toplantı sırasında tahtaya yazılan içerik otomatik olarak kaydedilir ve toplantı sonrasında dosya olarak paylaşılır.

Logitech’in Etkisi

Logitech, kurumsal toplantı odası pazarına tüketici çevre birimi tarafından girdi ve ciddi bir oyuncu haline geldi. Rally Bar ve Rally Bar Mini sistemleri, kamerayı entegre hoparlör ve mikrofonla birleştiren bar biçimli sistemler — bir ekranın üstüne veya altına yerleştirilmek üzere tasarlandı.

Önem: kurumsal düzeyde toplantı odası özelliği, tüketici düzeyinde fiyatlandırmayla. Microsoft Teams veya Zoom Rooms sertifikalı bir Logitech Rally Bar, Cisco veya Poly toplantı odası sisteminin çok altında bir fiyata mal oluyor. Onlarca küçük toplantı odası donatmak isteyen organizasyonlar için bu fiyat noktası, daha önce ekonomik olmayan her odayı donatmayı mümkün kılıyor.

Bölüm 6: CUCM Yükseltmeleri — Pratik Bir Not

Şirket içinde Cisco CUCM çalıştıran organizasyonlar için yükseltmeler hâlâ önemli bir operasyonel olaydır. Birden fazla büyük sürüm yükseltmesinden geçmiş biri olarak birkaç gözlem:

Hazırlık, asıl işin kendisidir. Yanlış giden bir CUCM yükseltmesi neredeyse her zaman atlanan bir hazırlık adımına kadar izlenebilir. Her yükseltmeden önce:

• Tüm uç noktaların hedef CUCM sürümü için desteklenen yazılımı çalıştırdığını doğrulayın
• Tüm özel yapılandırmaları belgeleyin (CTI yol noktaları, arama grupları, çeviri desenleri)
• Mümkünse lab ortamında yükseltme sonrasında çevirme planı işlevini test edin
• Yedeklemenin tamamlandığını ve geri yüklenebilir olduğunu doğrulayın

Önce Publisher, sonra subscriber’lar. Yükseltme sırası önemlidir. CUCM Publisher önce yükseltilir. Subscriber’lar Publisher tam olarak yükseltilip sağlıklı olana kadar eski sürümde kalır, ardından her Subscriber sırayla yükseltilir.

Yükseltme sonrası doğrulama. Her subscriber yükseltmesinden sonra: tüm telefonların yeniden kayıt olduğunu doğrulayın, gelen ve giden PSTN aramalarını test edin, siteler arası aramaları test edin, sesli posta entegrasyonunu doğrulayın. Tüm çağrı yolları doğrulanana kadar başarı ilan etmeyin.

Geçiş yolu: Eski CUCM sürümlerindeki pek çok Cisco müşterisi, Cisco’nun şirket içi CUCM’nin bulut yedeği olan Webex Calling’e yönlendiriliyor. Geçiş, telefon numaralarını taşımayı, çevirme planı mantığını bulutta yeniden oluşturmayı ve Webex App’i softphone istemcisi olarak kullanıma almayı içeriyor.

Bugünkü Durum

Kurumsal iş birliği pazarı, on yıl önce olası görünmeyecek birkaç şeyde birleşti:

Önce yazılım: Çoğu kullanıcı için birincil arayüz fiziksel bir telefon değil, Webex App, Teams, Zoom gibi bir yazılım istemcisi.

Bulut tabanlı operasyonlar: Yeni deployment’lar büyük ölçüde bulut tabanlı. Şirket içi CUCM buna sahip organizasyonlar tarafından sürdürülüyor, ancak yeni deployment’lar artık nadiren UCaaS alternatiflerinden önce bunu tercih ediyor.

Temel olarak birlikte çalışabilirlik: İş birliği sisteminizin diğer organizasyonların sistemleriyle — platform ne olursa olsun — iletişim kurabilmesi beklentisi artık standart.

Toplantı odası sistemleri erişilebilir teknoloji olarak: Toplantı odası sistemleri, herhangi bir önceki noktadan daha basit şekilde kullanıma alınır, kullanılır ve bakımı yapılır hale geldi.

Özelleşmiş bir Cisco iş birliği mühendisinin yapılandırıp bakımını yaptığı altyapının yerini büyük ölçüde genel amaçlı bir IT yöneticisinin işletebileceği yönetilen bulut hizmetleri aldı. Bu eski altyapının eleştirisi değil — zamanında gerçekten gelişmiş bir mühendisliğin ürünüydü. Altta yatan karmaşıklığın ne kadar soyutlandığının gözlemidir.

CUCM, Expressway, TelePresence ve tam Cisco iş birliği yığını üzerine kariyer inşa eden mühendisler için: o bilgi değersiz hale gelmedi. Mimari düşünme — çevirme planlarının nasıl çalıştığı, çağrı yönlendirme mantığının nasıl yapılandırıldığı, QoS’un ses kalitesi için ne anlama geldiği, codec seçiminin neden önemli olduğu — doğrudan şirket içi altyapının yerini alan bulut platformlarını anlamaya aktarılır. Uygulama detayları değişti. Prensipler değişmedi.

Temel Çıkarımlar

• IP telefonun orijinal iş gerekçesi, MPLS/VPN aracılığıyla siteler arası aramalarda maliyet azaltmaktı — bu tek başına pek çok kurumsal PBX’ten IP telefona geçişi haklı kıldı.
• Donanım video konferans kalite sundu ancak muazzam altyapı maliyeti ve operasyonel karmaşıklıkla — yaygın benimsemenin önündeki darboğaz.
• Bulut iş birliği, internet kalitesi yeterince iyileştiğinde ve şirket içi altyapıyla ekonomik karşılaştırma kesin olarak değiştiğinde uygulanabilir hale geldi.
• Webex, bir toplantı aracından CUCM, VCS ve Unity Connection’ın tek bir bulut hizmetinde yerini alan tam bir UCaaS platformuna dönüştü.
• Teams, saf teknik üstünlük değil dağıtım avantajıyla pazarı dönüştürdü — Microsoft 365 çalıştıran organizasyonlarda zaten deploy edilmişti.
• Toplantı odası donanımı, herhangi bir organizasyonun ölçekte kullanıma alabileceği 3.000 dolarlık erişilebilir barlara dönüşerek 30.000 dolar+ özel sistemlerden çıktı.
• CUCM yükseltmeleri, hâlâ şirket içinde bulunan organizasyonlar için önemli operasyonel olaylar olmaya devam ediyor — hazırlık ve sıra, yükseltmenin kendisinden daha önemli.
• Platformlar arası birlikte çalışabilirlik artık beklenen, istisnai değil — Webex odaları Teams toplantılarına katılıyor, Teams kullanıcıları Webex toplantılarına katılıyor.

İlgili Yazılar

• 🔐 Zero Trust Zihniyeti: Güvenliği Bir Mimari Olarak Mühendislemek — Bulut iş birliği ortamları için güvenlik mimarisi
• 🏗️ IT Altyapısı Ürünler Koleksiyonu Değildir — İş birliği platformları için de geçerli sistem düşüncesi
• 📊 İzleme Doğru Yapıldığında — İş birliği altyapısını proaktif olarak izleme
• 🔧 SecureCRT ve SuperPutty — İş birliğinin üzerinde çalıştığı şirket içi altyapıyı yönetmek için araçlar

Bu yazı F5 BIG-IP serisinin bir parçasıdır.

F5’e yeni misiniz? Önce platform genel bakışıyla başlayın: F5 BIG-IP Bir Load Balancer Değil — Uygulama Teslim Platformudur

Büyük resmi zaten biliyorsanız ve LTM’e derinlemesine inmek istiyorsanız — yapılandırma, iRule’lar, migrasyon saha notları — doğru yerdesiniz.

Full-Proxy Mimarisi: Neden Her Şeyi Değiştirir

LTM hakkında anlaşılması gereken en önemli şey, bunun bir full-proxy olduğudur. Bu bir pazarlama terimi değildir — LTM’yi her türlü daha basit load balancer’dan ayıran doğrudan operasyonel sonuçları vardır.

Bir istemci F5 LTM üzerinden bağlandığında, iki tamamen ayrı TCP bağlantısı oluşur:

İstemci ──[TCP bağlantı 1]──→ F5 LTM ──[TCP bağlantı 2]──→ Backend Sunucu
          (Virtual Server IP)            (Pool Member IP)

F5 istemci bağlantısını tamamen sonlandırır, inceler, tüm yönlendirme ve politika kararlarını verir, ardından backend’e yeni bir bağlantı açar. İstemci ve backend sunucusu hiçbir zaman doğrudan iletişim kurmaz.

Bu, pass-through load balancer’ların sağlayamadığı yetenekler sunar:

• İstek ve yanıtın her baytına tam görünürlük
• Trafiğin herhangi bir bölümünü yeniden yazabilme — başlıklar, URI’ler, çerezler, yanıt gövdeleri
• Backend’ler adına SSL sonlandırma — backend’ler düz HTTP görür
• İstemci taraflı ve sunucu taraflı bağlantılar için bağımsız TCP ayarı
• Bağlantı çoğullaması ve HTTP pipelining optimizasyonları

Pratikte, full-proxy konumu, yukarı akış sorunlarının (istemci tarafı) ve aşağı akış sorunlarının (sunucu tarafı) tamamen izole edildiği anlamına gelir. Bu, üretim olaylarında sorun gidermeyi önemli ölçüde basitleştirir.

Virtual Server’lar: Giriş Noktası

Virtual Server, istemcilerin bağlandığı IP adresi ve port kombinasyonudur. LTM’deki birincil nesnedir ve tüm trafik politikasının kapsayıcısıdır:

Virtual Server: vs_webapp_443
  Hedef IP:           10.10.1.100
  Port:               443
  Protokol:           TCP
  HTTP Profili:       http_profile_xforward
  SSL İstemci Profili: clientssl_webapp
  SSL Sunucu Profili: serverssl_backend
  Varsayılan Pool:    pool_webapp_8080
  Persistence:        cookie_persistence
  iRule:              /Common/rule_uri_routing

Bir VIP, birden fazla uygulama: Tek bir virtual server IP’si, HTTP Host başlığına veya URI yoluna göre yönlendirme yapmak için iRule’lar kullanarak birden fazla uygulamaya hizmet verebilir. Bu, IP tüketimini azaltır ve yukarı akış firewall kurallarını basitleştirir.

Virtual server durumu pool sağlığından bağımsızdır: Bir virtual server devre dışı bırakılırsa, pool member’ların sağlıklı olup olmadığına bakılmaksızın hiçbir trafik pool’a ulaşmaz. Virtual server kullanılabilirliğini, pool member kullanılabilirliğinden ayrı olarak her zaman izleyin.

Üç virtual server türü:

• Standard — full proxy, en yaygın tür
• Performance Layer 4 — L7 incelemesinin gerekmediği yüksek verimli senaryolar için proxy’yi atlar
• Forwarding — proxy davranışı olmadan pass-through yönlendirme, şeffaf deployment’larda kullanılır

Pool’lar ve Load Balancing Yöntemleri

Pool, virtual server’ın trafiği dağıttığı backend sunucuları grubudur:

Pool: pool_webapp_8080
  Load Balancing Yöntemi: Least Connections (member)
  Slow Ramp Time:         30 saniye
  Monitor:                http_monitor_webapp
  Member'lar:
    192.168.10.11:8080   Öncelik Grubu: 1
    192.168.10.12:8080   Öncelik Grubu: 1
    192.168.10.13:8080   Öncelik Grubu: 2  ← yedek, yalnızca grup 1 başarısız olursa etkinleşir

Load balancing yöntemleri karşılaştırması:

• Round Robin — sıralı dağılım. Durumsuz, tekdüze iş yükleri için çalışır. Bağlantı süreleri önemli ölçüde farklılaştığında kötü seçimdir.
• Least Connections (member) — en az aktif bağlantıya sahip member’a gönderir. Değişken oturum süreleri olan uygulamalar için en iyisi. Çoğu üretim ortamında standart seçim.
• Least Connections (node) — yalnızca bu pool değil, bir sunucu IP’sine tüm pool’lardaki bağlantıları sayar. Bir sunucu birden fazla pool’a katıldığında kullanın.
• Ratio — ağırlıklı dağılım. A member’ı, B member’ından 3× daha fazla bağlantı alır. Farklı kapasitelere sahip sunucular için.
• Fastest — en son yanıt veren member’a gönderir. Sıcak nokta oluşturabilir; daha fazla kararlılık için bunun yerine Observed kullanın.

Slow Ramp Time az kullanılır ama önemlidir. Bir pool member başarısızlıktan kurtulduğunda hemen kullanılabilir hale gelir — ancak tam olarak hazır olmayabilir (JVM, cache’ler, veritabanı bağlantı havuzları). Slow Ramp Time, yeni kullanılabilir bir member’ın ağırlığını belirtilen saniyeler boyunca kademeli olarak artırır ve soğuk bir sunucunun anında aşırı yüklenmesini önler.

Öncelik Grupları, tek bir pool içinde aktif ve yedek member setlerine olanak tanır. Grup 1 member’ları, minimum aktif member eşiğinin üzerindeyken tüm trafiği alır. Grup 2 member’ları, Grup 1 eşiğin altına düştüğünde otomatik olarak etkinleşir.

Health Monitor’lar: Load Balancing Yönteminden Daha Önemli

Bir pool member, TCP erişilebilir ve uygulama düzeyinde tamamen bozuk olabilir. Her istekte HTTP 500 döndüren bir ödeme işleme sunucusu hâlâ TCP erişilebilirdir — temel bir TCP monitor sorunu hiçbir zaman tespit etmez.

Bu, üretim ortamlarında gördüğüm en yaygın başarısızlık senaryosudur ve ekiplerin en sık yetersiz yatırım yaptığı yerdir.

TCP Monitor: Gerekli ama Yetersiz

Monitor: tcp_monitor_basic
  Tür:      TCP
  Interval:  5 saniye
  Timeout:   16 saniye

Tespit eder: ağ bağlantı kaybı, sunucu çöküşleri, port dinlenmiyor.

Tespit etmez: uygulama hataları, veritabanı bağlantı başarısızlıkları, bellek tükenmesi, kısmen başlatılmış uygulama durumları.

HTTP Monitor: Üretim Standardı

Monitor: http_monitor_webapp
  Tür:            HTTP
  Send String:    GET /health HTTP/1.1\r\nHost: webapp.internal\r\nConnection: close\r\n\r\n
  Receive String: "status":"healthy"
  Interval:       5 saniye
  Timeout:        16 saniye

LTM, yalnızca yanıt gövdesi tam olarak beklenen dizeyi içerdiğinde member’ı UP olarak işaretler. Uygulama, yalnızca portun açık olduğunu değil, sağlıklı olduğunu aktif olarak onaylamalıdır.

İyi bir /health endpoint’i şunları kontrol eder: veritabanı bağlantısı, cache kullanılabilirliği, kilit bağımlılık durumu ve ilgiliyse disk alanı. {"status":"degraded"} ile HTTP 200 döndüren bir uygulama, monitor kontrolünü başarısız kılmalıdır.

Şifreli Backend’ler için HTTPS Monitor

Monitor: https_monitor_webapp
  Tür:         HTTPS
  SSL Profili:  serverssl_monitor (dahili olarak öz imzalı sertifikaları kabul edecek şekilde yapılandırın)
  Send String:  GET /health HTTP/1.1\r\nHost: webapp.internal\r\n\r\n
  Receive String: "status":"healthy"

Timeout Formülü

Sık yapılan bir yanlış yapılandırma: timeout değerini interval’e eşit veya daha küçük ayarlamak. Doğru formül:

Timeout = (Interval × yeniden deneme sayısı) + 1

Interval=5 ve 3 yeniden denemeyle: Timeout = 16. Bu, geçici ağ dalgalanmalarından kaynaklanan yanlış pozitifleri önlemek için LTM’ye member’ı düşürmeden önce yeniden deneme zamanı verir.

SSL Offloading ve SSL Bridging

SSL Offload (Yalnızca İstemci SSL)

İstemci ──(HTTPS/TLS 1.3)──→ F5 LTM ──(HTTP)──→ Backend

F5, istemciden TLS’yi sonlandırır ve şifrelenmemiş HTTP’yi backend’lere iletir. Maksimum backend CPU tasarrufu. Virtual server’da bir İstemci SSL Profili gerektirir:

İstemci SSL Profili: clientssl_webapp
  Sertifika:   /Common/webapp_cert
  Anahtar:     /Common/webapp_key
  Zincir:      /Common/intermediate_ca
  Şifreler:    TLSv1.2:TLSv1.3
  Seçenekler:  TLSv1 Yok, TLSv1.1 Yok

SSL Bridging (İstemci + Sunucu SSL)

İstemci ──(HTTPS/TLS 1.3)──→ F5 LTM ──(HTTPS/TLS)──→ Backend

F5 şifresini çözer, inceler, ardından backend için yeniden şifreler. Uyumluluk gereksinimlerinin uçtan uca şifrelemeyi zorunlu kıldığı düzenlenmiş ortamlarda (bankacılık, sağlık) gereklidir. Bağlantı başına iki TLS el sıkışması nedeniyle biraz gecikme ekler — ancak tam uyumluluk ve görünürlük sağlar.

Bankacılık ortamında, tüm üretim virtual server’ları SSL bridging çalıştırıyordu. Her bağlantı şifresi çözülüyor, WAF tarafından inceleniyor ve backend’e yeniden şifreleniyordu.

Sertifika Yönetimi

Temel operasyonel noktalar:

• F5, sertifikalar sona erme tarihine yaklaştığında varsayılan olarak uyarı vermez. Virtual server’lardaki sertifika süresini kontrol etmek için harici izleme (SolarWinds, Zabbix) kurun.
• Sertifika değiştirme sıfır downtime ile yapılır: sertifika nesnesini güncelleyin, profil buna otomatik olarak referans verir.
• SNI, tek bir VIP’nin farklı sertifikalara sahip birden fazla uygulamaya hizmet vermesine olanak tanır.

Session Persistence

Cookie Persistence (Önerilen)

F5, HTTP yanıtına pool member’ı tanımlayan bir çerez ekler:

Persistence Profili: cookie_persistence
  Yöntem:      Insert
  Çerez Adı:   BIGipServer_webapp
  Son Kullanma: Session
  Şifrele:     Etkin

Sonraki isteklerde, tarayıcı bu çerezi gönderir. F5, mevcut yük dağılımından bağımsız olarak doğru member’a yönlendirir. Uygulamaya şeffaf, NAT üzerinden çalışır, istemci IP değişikliklerine dayanır.

Kaynak Adres Persistence

Aynı istemci IP’sinden gelen tüm trafiği aynı member’a yönlendirir:

Persistence Profili: source_addr_persistence
  Timeout: 3600 saniye

Basit, ancak birçok kullanıcı bir NAT IP’yi paylaştığında sorunlu — aynı NAT arkasındaki tüm kullanıcılar aynı backend sunucusuna gider, yük dağılımını bozar.

iRule Tabanlı Evrensel Persistence

Özel oturum tanımlayıcıları için (standart dışı çerezler, URL parametreleri, özel başlıklar):

when HTTP_REQUEST {
  persist uie [HTTP::header "X-Session-Token"]
}

Özel bir başlık değerine göre kalıcı hale getirir — hiçbir standart profilin desteklemediği bir şey.

iRule’lar: Programlanabilir Trafik Katmanı

iRule’lar, TMOS veri düzleminde hat hızında çalışan Tcl tabanlı betiklerdir. En güçlü LTM farklılaştırıcısıdır — aksi takdirde uygulama kodu değişikliği gerektiren trafik mantığı.

Olay Modeli

iRule’lar, trafik yaşam döngüsündeki olaylarda çalışır:

• HTTP_REQUEST — istemciden tam HTTP isteği alındı
• HTTP_RESPONSE — backend’den yanıt alındı
• CLIENT_ACCEPTED — istemciden TCP bağlantısı kuruldu
• SERVER_CONNECTED — F5 backend’e bağlandı
• SSL_HANDSHAKE_START — TLS müzakeresi sırasında

Üretim iRule Örnekleri

Backend’e istemci IP iletimi:

when HTTP_REQUEST {
  HTTP::header insert "X-Forwarded-For"   [IP::client_addr]
  HTTP::header insert "X-Real-IP"         [IP::client_addr]
  HTTP::header insert "X-Forwarded-Proto" "https"
}

URI tabanlı pool yönlendirmesi:

when HTTP_REQUEST {
  if { [HTTP::uri] starts_with "/api/v2/" } {
    pool pool_api_v2_servers
  } elseif { [HTTP::uri] starts_with "/api/" } {
    pool pool_api_v1_servers
  } elseif { [HTTP::uri] starts_with "/admin/" } {
    pool pool_admin_servers
  } else {
    pool pool_web_servers
  }
}

Pool boşken bakım yönlendirmesi:

when HTTP_REQUEST {
  if { [active_members pool_webapp_8080] < 1 } {
    HTTP::redirect "https://status.sirket.com/bakim"
  }
}

Host başlığı tabanlı yönlendirme — bir VIP’de birden fazla uygulama:

when HTTP_REQUEST {
  switch [HTTP::host] {
    "uygulama1.sirket.com" { pool pool_app1 }
    "uygulama2.sirket.com" { pool pool_app2 }
    "api.sirket.com"       { pool pool_api  }
    default                { pool pool_default }
  }
}

İstemci IP’ye göre bağlantı hızı sınırlaması:

when CLIENT_ACCEPTED {
  set conn_limit 50
  if { [table lookup -notouch [IP::client_addr]] > $conn_limit } {
    reject
  } else {
    table incr [IP::client_addr]
    table timeout [IP::client_addr] 60
  }
}

iRule Performans Notları

iRule’lar, virtual server üzerinden her bağlantı veya istek için çalışır. Yönergeler:

• Yüksek trafikli iRule’larda karmaşık dize işlemlerinden kaçının — hesaplanan değerleri önbelleğe almak için table kullanın
• Sözdizimi hatası tüm iRule’u sessizce devre dışı bırakır — önce staging ortamında test edin
• Üretimde log local0.debug kullanımını sınırlayın — aşırı loglama performansı etkiler
• RULE_INIT olayı başlangıçta bir kez çalışır ve paylaşılan veri yapılarını başlatmak için idealdir

High Availability: Üretimde Aktif-Yedek

Cihaz Grupları ve Trafik Grupları

F5 HA, Cihaz Güveni (eşler arasında karşılıklı kimlik doğrulama) ve Cihaz Grupları (sync-failover yapılandırması) kullanır:

Cihaz Grubu: dg_production
  Tür:     sync-failover
  Member'lar: bigip-01 (Aktif), bigip-02 (Yedek)

Trafik Grubu: traffic-group-1
  Floating IP'ler: 10.10.1.100 (VIP), 10.10.1.1 (self IP)
  Aktif on:        bigip-01

Trafik Grupları, failover sırasında cihazlar arasında geçiş yapan floating IP’leri içerir. bigip-01 başarısız olduğunda, bigip-02 traffic-group-1’in sahipliğini alır ve gratuitous ARP aracılığıyla VIP’yi duyurur.

Özel Heartbeat VLAN: Zorunlu

F5 HA, ağ failover kullanır — cihazlar arasındaki heartbeat paketleri eş başarısızlığını tespit eder. Kritik kural:

Üretim ve yönetim ağlarından ayrı, her zaman özel bir failover VLAN kullanın.

Heartbeat için üretim arayüzünü paylaşmak, ağ tıkanıklığı sırasında yanlış failover olayları oluşturur. Her iki cihaz da diğerinin başarısız olduğuna inanır ve her ikisi de aynı anda aktif hale gelir — split-brain. Trafik çoğaltılır, oturumlar bozulur ve olaydan kurtulmak zahmetlidir.

Failover VLAN: vlan_ha_heartbeat
  Arayüz:            1.3 (özel)
  bigip-01 self IP:  192.168.100.1/24
  bigip-02 self IP:  192.168.100.2/24

Config Sync: Manuel - Otomatik

Otomatik sync — aktif cihazda yapılan değişiklikler anında yedek cihaza yayılır. Risk: kısmi veya yanlış bir yapılandırma değişikliği inceleyemeden önce yayılır.

Manuel sync — yönetici değişiklikleri doğruladıktan sonra sync’i açıkça tetikler. Üretim için daha güvenli. Düzenlenmiş ortamlarda standart seçim.

Bağlantı Yansıtma

Varsayılan olarak, failover tüm mevcut bağlantıları düşürür — istemcilerin yeniden bağlanması gerekir. Çoğu web uygulaması için bu kabul edilebilirdir.

Uzun süreli bağlantılar için (kalıcı WebSocket’ler, büyük dosya transferleri, veritabanı bağlantıları), bağlantı yansıtma yedek cihazda oturum durumunu korur. Failover bu bağlantıları minimum kesinti ile sürdürür.

Bağlantı yansıtmayı seçici olarak etkinleştirin — her iki cihazda da bellek ve CPU tüketir. Her virtual server buna ihtiyaç duymaz.

Saha Notları: 2000 → 5000 Migrasyonu

Neden Migrasyon Yaptık

BIG-IP 2000 serisi, bankacılık yoğun saatlerinde SSL offloading tavanına ulaşmıştı. TMOS 13.x destek sonuna yaklaşıyordu. 5000 serisi, donanım SSL hızlandırması, 6× verim iyileştirmesi ve TMOS 15.x aracılığıyla TLS 1.3 desteği sunuyordu.

Sıfır Downtime Yaklaşımı: 30+ Cihaz, 0 Kesinti

Faz 1 — Paralel deployment 5000 serisi donanımı mevcut 2000 serisi yanına kurun. Yeni cihazlarda özdeş virtual server’lar, pool’lar, profiller ve iRule’lar yapılandırın. Henüz sıfır trafik.

Faz 2 — Kritik olmayan virtual server üzerinde doğrulama Tek bir dahili uygulamayı yeni cihaza yönlendirin. 72 saat izleyin: bağlantı oranları, SSL el sıkışma gecikmesi, health monitor davranışı, iRule yürütme logları, sentetik yük altında HA failover testi.

Faz 3 — İş riski bazında kademeli migrasyon Virtual server’ları gruplara göre taşıyın — önce dahili araçlar, sonra genel uygulamalar, en son ödeme işleme. Her grup için:

• Yeni cihaza işaret etmek üzere yukarı akış yönlendirme / SNAT’ı güncelleyin
• 48 saat izleyin
• Grup başına 72 saat eski cihazı geri alma seçeneği olarak tutun

Faz 4 — HA çifti tamamlama Yeni aktif cihazda tüm virtual server’lar doğrulandıktan sonra:

1. Önce yedek (eski cihaz) değiştirin
2. Yeni yedeğin aktiften yapılandırmayı senkronize ettiğini doğrulayın
3. Zorla failover yapın — yeni yediği üretim yükü altında test edin
4. Eski aktifi devre dışı bırakın

İşe yaratan kural: her iki HA cihazını aynı anda hiçbir zaman değiştirmeyin. Trafiği üstlenen her zaman tam doğrulanmış, üretimde test edilmiş bir cihaz olmalıdır.

TMOS Uyumluluk Denetimi: Başlamadan Önce Yapın

TMOS 13.x için yazılmış iRule’lar her zaman 15.x’te aynı şekilde davranmaz. Migrasyondan önce tüm iRule’ları şunlar için denetleyin:

• HTTP:: komutları — HTTP/2 senaryolarında davranış değişiklikleri
• SSL:: olayları — TLS 1.3’te yeni olaylar ve değişen zamanlama
• RULE_INIT yürütmesi — başlangıçta zamanlama farklılıkları

Cutover öncesinde değişiklik gerektiren 3 iRule bulduk. Bunları staging ortamında bulmak, üretim olay yanıtında saatler kurtardı.

Temel Çıkarımlar

• LTM bir full-proxy‘dir — pass-through değil. Bu ayrım tüm yeteneklerini ve sorun giderme yaklaşımlarını yönlendirir.
• Health monitor’lar, load balancing yönteminden daha önemlidir. Uygulama yanıtlarını kontrol eden HTTP monitor’lar her zaman TCP monitor’lardan daha iyidir.
• iRule’lar, uygulama kodu değişiklikleri olmadan hat hızında trafik mantığı sağlar — en güçlü LTM farklılaştırıcısı.
• SSL offloading, şifreleme yükünü backend’lerden kaldırır. Düzenlenmiş ortamlarda SSL bridging gereklidir.
• HA için her zaman özel bir heartbeat VLAN kullanın. Paylaşılan arayüzler split-brain’e neden olur.
• Migrasyonlarda: önce yedek, sonra aktif. Aynı anda asla.

Bu Seri

• 📖 F5 BIG-IP Platform Genel Bakış — Tüm Modüller ← F5’e yeniyseniz buradan başlayın
• 🌐 F5 GTM ve GSLB Deep Dive
• 🛡️ F5 WAF Deep Dive

İlgili Yazılar

• 🛠️ Ağın Arka Kapısı: Yeni Nesil Console Server Mimarisi — F5 bakım pencereleri sırasında out-of-band erişim
• 🛡️ Network Packet Broker (NPB) Masterclass — ADC ile birlikte trafik görünürlüğü
• 🔐 Zero Trust Zihniyeti — LTM’nin Zero Trust mimarisindeki yeri

Firewall seçim görüşmeleri genellikle iki şekilde ilerler. Ya karar marka tanıdıklığına dayanır — “her zaman X satıcısını kullandık” — ya da üretimde bu sayıların gerçekte ne anlama geldiğini anlamadan datasheet throughput rakamlarına dayanır. Her iki yaklaşım da ya kullanmayacağınız kapasite için fazla ödemeye ya da gerçekte çalıştıracağınız trafik için yetersiz boyutlandırmaya yol açar.

Bankacılık ve üretim ortamlarında yüzlerce Fortinet firewall deploy ettikten ve Palo Alto ile Cisco’yu üretim altyapısında yoğun biçimde kullandıktan sonra, seçim sürecinin yalnızca öneriyi değil sonucu da üstlendiğinizde gerçekte nasıl göründüğünü paylaşmak istiyorum.

Firewall yerleştirme kararlarının arkasındaki mimari bağlam için bakınız: Switch, Firewall, AP — Doğru Ürünleri Seçmek Neden Yeterli Değil

Herkesi Yanıltan Sayı: Firewall Throughput’u

Her firewall datasheet’i bir throughput rakamıyla başlar. 10 Gbps. 40 Gbps. 100 Gbps. Bu rakamlar gerçektir — ölçüldükleri spesifik koşullarda.

Bu koşullar, sizin üretim ortamınız değildir.

Datasheet throughput’u tipik olarak şunlarla ölçülür:

• Büyük paket boyutları (1518 bayt) — gerçek trafik çok daha küçük paketler içerir
• Güvenlik özellikleri etkin değil — IPS yok, uygulama kontrolü yok, SSL inspection yok
• Sentetik test trafiği — gerçek bir ağın karışık, patlamalı, düzensiz trafiği değil

Üretimde firewall kapasitesini tüketen şeyler:

PPS (Saniyedeki Paket Sayısı): Küçük paketler büyük paketlerden daha maliyetlidir. 64 baytlık paketlerden oluşan 1 Gbps’lik trafiği taşıyan bir firewall, 1500 baytlık paketlerden oluşan 1 Gbps’den yaklaşık 20× daha fazla paket işler. Yüksek işlem hızına sahip ortamlar (bankacılık, ticaret, veritabanı replikasyonu), bant genişliği sınırlarından çok önce PPS sınırlarına ulaşır.

Eş Zamanlı Oturumlar: İzlenen her bağlantı, durum tablosunda bellek işgal eder. 2 milyon eş zamanlı oturum kapasiteli bir firewall “2 milyon kullanıcı” anlamına gelmez — tek bir kullanıcı aynı anda düzinelerce açık oturuma sahip olabilir. Yüksek eşzamanlılık ortamları (firewall arkasındaki web sunucuları, veritabanı kümeleri, mikro-servis mimarileri) oturum tablolarını bant genişliğinden daha hızlı tüketir.

Yeni Oturum Hızı: Firewall’un saniyede kaç yeni bağlantı kurabileceği. SYN flood koşullarında veya yoğun trafik dönemlerinde, yeni oturum hızı bağlayıcı kısıtlama haline gelir.

SSL/TLS Inspection: Kapasite planlamasının en çok yanlış yapıldığı yer burasıdır. SSL inspection etkinleştirildiğinde — HTTPS trafiğini şifre çözme, inceleme, yeniden şifreleme — çoğu platformda throughput önemli ölçüde düşer. Etkinin derecesi satıcıya ve modele göre değişir.

SSL Inspection Gerçeği

Bugün kurumsal trafiğin büyük çoğunluğu HTTPS’tir. Firewall’unuz SSL’i inspect etmiyorsa, trafiğinizin büyük bölümünü inspect etmiyorsunuz demektir. Ancak SSL inspection’ı etkinleştirmenin doğrudan ve önemli bir performans maliyeti vardır.

10 Gbps throughput ile pazarlanan bir firewall, platforma bağlı olarak tam SSL inspection etkinken 2–4 Gbps sunabilir. Bu bir hata veya satıcı eksikliği değildir — SSL şifre çözme hesaplamsal olarak maliyetlidir ve donanım SSL hızlandırması (üst düzey modellerde mevcut), pratikte giriş seviyesi ile orta segment platformları birbirinden ayıran şeydir.

Önemli olan hesaplama:

Bir firewall boyutlandırırken soru “ne kadar bant genişliğim var?” değil, “bu bant genişliğinin ne kadarı SSL inspect edilecek?” olmalıdır. Çoğu organizasyon için:

• İnternete giden trafik: neredeyse %100 HTTPS → tümü SSL inspect edilir
• Dahili segmentasyon trafiği: şifreli ve şifresiz uygulama trafiğinin karışımı
• Sunucudan sunucuya trafik: uyumluluk nedeniyle giderek artan oranda TLS

2 Gbps’lik internet bant genişliğiniz varsa ve tamamını inspect etmeyi planlıyorsanız, firewall’u 2 Gbps ham throughput için değil, 2 Gbps SSL inspection throughput’u için boyutlandırın. Bunlar çoğunlukla çok farklı sayılardır.

Çok Firewall Mimarisi: Tek Beden Herkese Uymaz

Birçok üretim ortamında, tüm rolleri üstlenen tek bir firewall, bilinçli bir tasarım seçimi değil, bir tasarım uzlaşısıdır. Farklı trafik türlerinin farklı gereksinimleri vardır:

İnternet Edge Firewall:
  → Yüksek SSL inspection throughput'u (trafiğin çoğu HTTPS)
  → VPN sonlandırma kapasitesi
  → İnternetten gelen tehditler için IPS
  → Orta oturum sayısı

Dahili Segmentasyon Firewall'u (Doğu-Batı):
  → Yüksek PPS (dahili trafik genellikle küçük paketlerdir)
  → Çok yüksek eş zamanlı oturum sayısı
  → Daha düşük SSL inspection gereksinimleri (dahili trafik genellikle şifresiz)
  → Yüksek yeni oturum hızı

Veri Merkezi / Sunucu Firewall'u:
  → Aşırı oturum sayıları (sunucular çok sayıda eş zamanlı bağlantıya sahiptir)
  → Düşük gecikme (uygulama performansına duyarlı)
  → Toplu veri transferleri için yüksek throughput
  → Sunucu tarafı exploit'ler için ayarlanmış IPS

Üç rol için de aynı firewall modelini kullanmak, en azından birinde uzlaşı anlamına gelir. SSL inspection için optimize edilmiş internet edge firewall’u çoğunlukla doğu-batı segmentasyonu için yanlış seçimdir. Yüksek oturum sayılı DC firewall’u çoğunlukla bir şube ofisi için gereğinden fazla mühendislenmiştir.

Bu teorik değildir — oturum sayısı sınırına ulaşıldığı için internet edge firewall’un belirtilen throughput’unun %30’unda doyuma ulaştığı, DC firewall’unda ise bol throughput rezervi olmasına rağmen PPS sınırları nedeniyle paket düştüğü ağlar gördüm.

Satıcı Saha Notları

Aşağıdakiler doğrudan üretim deneyimine dayanmaktadır. Bunlar kıyaslama karşılaştırmaları değil, operasyonel gözlemlerdir. Satıcı yetenekleri yazılım sürümleri ve yeni donanım nesilleriyle gelişir — her aktif proje için mevcut spesifikasyonları doğrulayın.

Fortinet FortiGate

Fortinet, üretim firewall deneyimimin büyük bölümünün yoğunlaştığı yerdir — küçük şube deployment’larından bankacılık genel merkezlerine ve büyük üretim ortamlarına kadar.

FortiGate’in gerçekten üstün olduğu yerler:

Orta düzeyde güvenlik inspection gereksinimleri olan yüksek throughput ortamları. Fortinet’in özel NP (Ağ İşlemcisi) ve CP (İçerik İşlemcisi) ASIC’leri belirli işlevleri donanıma boşaltır — paket işleme, IPsec VPN ve bazı inspection görevleri genel amaçlı CPU’lar yerine özel silikon üzerinde çalışır. Yüksek bant genişliğinde bu donanım hızlandırması anlamlı bir fark yaratır.

Büyük trafik hacimlerini taşıması gereken ortamlar için — sunucudan sunucuya, büyük dosya transferleri, yüksek bant genişlikli şube bağlantısı — FortiGate, eşdeğer fiyat noktalarında yazılım tabanlı mimarilerin karşılaştıramayacağı throughput sunar.

Fortinet Security Fabric, FortiGate’i FortiSwitch, FortiAP, FortiAnalyzer ve FortiManager ile birlikte çalıştıran organizasyonlar için gerçek bir operasyonel avantajdır. Politika, loglama ve yönetim, çok satıcılı ortamların gerektirdiği entegrasyon çalışmasını azaltacak biçimde birleştirilmiştir.

FortiGate’in sınırlılıkları:

Ölçekte derin inspection. IPS, uygulama kontrolü, SSL inspection ve antivirüs yüksek trafikli bağlantılarda aynı anda etkinleştirildiğinde, throughput başlık rakamlarına kıyasla önemli ölçüde düşebilir. Fortinet, bunu yansıtan “tehdit koruması” throughput rakamları yayınlar — ancak bu rakamlar hâlâ spesifik trafik karışımınız ve tam özellik aktivasyonuyla göreceğinizden genellikle iyimserdir.

Donanım nesil güncellemesi (2024–2025): Fortinet’in yeni cihaz serisi, SSL inspection kapasitesini önemli ölçüde iyileştirdi. 2025’te Keysight tarafından doğrulanan FortiGate 700G serisi, önceki nesillerin eşdeğer orta segment modellerine göre anlamlı bir iyileştirme olan 14 Gbps’e kadar SSL derin inspection throughput’u elde ediyor. Boyutlandırırken, genel tahminler değil, değerlendirdiğiniz spesifik model ve nesle ait datasheet rakamlarını her zaman kullanın.

Pratik rehberlik: Tam SSL inspection deployment’ları için FortiGate boyutlandırırken, üretim trafiği için çalışma tahminim olarak datasheet’teki SSL inspection throughput rakamının %20-30’unu kullanıyorum. Bu muhafazakâr görünebilir, ancak trafik karışımını, eş zamanlı bağlantıları ve loglama yükünü hesaba katar. Math bu rakamda işe yarıyorsa, uygun rezerviniz var demektir.

Palo Alto Networks

Palo Alto’nun mimarisi geleneksel firewall’lardan temelden farklıdır ve bunu anlamak hem güçlü yönlerini takdir etmek hem de kısıtlamalarını planlamak için gereklidir.

App-ID mimarisi:

Palo Alto, trafiği ne yapacağına karar vermeden önce uygulamaya göre tanımlar. Her oturum, yalnızca hangi portu kullandığını değil, neyi temsil ettiğini belirlemek için analiz edilir. Port 80, port 8080 veya özel bir port üzerindeki HTTP, hepsinde çalışan spesifik uygulama olarak tanımlanır.

Bu, güvenlik açısından mimari olarak güçlüdür: politika “X alt ağından TCP 443’e izin ver” yerine “satış ekibinden Salesforce’a izin ver” üzerine kuruludur. Bilinmeyen uygulamalar — bilinen hiçbir uygulama imzasıyla eşleşmeyen trafik — varsayılan olarak potansiyel olarak şüpheli kabul edilir. Tanınmayan trafiğin geçmesini istiyorsanız açıkça izin vermeniz gerekir.

Bunun yarattığı güvenlik avantajı:

Tehdit modelinin tam uygulama görünürlüğü gerektirdiği ortamlarda — finansal hizmetler, düzenlenmiş sektörler, katı uyumluluk gereksinimleri olan ortamlar — Palo Alto’nun yaklaşımı gerçek güvenlik derinliği yaratır. Politika modeli, her trafik türü için açık kararlar almayı zorlar. Hiçbir şey incelenmeden geçemez. Olgun güvenlik ekiplerine sahip güvenlik odaklı organizasyonlar için bu önemli bir avantajdır.

Operasyonel takas:

Palo Alto’yu güvenlik odaklı ortamlarda güçlü kılan aynı mimari, diğerlerinde sürtünme yaratır. Bilinmeyen veya olağan dışı uygulamalar araştırma ve açık politika kararları gerektirir. Özel güvenlik ekipleri olmayan veya çeşitli, gelişen uygulama setlerine sahip ortamlarda, uygulama tabanlı bir politika modelini sürdürmenin operasyonel yükü önemli olabilir.

Küçük ve orta ölçekli organizasyonlar için veya birincil gereksinimin maksimum güvenlik derinliği yerine makul güvenlikli bağlantı olduğu ortamlarda, bu takas değmeyebilir. Operasyonel model, her organizasyonun sahip olmadığı bir güvenlik olgunluk düzeyini varsayar.

Panorama:

Panorama aracılığıyla Palo Alto firewall’larının merkezi yönetimi, bireysel cihazları yönetmekten önemli ölçüde daha yeteneklidir. Çok firewall ortamları için Panorama, Palo Alto’yu ölçekte işletmek için fiilen gereklidir. Panorama olmadan yönetim yükü alternatiflere oranla orantısızdır.

SASE liderliği (2025 güncellemesi): Palo Alto’nun bulut güvenlik platformu (Prisma SASE), en güçlü büyüme alanlarından biri haline geldi — 2025’e kadar üç ardışık yıl Gartner SASE Lideri seçildi, yıllık %35 büyümeyle 1,3 milyar dolar ARR. Organizasyonunuz yalnızca bir perimeter firewall değil, daha geniş bir güvenlik platformunu değerlendiriyorsa bu bilgi ilgilidir.

Cisco Firepower (Şimdi Cisco Secure Firewall)

Cisco’nun NGFW hikayesinin anlaşılmaya değer bir geçmişi var. Orijinal ASA (Adaptive Security Appliance) güçlü bir stateful firewall’du — güvenilir, yaygın biçimde deploy edilmiş, ancak yeni nesil yetenekler açısından sınırlı. Cisco’nun yanıtı, IPS teknolojisi (Snort tabanlı) gerçekten güçlü olan ve olan Sourcefire’ı satın almak ve Firepower platformunu ASA mimarisinin üzerine inşa etmek oldu.

Firepower’ın güçlü olduğu yerler:

IPS yeteneği gerçektir. Sourcefire’ın tehdit istihbaratı ve tespiti, şimdi Cisco Talos (dünyanın en büyük tehdit istihbaratı organizasyonlarından biri), Firepower’ın IPS’ini genel olarak saygın bir tespit kalitesiyle güçlendirir. IPS’in birincil güvenlik gereksinimi olduğu ortamlar için Cisco ciddi bir yetenek sunar.

Cisco’nun daha geniş ekosistemiyle entegrasyon — ISE, Umbrella, Stealthwatch (şimdi Secure Network Analytics), SecureX — giderek daha tutarlı hale gelmiş ve son yıllarda önemli ölçüde iyileşmiştir.

Yönetim zorluğu:

Cisco Firepower, tarihsel olarak yönetim karmaşıklığı nedeniyle eleştirilmiştir. Firepower Management Center (FMC) olmadan Firepower çalıştırmak, görünürlük ve politika yönetiminde önemli sınırlamaları kabul etmek anlamına gelir. FMC’nin kendisi, alternatiflere göre daha dik bir öğrenme eğrisine sahiptir.

Platform önemli ölçüde olgunlaşmış ve Cisco yönetim deneyimini iyileştirmeye yoğun yatırım yapmıştır. 2024’te Cisco, Cisco Defense Orchestrator’ı Security Cloud Control olarak yeniden adlandırdı — FMC, ASA ve diğer Cisco güvenlik ürünlerini tek bir arayüzde birleştiren, yapay zeka destekli bir bulut yönetim platformu. Artık politika kuralı oluşturma için AI Asistanı, proaktif öneriler için AIOps içgörüleri ve şirket içi altyapı yükünü azaltan bulut tabanlı FMC içeriyor. Bu, eski yalnızca FMC modeline göre anlamlı bir iyileştirmedir. Daha basit firewall platformlarından gelen ekipler hâlâ bir uyum dönemi yaşayacak, ancak fark birkaç yıl öncesine kıyasla daralmıştır.

Mimari bağlam:

Cisco, ISE’nin kimlik, Catalyst’ın switching ve DNA Center / Catalyst Center’ın merkezi yönetim sağladığı Cisco ekosistemi yatırımına zaten derinden dahil olmuş ortamlarda en güçlüdür. Bu ortamlarda Firepower tutarlı biçimde uyum sağlar. Çok satıcılı ortamlarda entegrasyon hikayesi daha fazla çalışma gerektirir.

Check Point

Check Point, 1990’larda firewall teknolojisini ana akım haline getiren orijinal kurumsal firewall satıcılarından biridir. Mimarileri bu mirası yansıtır: olgun, güvenlik odaklı ve yöneticilere önemli kontrol sağlayan ancak karşılık gelen uzmanlık gerektiren bir işletim sistemi (Linux tabanlı Gaia) etrafında inşa edilmiş.

Check Point’in güçlü olduğu yerler:

Güvenlik politikası derinliği ve inspection kalitesi. Check Point’in politika modeli ayrıntılıdır ve inspection yetenekleri olgunlaşmıştır. Güvenlik politikası karmaşıklığının yüksek olduğu ortamlarda — çok sayıda kural, çok sayıda istisna, ayrıntılı loglama gereksinimleri — Check Point’in yönetim altyapısı (SmartConsole, yönetim sunucusu, log sunucusu ayrımı) ölçeği iyi karşılar.

Platformu bilen güvenlik operasyon ekiplerine sahip organizasyonlar için Check Point yetenekli ve saygın bir seçimdir.

Operasyonel gerçeklik:

Check Point’in yönetim modeli diğer satıcılardan farklıdır. Yönetim, zorunluluktan ayrıdır — Security Management Server (SMS) olan yönetim sunucusu, zorunluluk gateway’lerinden ayrıdır. Bu ayrımla, politika kurulum süreciyle ve temel Gaia OS ile çalışmak gerçek uzmanlık gerektirir.

Bir ağ mühendisinin perspektifinden Check Point, operasyonel olarak en şeffaf platform değildir. Linux yönetimine aşinalık önemli ölçüde yardımcı olur. Nesne modeli ve kural tabanı yapısı hakkında sağlam bir anlayış olmadan politika yönetimi, zamanla biriken karmaşıklığa yol açar.

HA Mimarisi: Aktif-Yedek ve Aktif-Aktif

Kurumsal firewall deployment’ları yüksek erişilebilirlik gerektirir. İki modelin farklı özellikleri vardır:

Aktif-Yedek:

• Bir firewall tüm trafiği işler; yedek izler ve arızada devralır
• Oturum durumu yedeğe senkronize edilir — failover kurulu bağlantılara şeffaftır
• Sorun giderme daha basit — herhangi bir zamanda tüm trafik tek cihazdan
• Normal işlemde donanım kapasitesinin %50’sini boşa harcar
• Çoğu kurumsal edge deployment için standart seçim

Aktif-Aktif:

• Her iki firewall da aynı anda trafiği yönetir, tipik olarak farklı trafik akışları veya bölgeler için
• Yapılandırmak ve sorun gidermek daha karmaşık — asimetrik routing’den kaçınılmalı
• Her iki cihazı da kullanır, ancak durum senkronizasyonunu karmaşıklaştırır
• Tek cihazın karşılayamayacağı çok yüksek throughput gereksinimleri için daha uygun
• Dikkatli trafik mühendisliği gerektirir — asimetrik akışlar (FW-1 üzerinden istek, FW-2 üzerinden yanıt) oturum düşüşlerine neden olur

Pratikte Aktif-Yedek, kurumsal deployment’ların büyük çoğunluğu için doğru seçimdir. HA yükü hesaba katıldığında tek bir cihazın sağlayabileceğinden gerçekten daha fazla throughput’a ihtiyaç duymadıkça, Aktif-Aktif’in throughput faydası operasyonel karmaşıklığı haklı kılmaz.

Politika Hijyeni: Yavaş Yavaş Biriken Sorun

Firewall kapasitesi yalnızca bir donanım sorusu değildir. Kural tabanı karmaşıklığı arttıkça firewall performansı düşer — özellikle kural tabanları düzenli temizlik yapılmadan büyüdüğünde.

Trafiğin çoğunun ilk 50 kuralda eşleştiği 5.000 kurallı bir kural tabanı, trafiğin yüzlerce kural genelinde dağıldığı 5.000 kurallı bir tabanla çok farklı performans gösterir. Her paket, eşleşene veya örtük redde ulaşana kadar kural tabanını yukarıdan aşağıya doğru geçer.

Kural hijyeni pratikte ne anlama gelir:

• Hiçbir zaman eşleşmeyen kurallar (gölge kurallar, eski kurallar) üç ayda bir tespit edilmeli ve kaldırılmalıdır
• Yüksek trafikli kurallar kural tabanının üst kısmına yerleştirilmelidir
• Aşırı geniş kurallar (loglama devre dışı bırakılmış herhangi/herhangi izinler) belgelenmeli ve gözden geçirilmelidir
• Platform desteklediğinde uygulamaya özgü kurallar port tabanlı kuralların yerini almalıdır

FortiManager, Panorama ve FMC’nin hepsinde kural kullanım istatistikleri ve gölge kural tespiti bulunur. Bu araçları kullanmak, periyodik temizlik alıştırması değil, sorumlu firewall operasyonunun bir parçasıdır.

Kapasite Planlaması: Pratik Çerçeve

Bir firewall boyutlandırırken şu metrikleri sırayla işleyin:

1. Temel trafik karakterizasyonu

• Mevcut zirve bant genişliği nedir (ortalama değil)?
• SSL/HTTPS yüzdesi nedir?
• Zirvede eş zamanlı oturum sayısı nedir?
• Zirvede yeni oturum hızı nedir?

2. Büyüme projeksiyonu

• 3 yıllık yaşam döngüsü için beklenen zirvenin %40–50 üzerinde rezerv ekleyin
• Eklenecek yeni uygulama ve hizmetleri hesaba katın

3. Özellik etkisi

• Hangi güvenlik özellikleri etkinleştirilecek? (IPS, SSL inspection, App-ID, AV)
• Ham throughput değil, satıcının “tehdit koruması” throughput rakamlarını kullanın
• SSL inspection için özellikle: tahmini HTTPS yüzdenizi kullanarak satıcı boyutlandırma araçlarıyla doğrulayın

4. HA yükü

• Aktif-Yedek: her birimi trafiğin %100’ü için boyutlandırın (yedek tam yükü karşılayabilmelidir)
• Yedek kapasitesini kullanmayı planlamayın — failover için hazır olmalıdır

5. Yönetim ve loglama

• Yüksek loglama oranları firewall’un kendi CPU’sunu tüketir
• Harici log yönetimi (FortiAnalyzer, Panorama, FMC) ölçekte isteğe bağlı değildir

Basit bir boyutlandırma örneği:

Ortam:
  Zirve bant genişliği: 2 Gbps
  SSL yüzdesi: %80 (1,6 Gbps HTTPS)
  IPS + App-ID + SSL inspection: hepsi etkin
  3 yıllık büyüme rezervi: %50

Gerekli SSL inspection throughput'u:
  1,6 Gbps × 1,5 (büyüme) = 2,4 Gbps

≥ 2,4 Gbps SSL inspection throughput'u için derecelendirilen model seçin
(2,4 Gbps ham throughput için değil)

Temel Çıkarımlar

• Datasheet throughput’u üretim throughput’u değildir. SSL inspection, IPS ve uygulama kontrolü efektif throughput’u önemli ölçüde azaltır. Ham rakamlar değil, tehdit koruması veya SSL inspection rakamlarına göre boyutlandırın.
• SSL inspection kapasitesi, çoğu internet edge deployment için bağlayıcı kısıtlamadır. Trafiğin büyük çoğunluğu HTTPS’tir ve inspect etmek maliyetlidir.
• Fortinet, donanım hızlandırmasının önemli olduğu yüksek throughput ortamlarında üstündür. Ölçekte tam derin inspection, dikkatli model seçimi gerektirir — tüm özellikler etkinleştirildiğinde throughput önemli ölçüde düşer.
• Palo Alto, en derin uygulama görünürlüğü ve en katı politika modelini sunar. Mimari güvenlik-olgun organizasyonlar için güçlüdür; özel güvenlik ekipleri olmayanlar için operasyonel yük ekler. Çok cihazlı yönetim için Panorama fiilen gereklidir.
• Cisco Firepower, güçlü IPS (Talos istihbaratı) ve Cisco ekosistemi entegrasyonu sunar. Yönetim karmaşıklığı gerçektir — FMC, platformun değerini gerçekleştirmek için gereklidir.
• Check Point, derin politika kontrolüyle olgun ve güvenlik odaklıdır. Etkili biçimde işletmek için Linux/Gaia OS aşinalığı ve disiplinli kural tabanı yönetimi gerektirir.
• Çok firewall mimarisi — edge, dahili segmentasyon ve DC için farklı firewall’lar — çoğunlukla her şey için tek platform yerine doğru yanıttır.
• Kural hijyeni yalnızca ev düzeni değil, bir performans ve güvenlik sorunudur. İhmal edilen kural tabanları her ikisini de bozar.

İlgili Yazılar

• 🏗️ Switch, Firewall, AP — Doğru Ürünleri Seçmek Neden Yeterli Değil — Firewall yerleştirme için mimari bağlam
• 🔐 Zero Trust Zihniyeti: Güvenliği Bir Mimari Olarak Mühendislemek — Firewall tasarımının arkasındaki politika felsefesi
• 🛡️ DDoS Koruma Stratejileri — Firewall’un yukarısında ne var
• 🛡️ F5 WAF Deep Dive — Firewall politikasını tamamlayan Katman 7 koruması
• 📊 İzleme Doğru Yapıldığında — Firewall davranışını görünür kılmak

Çoğu ağ mühendisi kariyerini IT altyapısında geçirir — kurumsal LAN’lar, veri merkezleri, kampüs ağları, bulut bağlantısı. Sonra bir gün masanıza fabrika, depo otomasyon sistemi veya bir tesis içeren bir proje düşer. Ve birden tanıdık kurallar tam olarak geçerli olmaz.

OT (Operational Technology — Operasyonel Teknoloji) ağları IT ağları değildir. Cihazlar farklıdır, protokoller farklıdır, öncelikler farklıdır ve — kritik olarak — bir şeyi yanlış yapmanın sonuçları farklıdır. IT’de yanlış yapılandırılmış bir switch ağ kesintisine neden olur. OT’de yanlış yapılandırılmış bir ağ değişikliği üretim hattını durdurabilir, pahalı ekipmanı hasar görebilir veya kritik altyapı senaryolarında fiziksel güvenlik riskleri yaratabilir.

Bu yazı IT mühendisinin perspektifinden yazılmıştır — bir firewall eklemek, bir ağı segmente etmek veya endüstriyel bir sistemi kurumsal ağa bağlamak için çağrılan kişi. Derin bir SCADA mühendisliği rehberi değil, karşılaşacaklarınız ve herhangi bir şeye dokunmadan önce düşünmeniz gerekenler için pratik bir yönlendirme.

Temel Fark: Gizlilik Yerine Erişilebilirlik

IT güvenliğinde klasik öncelik sırası CIA: Gizlilik, Bütünlük, Erişilebilirlik’tir. Gizlilik önce gelir — verileri yetkisiz erişimden korumak birincil endişedir.

OT’de öncelik sırası esasen AIC: Erişilebilirlik, Bütünlük, Gizlilik’tir. Üretim hattı çalışmaya devam etmelidir. IT ortamında 30 saniyelik ağ kesintisi bir rahatsızlıktır. Bir üretim tesisinde 30 saniyelik ağ kesintisi, ıskarta ürün, hasar görmüş makineler veya bir güvenlik olayı anlamına gelebilir.

Bu tersine çevirme, OT ortamındaki her ağ kararı için doğrudan sonuçlar doğurur:

• OT cihazlarını kapsamlı planlama olmadan yeniden başlatmazsınız. IT ortamında bir Cisco switch dramaya gerek kalmadan 3 dakikada yeniden başlatılabilir. Üretim hattına gömülü bir switch, planlanmış bakım penceresi, üretim durdurma ve tesis operasyon ekibiyle koordinasyon gerektirebilir.
• Yama yönetimi basit değildir. IT’de sistemleri düzenli olarak yamarsınız. OT’de birçok sistem yamalanamamaktadır — satıcı yazılım sürümünü sertifikalandırır ve herhangi bir değişiklik sertifikayı geçersiz kılar veya pahalı yeniden doğrulama gerektirir.
• Ağ değişiklikleri koordinasyon gerektirir. IT’de VLAN eklemek rutindir. OT’de aynı değişiklik üretim yöneticilerinden, güvenlik mühendislerinden ve ekipman satıcılarından onay gerektirebilir.

Bunu çalışmaya başlamadan önce anlamak yalnızca mesleki nezaket değildir — gerçek operasyonel olayları önler.

Purdue Modeli: OT Ağ Mimarisinin Haritası

Purdue Modeli (ISA-95), endüstriyel ağ mimarisini anlamak için standart çerçevedir. En alttaki fiziksel süreçlerden en üstteki kurumsal IT’ye kadar seviyeleri tanımlar:

Seviye 4/5  — Kurumsal IT Ağı (ERP, e-posta, kurumsal LAN)
─────────────────────────────────────────────────────────────
              IT/OT DMZ  ← IT mühendislerinin çalıştığı sınır
─────────────────────────────────────────────────────────────
Seviye 3    — Operasyonlar / Saha Yönetimi
              (Tarihçi sunucular, mühendislik iş istasyonları,
               HMI sunucuları, toplu yönetim)

Seviye 2    — Denetimsel Kontrol
              (SCADA sunucuları, HMI istemcileri, DCS iş istasyonları)

Seviye 1    — Temel Kontrol
              (PLC'ler, DCS kontrolörleri, RTU'lar)

Seviye 0    — Fiziksel Süreç
              (Sensörler, aktüatörler, motorlar, valfler)

IT mühendislerinin tipik olarak çalıştığı yer: IT/OT DMZ ve Seviye 3. Kurumsal IT ağı ile OT ortamı arasındaki bağlantının yönetildiği yer burasıdır. Firewall projeleri, tarihçi bağlantısı, uzak erişim çözümleri ve ağ segmentasyonu çalışmalarının yapıldığı yer.

IT mühendislerinin nadiren doğrudan dokunduğu şeyler: Seviye 0, 1 ve 2 — gerçek kontrol sistemleri, PLC’ler ve SCADA bileşenleri. Bunlar OT/otomasyon mühendisleri ve ekipman satıcılarının alanıdır.

IT ile OT arasındaki DMZ, endüstriyel ağ mimarisindeki en kritik sınırdır. Var olmalıdır. Trafik kurumsal ağ ile OT ortamı arasında serbestçe akmamalıdır.

OT Protokolleri: Bu Ağlarda Neler Çalışıyor

Bir OT ağına ilk kez ağ analizörü bağladığınızda, hiçbir IT ağında görünmeyen protokoller göreceksiniz. Bunların ne olduğunu — yüzey düzeyinde bile olsa — anlamak, makul firewall ve segmentasyon kararları vermenize yardımcı olur.

Modbus

1979’da geliştirilen en eski endüstriyel protokol. Üretim, kamu hizmetleri ve bina otomasyonunda hâlâ yaygın biçimde kullanılmaktadır.

• Modbus RTU: Seri tabanlı (RS-232, RS-485). Ethernet değil, fiziksel seri bağlantılar üzerinden çalışır.
• Modbus TCP: TCP/IP içinde kapsüllenmiş Modbus. Port 502 üzerinde çalışır.

Modbus’ta kimlik doğrulama yoktur, şifreleme yoktur, yetkilendirme yoktur. Modbus etkin bir kontrolörün port 502’sine ulaşabilen ağdaki herhangi bir cihaz sensör değerlerini okuyabilir veya kontrol komutları yazabilir. Bu tarihsel bir ihmal değildir — Modbus, fiziksel erişimin güvenlik kontrolü olduğu izole seri ağlar için tasarlanmıştır.

Modbus TCP, OT segmentinin dışından erişilebilen bir Ethernet ağında olduğunda, kimlik doğrulamanın yokluğu önemli bir risktir. Firewall politikası, Modbus etkin kontrolörlere hangi cihazların ulaşabileceğini kısıtlamalıdır.

DNP3 (Distributed Network Protocol)

Kamu hizmetlerinde yaygın — enerji üretimi, su arıtma, petrol ve gaz. Başlangıçta kontrol merkezleri ile uzak saha cihazları (trafo merkezleri, pompa istasyonları) arasındaki SCADA iletişimi için tasarlanmıştır.

DNP3’ün temel kimlik doğrulama uzantıları vardır (Güvenli Kimlik Doğrulama Sürüm 5), ancak dağıtılmış uygulamaların çoğu hâlâ orijinal kimlik doğrulamasız sürümü kullanmaktadır. Modbus gibi, izole ağlar için tasarlanmış ve çoğunlukla kağıt üzerinde mevcut olan güvenlik özellikleri olmadan dağıtılmıştır.

OPC-UA (OPC Unified Architecture)

Eski protokollerdeki güvenlik açıklarını gidermek için özel olarak tasarlanmış modern endüstriyel iletişim standardı. OPC-UA şunları destekler:

• Sertifika tabanlı kimlik doğrulama
• Şifreli iletişim
• İnce taneli yetkilendirme (hangi istemcilerin hangi veri noktalarını okuyabileceği)

OPC-UA, yeni kurulumlarda ve Tarihçi sunucu bağlantısında karşılaşacağınız protokoldür — Seviye 3 sistemlerin bir güvenlik sınırını korurken Seviye 2 kontrolörlerden veri topladığı yöntem.

PROFINET

Siemens’in endüstriyel Ethernet protokolü, Avrupa üretiminde (otomotiv, gıda işleme, ilaç) baskındır. PROFINET standart Ethernet üzerinde çalışır ancak belirli EtherType değerleri kullanır ve gerçek zamanlı açıdan hassastır — milisaniyelik gecikmeler önemlidir.

PROFINET’in neredeyse hiç yerleşik güvenliği yoktur. Fiziksel olarak izole edilmiş bir ağı varsayar. PROFINET kontrolörlü ortamlarda, ağ segmentasyonu katı olmalıdır — PROFINET trafiği asla kendi özel VLAN’ının dışına çıkmamalıdır.

EtherNet/IP

Rockwell Automation / Allen-Bradley’nin endüstriyel Ethernet protokolü. Kuzey Amerika üretiminde yaygın. PROFINET’e benzer güvenlik özellikleri — izole ağlar için tasarlanmış, sınırlı kimlik doğrulama.

IT Mühendisinin Gerçekte Yapması İstenenler

Pratikte, IT/ağ mühendisleri OT projelerine dahil olduğunda, talep genellikle şu kategorilerden birine girer:

Senaryo 1: “PC ile Makine Arasına Firewall Ekle”

En yaygın senaryo. Bir Windows PC (SCADA yazılımı veya HMI çalıştıran), aralarında hiçbir ağ cihazı olmadan Ethernet aracılığıyla doğrudan bir PLC veya üretim makinesine bağlıdır. Talep, bir güvenlik katmanı eklemektir.

Önce:
  [Windows HMI PC] ──────────────── [PLC / Makine Kontrolörü]

Sonra (tipik yaklaşım):
  [Windows HMI PC] ── [Firewall] ── [PLC / Makine Kontrolörü]

Katman 2 şeffaf firewall deployment’ı:

Bu yola firewall eklemenin operasyonel açıdan en güvenli yolu, Katman 2 şeffaf moddur (“bump in the wire” veya köprü modu olarak da adlandırılır). Firewall trafiği şeffaf olarak geçirir — ne cihaz onun varlığından haberdar olur, ne IP adresleri değişir ne de routing değişiklikleri yapılır. Firewall arızalanırsa, trafik kaldırılıp doğrudan yeniden bağlanarak geri yüklenebilir.

Bu önemlidir çünkü PLC veya endüstriyel kontrolör üzerindeki IP adreslerini değiştirmek, onunla konuşan uygulama yazılımını yeniden yapılandırmayı gerektirir — bu, satıcı desteği, yeniden sertifikalama ve üretim kesintisi içerebilecek bir süreçtir.

Şeffaf modda:

• PLC mevcut IP adresini korur
• HMI PC mevcut IP adresini korur
• Firewall, yönlendirilmiş bir atlama olmadan trafiği inceler ve politikayı uygular

Bu senaryoda firewall politikası tipik olarak şunları içerir:

• HMI’dan kontrolöre belirli OT protokolü trafiğine izin ver (Modbus port 502, PROFINET, EtherNet/IP)
• Yalnızca gerekli yönetim protokollerine izin ver
• Geri kalanını engelle
• Görünürlük için tüm trafiği logla

Senaryo 2: “OT Ağını Kurumsal IT’ye Bağla”

Üretim ekibi, fabrika zemininden kurumsal sistemlere veri almak ister — ERP’ye üretim istatistikleri, raporlama veritabanına sensör verileri, uzak izleme yeteneği.

Bu bir DMZ mimarisi gerektirir:

[Kurumsal IT Ağı]
         │
    [IT/OT Firewall]   ← Katı politika: yalnızca belirli akışlara izin ver
         │
    [OT DMZ]
    [Tarihçi Sunucu]    ← OT'den veri toplar, IT'ye sunar
         │
    [OT Firewall]       ← OT'yi DMZ'den koruyan ayrı firewall
         │
    [OT Ağı — Seviye 2/3]

DMZ prensibi: kurumsal ağ, OT cihazlarına doğrudan ulaşamaz. DMZ’deki Tarihçi sunucu, OT sistemlerinden veri toplar (OT firewall tarafından izin verilir) ve kurumsal sistemlerin kullanımına sunar (IT firewall tarafından izin verilir). Kurumsal ağ ne OT ağına, ne de OT ağı kurumsal ağa doğrudan bağlantı başlatabilir.

Neden iki firewall, bir değil? DMZ’deki Tarihçi sunucu ele geçirilirse, herhangi bir ağa erişim yolu sağlamamalıdır. DMZ segmentli tek bir firewall, iki ayrı firewall’dan daha az izolasyon sağlar.

Senaryo 3: “Düz OT Ağına Segmentasyon Ekle”

Birçok eski OT ortamı tamamen düz bir ağa sahiptir — tüm PLC’ler, HMI’lar, mühendislik iş istasyonları ve hatta bazen kurumsal bağlantılı PC’ler aynı Katman 2 yayın etki alanındadır. Her cihaz diğer her cihaza ulaşabilir.

Bu ağı segmente etmek şunları içerir:

• VLAN yetenekli yönetilen switchler eklemek
• Cihaz türü veya işleve göre VLAN’lar tanımlamak (Seviye 2 kontrolörler, Seviye 3 denetimsel, mühendislik iş istasyonları)
• Katı VLAN arası politikayla bir firewall üzerinden VLAN’lar arasında routing yapmak

Kritik kısıt: Herhangi bir ağ değişikliği yapmadan önce mevcut iletişim akışlarını kapsamlı biçimde belgeleyin. Hangi cihazlar hangi cihazlarla konuşur? Hangi portlar üzerinde? Bir PLC ile kontrolörü arasındaki belgelenmemiş iletişim yolunu kıran segmentasyon, üretim hattını durdurur.

IT ortamlarında, akışları birkaç gün izleyerek keşfedebilir ve ardından uygulayabilirsiniz. OT’de, bazı iletişim akışları yalnızca belirli üretim aşamalarında gerçekleşir — haftalık bir toplu işlem, vardiya sonu raporu — ve kısa bir izleme penceresi sırasında görünmez. Segmentasyonu uygulamadan önce tüm iletişim gereksinimlerini belgelemek için OT ekibiyle çalışın.

OT Odaklı Firewall’lar: Satıcıların Geliştirdikleri

Standart IT firewall’ları (NGFW’ler bile) OT protokollerine sınırlı görünürlüğe sahiptir. IP başlıklarını ve TCP/UDP portlarını inceleyebilirler, ancak Modbus TCP komutunun içeriğini anlayamazlar — “sensör değeri oku” ile “aktüatöre kontrol komutu yaz” arasındaki farkı ayırt edemezler.

OT odaklı firewall’lar endüstriyel protokol incelemesi ekler — OT protokolü payload’larını ayrıştırma ve protokole özgü içeriğe dayalı politika kararları verme yeteneği.

İmza Farkı

Standart bir NGFW’nin 2.000–5.000 uygulama imzası olabilir — çoğunlukla IT uygulamaları (HTTP, TLS, DNS, SMB, Office 365, vb.). OT yetenekli bir firewall lisansı, endüstriyel protokoller için yüzlerce ek imza ekler:

• Modbus TCP: Okuma isteklerini (HMI’dan kabul edilebilir) yazma komutlarından (yalnızca yetkili sistemlerle kısıtla) ayırt et
• PROFINET: Belirli PROFINET servislerini tanımla ve kontrol et
• EtherNet/IP: CIP (Common Industrial Protocol) komutlarını ayrıştır
• DNP3: DNP3 fonksiyon kodlarını ve nesne türlerini incele
• OPC-DA/UA: OPC iletişim yönünü ve veri türlerini kontrol et
• BACnet: Bina otomasyon protokolü incelemesi
• Düzinelerce endüstriyel ve bina otomasyon protokolü daha

Neden önemli: OT protokolü incelemesi olmadan, bir firewall yalnızca “bu IP o IP’ye bu portta ulaşabilir mi” yi kontrol edebilir. OT incelemesiyle, “HMI, PLC’den Modbus holding registerlarını okuyabilir, ancak coillere yazamaz” ı zorunlu kılabilir — IP/port filtrelemeden temel olarak farklı bir kontrol düzeyi.

Satıcı Ortamı

OT Bundle’lı Fortinet FortiGate: Fortinet, temel NGFW’yi endüstriyel protokol imzaları ve OT’ye özgü tehdit istihbaratıyla genişleten belirli OT/ICS lisansları sunar. FortiGate, şeffaf modda (Katman 2) veya yönlendirilmiş modda dağıtılabilir. IT için zaten FortiGate çalıştıran ortamlarda, aynı platform her ikisini de yönetir.

ICS/SCADA içeriğiyle Palo Alto Networks: Palo Alto’nun App-ID motoru, endüstriyel protokol tanımlamasını içerir. Industrial IoT Security aboneliği OT cihaz görünürlüğü, risk değerlendirmesi ve protokole özgü politikalar ekler. Bölge tabanlı mimari, Purdue modeli segmentasyonuyla iyi uyum sağlar.

Claroty, Nozomi Networks, Dragos (OT’ye özel): Bunlar geleneksel firewall’lar değildir — OT’ye özgü güvenlik izleme platformlarıdır. SPAN portu aracılığıyla OT ağına bağlanırlar (pasif izleme) ve derin görünürlük sağlarlar: varlık keşfi, protokol analizi, davranışsal temel, anomali tespiti. Trafiği engellemezler ancak genel IT araçlarının sağlayamadığı görünürlük sunarlar. Genellikle standart bir firewall ile birlikte kullanılır.

Cisco Industrial Network Director: Cisco’nun OT odaklı yönetim ve güvenlik platformu, OT ağı görünürlüğü için Cisco endüstriyel switchleri ve firewall’larıyla entegre olur.

Lisanslama Gerçeği

OT firewall yetenekleri, standart IT NGFW özelliklerinden ayrı olarak lisanslanır. OT projesi için bir firewall belirtiyorsanız, standart kurumsal lisans yeterli değildir — OT/ICS bundle veya eşdeğeri gerekir. Bu hem maliyeti hem de müşteriyle satıcı seçim görüşmesini etkiler.

Yama Sorunu: Dokunamadığınız Eski Sistemler

IT’de yama rutin bir işlemdir. Aylık yama döngüleri, otomatik dağıtım, merkezi yönetim. OT’de yama çoğunlukla imkânsızdır.

Sebepler spesifik ve meşrudur:

Satıcı sertifikasyonu: Endüstriyel ekipman üreticileri (Siemens, Rockwell, Schneider, ABB, vb.) sistemlerini belirli yazılım sürümleriyle sertifikalandırır. İşletim sistemi sürümünü değiştirmek veya işletim sistemi yaması uygulamak, ekipman sertifikasyonunu geçersiz kılabilir; orijinal ekipmandan daha pahalıya mal olabilecek ve aylarca sürebilecek bir yeniden doğrulama süreci başlatır.

Üretim bağımlılığı: Yama, kesinti gerektirir. Sürekli süreç endüstrilerinde (kimya tesisleri, çelik fabrikaları), “kesinti” planlanmış yıllık bakım penceresi anlamına gelebilir — yama uygulamak için yılda bir fırsat.

Kullanım ömrü dolmuş yazılım: Kritik endüstriyel yazılım çalıştıran Windows XP, Windows 2003 Server ve daha eski sistemlerle karşılaşacaksınız. Microsoft bu sistemler için yıllardır güvenlik yaması yayınlamamıştır. Üzerlerinde çalışan endüstriyel yazılım daha yeni Windows sürümlerinde doğrulanmadığı için yükseltilemezler.

Ağ güvenliği için ne anlama gelir:

Sistemleri yamalayamazsanız, ağ kontrolleriyle telafi etmelisiniz:

• Katı ağ segmentasyonu: Yamalanamamış sistemler, internet kaynaklı tehditlere maruz kalabilecekleri herhangi bir ağdan erişilemez olmalıdır
• Uygulama beyaz listesi: Yalnızca özellikle yetkili uygulamalar OT uç noktalarında çalışabilir (uç nokta işletim sistemi bunu destekliyorsa)
• Telafi edici kontroller: Firewall, yamanın normalde yapacağı işi yapmalıdır — ağ politikası aracılığıyla saldırı yüzeyini kısıtlama
• Çevrimdışı antivirüs güncellemeleri: İnternet bağlantısı yerine hava boşluklu ortamlarda USB veya çevrimdışı medya aracılığıyla iletilen AV güncellemeleri

OT’deki güvenlik görüşmesi “sistemlerinizi yama yapın” değildir — “yamayalamadığımız sistemleri ağ mimarisi ve telafi edici kontroller aracılığıyla nasıl koruruz” sorusudur.

OT’de 802.1X ve NAC: Standart IT Yaklaşımlarının Neden Doğrudan Transfer Olmadığı

802.1X port tabanlı ağ erişim kontrolü, kurumsal IT’de standarttır. OT’de belirli zorluklar yaratır:

PLC’ler ve kontrolörlerin 802.1X supplicant’ları yoktur. Bir Siemens S7 PLC veya Allen-Bradley ControlLogix kontrolörü, 802.1X istemcisi olan standart bir işletim sistemi çalıştırmaz. Kullanıcı adı/şifre veya sertifika kullanarak bir RADIUS sunucusuna kendini doğrulayamaz. Bir 802.1X etkin switch portuna basitçe bağlanamaz.

Geçici çözüm olarak MAC Authentication Bypass (MAB): OT cihazları için standart yaklaşım MAB’dır — cihazın MAC adresi kimlik doğrulama kimlik bilgisi olarak kullanılır. Switch, MAC adresini RADIUS’a gönderir; RADIUS bunu yetkili cihaz veritabanına göre kontrol eder. MAC biliniyorsa erişim verilir.

MAB bir miktar kontrol sağlar — bilinmeyen cihazlar ağ erişimi alamaz — ancak sertifika veya kimlik bilgisi tabanlı kimlik doğrulamadan daha zayıftır. MAC adresleri taklit edilebilir. Değer görünürlükte ve yetkisiz cihazların bağlanmasını önlemede, kriptografik kimlik doğrulamada değildir.

Katı MAC adresi yönetimi gereksinimi: OT’de MAB, tüm yetkili cihaz MAC adreslerinin doğru bir veritabanını sürdürmeyi gerektirir. Dinamik IT ortamında bu uygulanamaz. Cihazların nadiren değiştiği ve tüm eklemelerin değişiklik yönetiminden geçtiği OT’de uygulanabilirdir — ancak disiplin gerektirir.

Alternatif olarak profiling: OT güvenlik platformları (Claroty, Nozomi, Cisco CyberVision), ağdaki cihazları profilleyebilir — pasif trafik analizinden PLC modellerini, yazılım sürümlerini ve iletişim kalıplarını tanımlar. Bu, cihazların kimlik doğrulaması yapmasını gerektirmeden varlık görünürlüğü sağlar. Profil verileri NAC politikalarına beslenebilir: “bu cihaz profili bir Siemens S7 PLC ile eşleşiyorsa, PLC VLAN’ına yerleştir.”

Ağ değişikliği riski: Mevcut bir düz OT ağında son derece dikkatli planlama olmadan 802.1X’i etkinleştirmek, üretim hattını durdurabilir. Zorunluluğu etkinleştirmeden önce her cihaz yetkili veritabanında olmalıdır. Doğrulama süreci yalnızca normal operasyonu değil, tüm üretim aşamalarını kapsamalıdır. Hafta sonu toplu çalışması sırasında ağdan düşen kaçırılan bir cihaz Pazartesi sabahı olayına neden olabilir.

Pratik Kontrol Listesi: OT Ağına Dokunmadan Önce

Saha deneyiminden — OT ortamında herhangi bir ağ değişikliği yapmadan önce gerçekleşmesi gereken şeyler:

• Önce OT ekibiyle konuşun. Otomasyon mühendisleri ve tesis operasyon personeli, ağ hakkında belgelenmemiş şeyler bilir. Herhangi bir değişiklikten önce onların katkısı gereklidir.
• Mevcut iletişim akışlarını belgeleyin. Hangi cihazlar hangileriyle, hangi portlar üzerinde, hangi sıklıkta konuşuyor. Kısa süreli izlemeye güvenmeyin — tüm bilinen iletişim yollarının belgelerini OT ekibinden isteyin.
• Üretim programını anlayın. Bakım penceresi ne zaman? Tesiste planlanmış kesinti ne zaman? Değişiklikler bu pencerelerle uyumlu olmalı, üretim üzerine dayatılmamalıdır.
• Mümkünse lab veya staging ortamında test edin. Birçok satıcı endüstriyel ekipmanları için lab ortamları veya simülatörler sağlar.
• Bir geri alma planınız olsun. Katman 2 firewall eklemesi için geri alma, firewall’u kaldırıp doğrudan yeniden bağlamaktır — bu prosedürü gerektiğinde hızlıca uygulanabilmesi için belgeleyin.
• Yazılım/konfigürasyon yedeklerini koordine edin. Herhangi bir ağ değişikliği yapmadan önce OT cihaz konfigürasyonlarının yedeklendiğinden emin olun. Bir PLC’nin güç döngüsüne ihtiyacı varsa, konfigürasyonu kurtarılabilir olmalıdır.
• Değişiklikten önce ve sonra “çalışıyor” tanımını yapın. OT ekibiyle kabul kriterlerini belirleyin — hangi sistemlere erişilebilir olmalı, hangi süreçler çalışıyor olmalı — değişikliği başarılı ilan etmeden önce.

Temel Çıkarımlar

• OT ağları, gizlilik yerine erişilebilirliği önceliklendirir — bu, birçok IT güvenlik varsayımını tersine çevirir ve her kararı bilgilendirmelidir.
• Purdue modeli, IT/OT sınırının nerede oturduğunu tanımlar. Seviye 3 ile kurumsal IT arasındaki DMZ, IT mühendislerinin en sık çalıştığı yerdir.
• OT protokolleri (Modbus, PROFINET, EtherNet/IP, DNP3) kimlik doğrulama veya şifrelemeye sahip değildir. Ağ kontrolleri birincil güvenlik mekanizmasıdır.
• Katman 2 şeffaf firewall deployment’ı, OT cihazları arasına güvenlik eklemenin en güvenli yoludur — IP adresi değişikliği yok, routing değişikliği yok, konfigürasyon değişiklikleri olmadan geri alınabilir.
• OT odaklı firewall’lar, endüstriyel protokolleri anlar ve politikayı protokol düzeyinde zorunlu kılabilir (okumalara izin ver, yazmaları engelle) — IP/port filtrelemeden temel olarak farklı bir yetenek.
• OT firewall lisanslaması, IT NGFW lisanslamasından ayrıdır — bunu proje kapsamına dahil edin.
• Yamalanmamış eski sistemler OT’de normaldir — telafi edici ağ kontrolleri, IT’de yamanın sağladığının yerini alır.
• 802.1X doğrudan transfer olmaz — PLC’ler kimlik doğrulayamaz. MAB ve cihaz profiling pratik alternatiflerdir.
• Herhangi bir şeye dokunmadan önce OT ekipleriyle koordine edin — üretim ortamlarındaki ağ hatalarının sonuçları IT’dekinden önemli ölçüde daha ciddidir.

İlgili Yazılar

• 🔐 802.1X Kimlik Tabanlı Mimari Sahada — 802.1X’in IT ortamlarında nasıl çalıştığı ve OT’nin neden farklı olduğu
• 🔐 Zero Trust Zihniyeti: Güvenliği Bir Mimari Olarak Mühendislemek — IT/OT sınır tasarımına uygulanan Zero Trust prensipleri
• 🛡️ DDoS Koruma Stratejileri — OT bağlantılı altyapıyı volumetrik saldırılardan korumak
• 🏗️ IT Altyapısı Ürünler Koleksiyonu Değildir — OT ağ tasarımı için de geçerli sistem düşüncesi

WiFi, herhangi bir ağın en görünür parçasıdır. Çalıştığında kimse söylemez. Çalışmadığında ise — dakikalar içinde IT ekibi binanın her köşesinden duyar.

Ancak kablosuz ağ oluşturma aldatıcı biçimde karmaşıktır. Bir kullanıcıya “sadece WiFi” gibi görünen şey, birbirleriyle etkileşen kararların bir yığınıdır: hangi 802.11 standardı, hangi frekans bandı, kaç erişim noktası, hangi controller mimarisi, kimlik doğrulamanın nasıl yönetileceği, roaming’in nasıl davranacağı, RF ortamının nasıl yönetileceği. Bunlardan herhangi birini yanlış yaparsanız, kağıt üzerinde iyi görünen ağ üretimde başarısız olur.

Aruba, Cisco Meraki ve Cisco kurumsal platformları kullanarak bankacılık genel merkezleri, üretim tesisleri, oteller, lojistik depoları ve muayenehanelerde kablosuz ağlar tasarladım ve deploy ettim. Bu seri, bu senaryoların her birinde gerçekte önemli olan şeyleri belgeliyor.

Bu Seriyi Nasıl Okuyalım

Bu yazı size büyük resmi verir — kurumsal kablosuz mimarisinin neyi içerdiğini, temel kararların neler olduğunu ve her deep dive’ın nereye gittiğini.

Mühendisseniz ve belirli bir konuya derinlemesine inmek istiyorsanız — kullanım senaryonuzu kapsayan yazıya atlayın:

• 📡 802.11 Standartları Deep Dive: WiFi 4, 5, 6, 6E ve Gerçekte Ne Değişti — ax, ac, n ve be’nin kapasite, kapsama alanı ve deployment kararları için gerçekte ne anlama geldiği
• 🏢 Kurumsal Controller Mimarisi: Cisco ve Aruba WLAN Tasarımı — Merkezi ve dağıtık kontrol, mobilite alanları, WLC ve bulut yönetimi karşılaştırması
• 🏨 KOBİ, Oteller ve Muayenehane İçin WiFi Tasarımı — Yoğunluk planlaması, misafir segmentasyonu ve beklenti yönetimi üzerine pratik saha notları
• 🔐 WiFi Güvenliği: WPA3, 802.1X, Sahte AP Tespiti ve Site Survey — Kimlik doğrulama, şifreleme, saldırı tespiti ve Ekahau survey metodolojisi

Mimar veya karar vericiyseniz ve kablosuz çözümleri değerlendiriyorsanız — burada okumaya devam edin. Bu yazı, RF uzmanlığı gerektirmeden stratejik soruları yanıtlar.

WiFi Mimarisinin Erişim Noktası Sayısından Daha Fazlasını Neden Önemlidir

WiFi deployment’larındaki en yaygın hata: kablosuzu bir miktar problemi olarak ele almak. “Daha iyi WiFi’ye ihtiyacımız var — daha fazla erişim noktası ekleyelim.”

Kötü tasarlanmış bir ağa erişim noktası eklemek onu daha da kötüleştirir. Aynı alanda daha fazla AP, daha fazla girişim, daha fazla kanal çakışması, daha fazla roaming olayı ve daha fazla karmaşıklık demektir — kullanıcı deneyiminde orantılı bir iyileşme olmadan.

Kurumsal kablosuz tasarımı erişim noktası yoğunluğu ile ilgili değildir. Şunlarla ilgilidir:

• Kapasite planlaması: Kaç eş zamanlı istemci, hangi veri hızlarına ihtiyaç duyarlar, hangi uygulamaları çalıştırıyorlar?
• RF tasarımı: Hangi kanallar, hangi güç seviyeleri, hangi band yönlendirme politikaları oluşturmak yerine girişimi önler?
• Controller mimarisi: Ağ kararları nasıl verir? Kimlik doğrulama nerede gerçekleşir? Roaming nasıl yönetilir?
• Güvenlik: Ağa kim, hangi kimlikle ve ne düzeyde erişimle izin verilir?
• Operasyonel model: Kim yönetir, nasıl izlenir, sorunlar nasıl teşhis edilir?

Bunları doğru yaparsanız erişim noktası sayısı bir başlangıç noktası değil, türetilmiş bir hesaplama olur.

802.11 Standartları: Gerçekte Ne Değişti

IEEE 802.11 standardı, her biri pazarlama amacıyla farklı biçimde markalanmış birden fazla nesil geçirdi:

Pazarlama materyallerindeki teorik hızlar pratikte hiçbir zaman ulaşılmaz. Gerçek deployment’larda önemli olan her nesil için farklıdır:

WiFi 6 (802.11ax), yoğun ortamlarda gerçekten önemli iki yetenek getirdi:

• OFDMA (Orthogonal Frequency Division Multiple Access): Bir AP’nin bölünmüş frekans kaynakları üzerinde aynı anda birden fazla istemciye hizmet vermesini sağlar — bir seferde bir istemci iletim yapmak yerine, birden fazla istemci kanalı verimli biçimde paylaşır. Çok sayıda IoT cihazı, telefon ve tablet bulunan ortamlar için kritik.
• BSS Boyama: Örtüşen hücreler arasında aynı kanal girişimini azaltan bir mekanizma. Komşu AP’ler iletimlerini “boyar”, bu da cihazların “benim AP’m” ile “yan odadaki AP” arasındaki ayrımı daha verimli yapmasını sağlar.

WiFi 6E, 6 GHz bandını ekledi — komşu ağlardan ve eski cihazlardan gelen girişimi ortadan kaldıran büyük ölçüde tıkanmamış bir spektrum. Yoğun kentsel ortamlarda önemli avantaj.

WiFi 7 ortaya çıkıyor ve Çok Bağlantılı Çalışma (MLO) sayesinde tek bir cihazın aynı anda birden fazla bant ve kanalı kullanması — verimi iyileştiriyor ve gecikmeyi azaltıyor. 2026 itibarıyla hâlâ erken kurumsal deployment aşamasında.

→ 802.11 Standartları Deep Dive

Controller Mimarisi: Zekanın Nerede Yaşadığı

Kurumsal kablosuz ağlarda iki temel mimari model vardır:

Merkezi Controller (Geleneksel Kurumsal)

Tüm erişim noktaları “ince"dir — RF iletimini yönetirler ancak tüm trafiği ve tüm kontrol kararlarını merkezi bir Kablosuz LAN Controller’a (WLC) gönderirler:

[AP] ──CAPWAP tüneli──→ [WLC] → Çekirdek Ağ
[AP] ──CAPWAP tüneli──→ [WLC]
[AP] ──CAPWAP tüneli──→ [WLC]

WLC, kimlik doğrulamayı, roaming kararlarını, RF yönetimini, güvenlik politikasını ve trafik iletimini yönetir. AP’ler birbirinin yerine geçebilir — birini kaldırın ve yerine başkasını takın; WLC yapılandırmayı yönetir.

Güçlü yönler: Merkezi görünürlük, tutarlı politika uygulaması, controller alanı içinde kesintisiz roaming.

Zayıf yönler: WLC tek hata noktasıdır (HA çiftleriyle hafifletilir). Trafik, yerel iletişim için bile WLC üzerinden geçer. Ölçeklendirme WLC kapasitesi eklemeyi gerektirir.

Cisco’nun kampüs kablosuz platformu ve Aruba’nın Mobility Master/Controller mimarisi baskın örneklerdir.

Bulut Yönetimli (Modern Yaklaşım)

Erişim noktalarının daha fazla zekası vardır. Yönetim, yapılandırma ve görünürlük buluttadır; veri düzlemi trafiği doğrudan ağa gider:

[AP] ──veri──→ Çekirdek Ağ (doğrudan, hairpin yok)
[AP] ──yönetim tüneli──→ Bulut Panosu

Güçlü yönler: Şirket içi controller donanımı yok. Dağıtık siteler arasında daha kolay yönetim. Yerleşik izleme ve analitik. Daha düşük operasyonel karmaşıklık.

Zayıf yönler: Yönetim için bulut bağlantısına bağımlı (AP’ler buluta ulaşılamazsa çalışmaya devam eder). Karmaşık kurumsal politikalar için daha az esnek.

Cisco Meraki ve Aruba Central, önde gelen bulut yönetimli platformlardır.

Dağıtık / Kampüs Fabric

Modern büyük kampüs deployment’ları çoğunlukla kablosuzu daha geniş ağ fabric’ine entegre eder — AP’ler, cihaz kablo veya kablosuz bağlansın tutarlı erişim kontrolüyle kimlik tabanlı VLAN atamasıyla kablolu portlarla aynı politika ve segmentasyon modeline katılır.

SD-Access ile Cisco DNA Center ve Central ile Aruba CX bu yaklaşımın örnekleridir.

→ Kurumsal Controller Mimarisi Deep Dive

KOBİ, Otel ve Muayenehane: Tasarım Prensipleri

Tüketici WiFi ekipmanı, profesyonel ortamlarda düşük kalite nedeniyle değil — yoğunluk, yönetim gereksinimleri veya bu ortamların güvenlik beklentileri için tasarlanmadığı için başarısız olur.

KOBİ (Küçük ve Orta Ölçekli İşletme)

Tipik KOBİ zorluğu: arka ofiste veya toplantı odasında WiFi’nin yavaş olduğundan şikayet eden personel — resepsiyonda tam sinyal olmasına rağmen. Kök nedenler neredeyse her zaman şunlardır:

• RF kapsamı yerine kablolama kolaylığına göre yerleştirilen AP’ler
• Kullanılabilir veri hızlarında fiziksel olarak kapsaması imkânsız bir katı kapsama almaya çalışan tek AP
• Band yönlendirme yok — yeni cihazlar beklerken eski cihazlar 2,4 GHz’i monopolleştiriyor
• QoS yok — video görüşmeleri dosya yedeklemeleriyle eşit rekabet ediyor

KOBİ kablosuz tasarım prensipleri:

• Ofis ortamlarında 150–200 m² başına bir AP planlayın (evrensel kural değil, tipik yükler için gerçekçi bir başlangıç noktası)
• Her zaman misafir ve kurumsal trafiği ayırın (farklı SSID’ler, farklı VLAN’lar, aralarında firewall politikası)
• Operasyonel sadelik için bulut yönetimli AP’ler kullanın (Aruba Instant On, Meraki Go, Cisco Business)

Otel WiFi’si

Oteller belirli bir zorluk sunar: odalarda yüksek istemci yoğunluğu (her misafir 3–5 cihaz getirir), günün saatine göre son derece değişken talep ve “WiFi"nin sıcak su gibi bir hizmet olduğu beklentisi — her zaman mevcut, hiçbir zaman düşünülmeyen.

Temel otel WiFi tasarım kararları:

• AP yerleşimi: Odaları kapsayan koridor AP’leri ve oda içi AP’ler karşılaştırması. Oda içi AP’ler odalar arasında daha iyi sinyal izolasyonu sağlar (daha az girişim) ancak daha yüksek deployment maliyeti ve bakım karmaşıklığı.
• Bant genişliği yönetimi: Kullanıcı başına hız sınırlama, tek misafirin paylaşılan uplink’i doyurmasını önler. Tek bir 4K video akışının düzinelerce diğer kullanıcıyı etkileyebildiği ortamlarda gerekli.
• Misafir portalı: Kimlik doğrulama, şartlar kabul, potansiyel olarak oda numarası doğrulama. Otomatik sağlama için PMS (Otel Yönetim Sistemi) ile entegrasyon.
• Personel ve misafir ağı: Tamamen ayrı — personel ağına hiçbir koşulda misafir ağından erişilememeli.

→ KOBİ, Oteller ve Muayenehane İçin WiFi Tasarımı Deep Dive

Roaming ve Band Yönlendirme

Roaming: Göründüğünden Neden Daha Zordur

Roaming — bir istemcinin bir AP’den diğerine geçişi — pek çok kablosuz deployment’ın sessizce başarısız olduğu yerdir. Belirtiler “WiFi sorunları” gibi görünür ama kök neden roaming davranışıdır.

Yapışkan istemci sorunu: Bir istemci cihaz, AP değil, ne zaman dolaşacağına kendisi karar verir. 30 metre ötedeki AP-1’e güçlü bağlantısı olan bir dizüstü bilgisayar, 5 metre ötedeki AP-2’ye dolaşmayı reddedebilir, çünkü AP-1’e bağlantısı teknik olarak hâlâ işlevseldir. AP, istemciyi dolaşmaya zorlayamaz (istemci yönlendirme mekanizmaları kullanmadan).

Hızlı roaming protokolleri:

• 802.11r (Fast BSS Transition): İstemcinin mevcut AP’den tam olarak bağlantısını kesmeden önce hedef AP ile önceden kimlik doğrulama yaparak roaming süresini azaltır. Bağlantı kesintilerinin görüşme düşmelerine neden olduğu ses ve video uygulamaları için gerekli.
• 802.11k (Komşu Raporları): AP, istemciye yakındaki AP’lerin ve sinyal güçlerinin listesini sağlar, istemcilerin daha iyi roaming kararları vermesine yardımcı olur.
• 802.11v (BSS Geçiş Yönetimi): AP’lerin bir istemcinin farklı bir AP’ye dolaşmasını önermesine veya talep etmesine olanak tanır — ağa istemci roaming davranışı üzerinde biraz etki verir.

Kurumsal deployment’larda, en iyi roaming davranışı için üç protokolün (topluca 802.11r/k/v olarak adlandırılır) birlikte etkinleştirilmesi gerekir.

Band Yönlendirme

Çift bantlı AP’ler hem 2,4 GHz hem de 5 GHz üzerinde yayın yapar. Kendi tercihlerine bırakıldığında, birçok istemci 2,4 GHz’i seçer — daha uzun menzili vardır ve tanıdıktır. Ancak 2,4 GHz’in (çoğu bölgede) yalnızca 3 örtüşmeyen kanalı vardır, komşu ağlar ve IoT cihazları tarafından yoğun biçimde kullanılır ve daha düşük verim sağlar.

Band yönlendirme, yetenekli istemcileri 5 GHz’e (veya WiFi 6E deployment’larında 6 GHz’e) iter:

• 2,4 GHz probe yanıtlarını geciktir — yanıt bekleyen istemciler 5 GHz’i dener
• Aktif yönlendirme — controller 5 GHz’e yetenekli istemcileri tanımlar ve 2,4 GHz ilişkisini reddeder

Tüm istemciler agresif band yönlendirmeye iyi yanıt vermez. Eski veya daha az yetenekli cihazlar için yönlendirme ile bağlantı arasındaki dengeyi bulun.

WiFi Güvenliği: Çoğu Ekibin Yanlış Yaptığı Katman

WiFi güvenliği yalnızca SSID’deki bir şifre değildir. Kurumsal ortamlarda kimlik doğrulama mimarisini, şifreleme standartlarını, ağ segmentasyonunu ve sahte altyapıyı izlemeyi içerir.

Kimlik Doğrulama: PSK’dan 802.1X’e

WPA2-PSK / WPA3-SAE (Önceden Paylaşılan Anahtar): Tüm kullanıcılar için tek şifre. Basit, ancak kritik zayıflıkları var: bir sızdırılan şifre tüm kullanıcıları tehlikeye atar, bireysel hesap verebilirlik yoktur ve iptal her yerde şifreyi değiştirmeyi gerektirir.

WPA2/WPA3-Enterprise (802.1X): Her kullanıcı, bireysel kimlik bilgileriyle (kullanıcı adı/şifre, sertifika veya akıllı kart) bir RADIUS sunucusuna (Windows NPS, Cisco ISE, Aruba ClearPass) karşı kimlik doğrular. Faydaları:

• Bireysel hesap verebilirlik — tam olarak hangi kullanıcının bağlı olduğunu bilirsiniz
• Ayrıntılı iptal — diğerlerini etkilemeden tek kullanıcıyı devre dışı bırakın
• Dinamik VLAN ataması — kimlik, departman veya cihaz türüne göre kullanıcıları farklı VLAN’lara yerleştirin
• Grup üyeliğine dayalı otomatik erişim için Active Directory ile entegrasyon

Hassas veriler işleyen herhangi bir kurumsal ortam için 802.1X isteğe bağlı değildir — taban çizgisidir.

Şifreleme: WPA3 ve Neden Önemlidir

WPA3, WPA2’nin PSK el sıkışmasının yerini alan SAE (Simultaneous Authentication of Equals) getirdi. Kritik iyileştirme: SAE ileri gizlilik sağlar — el sıkışmayı yakalamak ve daha sonra şifreyi elde etmek, daha önce yakalanan trafiğin şifresini çözmeye izin vermez.

WPA2 (PMKID saldırılarıyla), yakalanan el sıkışmalarının çevrimdışı kaba kuvvet kırılmasına olanak tanıyordu. WPA3 bu saldırı vektörünü ortadan kaldırır.

802.1X kullanan kurumsal deployment’lar için, 192 bit güvenlik modundaki WPA3-Enterprise mevcut en güçlü kablosuz şifrelemeyi sağlar.

Sahte AP Tespiti

Sahte AP, ağınıza bağlı yetkisiz bir erişim noktasıdır — kötü niyetle yerleştirilen veya ofise ev yönlendiricisi getiren iyi niyetli bir çalışan.

Kurumsal kablosuz controller’lar RF ortamını sürekli olarak AP’ler için tarar. Kablolu ağınızın BSSID’si veya SSID’siyle eşleşen bir AP tespit edildiğinde, sahte olarak işaretlenir ve — çoğu platformda — otomatik olarak çevrelenebilir (controller, sahte AP’ye bağlanan istemcilere kimlik doğrulama iptali çerçeveleri gönderir).

→ WiFi Güvenliği Deep Dive: WPA3, 802.1X, Sahte AP Tespiti ve Site Survey

Site Survey: Çoğu Projenin Atladığı Adım

Site survey, AP deployment öncesinde ve sonrasında RF ortamının sistematik olarak ölçülmesidir. Bu adımı atlamak, “WiFi deployment yaptık ama düzgün çalışmıyor” durumlarının en yaygın nedenidir.

Tahmine dayalı survey (deployment öncesi): Beklenen kapsama alanını modellemek için bir kat planı ve duvar malzemeleriyle RF simülasyon yazılımı (Ekahau Site Survey sektör standardıdır) kullanın. Herhangi bir şey kurmadan AP yerleşimini, kanal atamalarını ve güç seviyelerini belirleyin.

Doğrulama surveyi (deployment sonrası): Ekahau çalıştıran bir dizüstü bilgisayarla alanı yürüyerek gerçek sinyal gücünü, gürültü tabanını, kanal kullanımını ve roaming davranışını ölçün. Tahmine dayalı modelle karşılaştırın ve gerektiğinde AP yerleşimini veya ayarlarını düzenleyin.

Site survey’in ortaya koyduğu şeyler:

• Tahmine dayalı modelin öngörmediği kapsama boşlukları (beklenmedik girişim kaynakları, beklenenden daha fazla zayıflatan duvar malzemeleri)
• Komşu ağlardan kanal tıkanıklığı
• Kendi AP’leriniz arasındaki aynı kanal girişimi
• İstemcilerin AP’ler arasında bağlantıyı kaybettiği roaming ölü noktaları

Uygun bir site survey’in maliyeti, kurulumdan sonra önemli yeniden çalışma gerektiren kablosuz deployment maliyetiyle karşılaştırıldığında küçüktür.

→ WiFi Güvenliği Deep Dive, Site Survey metodolojisini içerir

Doğru Platformu Seçme

Bu Seri

• 📡 802.11 Standartları Deep Dive — WiFi 4, 5, 6, 6E ve 7: ne değişti, pratikte ne önemli
• 🏢 Kurumsal Controller Mimarisi — Cisco ve Aruba mimarileri, merkezi ve bulut karşılaştırması, mobilite alanları
• 🏨 KOBİ, Oteller ve Muayenehane İçin WiFi Tasarımı — Gerçek dünya deployment senaryolarında pratik saha notları
• 🔐 WiFi Güvenliği: WPA3, 802.1X, Sahte AP, Site Survey — Kimlik doğrulama, şifreleme, saldırı tespiti, Ekahau metodolojisi

İlgili Yazılar

• 🔐 802.1X Kimlik Tabanlı Mimari Sahada — Kurumsal WiFi güvenliğini işlevsel kılan kimlik katmanı
• 🏗️ IT Altyapısı Ürünler Koleksiyonu Değildir — Kablosuz tasarımın arkasındaki sistem düşüncesi
• 🎯 Ağ Altyapısı Ürün Seçimi: Stratejik Kriterler — Kablosuz satıcıları nesnel olarak nasıl değerlendirirsiniz

Bir DDoS (Dağıtılmış Hizmet Reddi) saldırısı sistemlerinizi ele geçirmek zorunda değildir. Sadece erişilemez hale getirmesi yeterlidir. Ve diğer güvenlik tehditlerinin aksine, hasar anlık ve tamamen görünürdür — uygulamanız çalışmayı durdurur, müşteriler size ulaşamaz ve gelir durur.

DDoS’u benzersiz biçimde zorlaştıran şey, saldırı trafiğinin paket düzeyinde meşru görünmesidir. Milyonlarca geçerli TCP SYN paketi, milyonlarca geçerli DNS sorgusu, milyonlarca geçerli HTTP isteği — hepsi mükemmel biçimlendirilmiş, hepsi tamamen kasıtlı. Ağınız bunları gerçek trafikle aynı şekilde işler, ve bu tam olarak sorunun ta kendisidir.

DDoS korumasının yasal bir gereklilik olduğu — sadece en iyi uygulama değil — bankacılık altyapısında çalışmış biri olarak, organizasyonların kendilerini gerçekte nasıl koruduğunu aktarmak istiyorum: üç ana yaklaşımın ne olduğu, her birinin ne yapıp yapamadığı ve pratikte nasıl bir araya geldikleri.

Saldırı Yüzeyini Anlamak

Koruma stratejisi seçmeden önce, neye karşı korunduğunuzu net olarak belirlemek faydalıdır. DDoS saldırıları üç kategoriye ayrılır ve temelden farklı azaltma yaklaşımları gerektirirler.

Volumetrik Saldırılar (Katman 3/4)

En görünür tür. Amaç basittir: internet bağlantınızı taşıyabileceğinden daha fazla trafikle doyurmak.

Yaygın teknikler:

• UDP flood — rastgele portlara büyük hacimde UDP paketi göndermek. Hedef her birine “port erişilemez” ICMP yanıtı gönderir, hem gelen hem giden bant genişliğini tüketir.
• ICMP flood (Ping flood) — ping istekleriyle bunaltmak.
• Amplifikasyon saldırıları — en tehlikeli varyant. Saldırgan, kaynak olarak IP’nizi kullanarak yanlış yapılandırılmış üçüncü taraf sunucularına (DNS çözücüler, NTP sunucuları, memcached örnekleri) küçük istekler gönderir. Bu sunucular size büyük yanıtlar gönderir. DNS amplifikasyonu 50–70× amplifikasyon sağlayabilir; memcached amplifikasyonu 51.000בe ulaşmıştır.

Ölçek: Modern volumetrik saldırılar rutin olarak 1 Tbps’yi aşar. 10 Gbps’lik bir internet bağlantısı buna karşı anlamsızdır — firewall’unuza tek bir paket ulaşmadan doyuma ulaşırsınız.

Temel içgörü: ISP uplink’inizi aşan saldırı hacminde volumetrik saldırıları kendi tesislerinizde azaltamazsınız. Trafik bağlantınıza ulaşmadan önce yukarı akışta — ISP veya bulut seviyesinde — filtrelenmelidir.

Protokol Saldırıları (Katman 3/4)

Bant genişliği yerine ağ cihazı kaynaklarını tüketir.

• SYN flood — el sıkışmayı tamamlamadan milyonlarca TCP SYN paketi göndermek. Hedef her yarı açık bağlantı için bellek ayırır, bağlantı tablosu dolana ve meşru bağlantılar reddedilene kadar.
• Parçalanmış paket saldırıları — yeniden birleştirme tamponlarını bunaltan hatalı biçimlendirilmiş veya üst üste binen IP parçaları göndermek.
• Smurf saldırısı — sahte kaynak IP’ler kullanan ICMP broadcast amplifikasyonu.

Ölçek: Bant genişliğiyle değil, saniyedeki paket sayısıyla (Mpps) ölçülür. Küçük paket boyutlarında 100 Mbps’lik bir SYN flood, orta düzey bir firewall’un bağlantı tablo kapasitesini aşabilir.

Temel içgörü: Protokol saldırıları, FPGA tabanlı paket işleme ile özel DDoS donanımı tarafından on-premise azaltılabilir — ancak yalnızca hacim uplink’inizi önceden doyurmadıysa.

Uygulama Katmanı Saldırıları (Katman 7)

Tespit ve azaltması en zor olanlar. Trafik meşru HTTP/HTTPS’tir — kötü niyetli olan niyet.

• HTTP flood — kaynak yoğun uç noktalara (arama, giriş, rapor oluşturma) milyonlarca HTTP GET veya POST isteği göndermek.
• Slowloris — çok sayıda bağlantı açmak ve HTTP başlıklarını çok yavaş göndermek, istekleri tamamlamadan bağlantıları açık tutmak. Sunucunun bağlantı havuzunu tüketir.
• RUDY (R-U-Dead-Yet) — Slowloris’e benzer ama POST gövdeleri için. Veriyi bir seferde bir bayt gönderir.
• SSL tüketimi — TLS el sıkışmalarını başlatmak ama hiçbir zaman tamamlamamak veya el sıkışmaları tamamlayıp hemen yeniden müzakere etmek. Donanım SSL hızlandırması olmayan sunucular için CPU yoğun.

Ölçek: Düşük trafik hacimlerinde yıkıcı biçimde etkili olabilir — milyonlarca normal isteği işleyen bir web sunucusunu saniyede birkaç bin istek hedefleyerek çökertebilir.

Temel içgörü: Katman 7 saldırıları uygulama destekli azaltma gerektirir. Volumetrik bir scrubbing servisi kötü niyetli bir HTTP flood’u meşru trafikten ayırt edemez.

Üç Koruma Yaklaşımı

Hiçbir tek koruma yaklaşımı tüm ölçeklerdeki tüm saldırı türlerini kapsamaz. Ciddi DDoS maruziyeti olan organizasyonlar tipik olarak bu katmanlardan ikisini veya üçünü birleştirir.

1. ISP Tabanlı Scrubbing Servisleri

Nasıl Çalışır

ISP’niz (veya yukarı akış ağ anlaşmalarına sahip uzman bir scrubbing sağlayıcısı), bir saldırı sırasında trafiğinizi bir scrubbing merkezine yönlendirir. Scrubbing merkezinde saldırı trafiği filtrelenir ve yalnızca temiz trafik ağınıza iletilir:

Normal işlem:
  İnternet → ISP → Ağınız

Saldırı sırasında:
  İnternet → ISP → Scrubbing Merkezi → Temiz trafik → Ağınız
                          │
                   Saldırı trafiği düşürülür

Trafik yönlendirmesi tipik olarak iki şekilde tetiklenir:

• İstek üzerine: Saldırı tespit edildiğinde ISP ile iletişime geçersiniz. Manuel süreç, yanıt süresi sağlayıcıya bağlıdır.
• Her zaman açık: Trafik sürekli olarak scrubbing üzerinden yönlendirilir. Tespit gecikmesi yoktur, ancak gecikme ekler.

ISP Scrubbing’in Koruduğu Şeyler

ISP scrubbing özellikle volumetrik saldırılar için tasarlanmıştır. Altyapınızın yukarı akışında, ağ katmanında çalışır. 10 Gbps bağlantınızı doyuracak bir saldırı, sağlayıcının 10 Tbps+ kapasitesi tarafından size ulaşmadan emilir.

ISP Scrubbing’in Yapamadıkları

• Katman 7 koruması: ISP scrubbing L3/L4’te çalışır. HTTP istek içeriğini analiz edemez.
• Yavaş ve düşük hacimli saldırılar: Slowloris, RUDY ve SSL tüketimi volumetrik değildir.
• Anlık yanıt: İstek üzerine scrubbing, trafik yönlendirilirken tipik olarak 15–30 dakikalık bir aktivasyon gecikmesine sahiptir.

ISP Scrubbing Ne Zaman Mantıklıdır

• Birincil tehdidiniz volumetrik saldırılardır (altyapıyı hedef alan en yaygın tür)
• ISP bağlantınız 10 Gbps veya daha azdır
• Donanım maliyetlerini haklı kılamazsınız ama DDoS koruması için düzenleyici gereklilikleriniz vardır
• Maliyet etkin bir temel koruma katmanı istiyorsunuz

2. On-Premise DDoS Cihazları

Nasıl Çalışır

Özel bir donanım cihazı (veya sanal cihaz), firewall’unuzun yukarısında, ağınızda inline konumlanır:

İnternet → [ISP Router] → [DDoS Cihazı] → [NGFW] → İç Ağ

Cihaz tüm trafiği gerçek zamanlı olarak analiz eder ve saldırı paketlerini firewall’unuza veya sunucularınıza ulaşmadan düşürür. Yazılım tabanlı çözümlerin aksine, özel amaçlı DDoS cihazları paket işleme için FPGA (Alan Programlanabilir Kapı Dizisi) donanımı kullanır.

Önde Gelen On-Premise Çözümler

NETSCOUT Arbor (Peakflow / Sightline / TMS) Özellikle bankacılık ve telekom sektöründe baskın kurumsal çözüm. Arbor, on-premise DDoS koruması için sektör standardı olarak yaygın biçimde kabul görür. Platform şunları birleştirir:

• Sightline: Akış verileri (NetFlow, sFlow, IPFIX) ve BGP kullanarak trafik analizi ve saldırı tespiti
• Threat Mitigation System (TMS): Inline veya out-of-band kullanılan donanım tabanlı scrubbing cihazı
• Arbor’un küresel tehdit istihbaratı ağıyla (ATLAS) entegrasyon

Radware DefensePro Finansal hizmetlerde güçlü. Normal trafiğin dinamik bir temelini oluşturan ve anomalileri tespit eden davranış tabanlı tespit özelliği — bilinen imzalarla eşleşmeyen sıfır-gün DDoS saldırılarına karşı etkili.

Fortinet FortiDDoS Fortinet ekosistemiyle entegre. Tutarlı yönetim için FortiGate firewall’ları zaten çalıştıran organizasyonlar için uygundur.

F5 BIG-IP AFM (Advanced Firewall Manager) F5 serisinde ele alındığı gibi — AFM, BIG-IP platformunun parçası olarak DDoS azaltma özellikleri sağlar. Uygulama teslimi için zaten F5 çalıştıran ve mevcut donanıma DDoS koruması eklemenin maliyet etkin olduğu ortamlara en uygunudur.

On-Premise Cihazların Koruduğu Şeyler

• Protokol saldırıları: SYN flood’lar, parçalanmış paketler, hatalı biçimlendirilmiş başlıklar — firewall’a ulaşmadan donanım hızında işlenir
• Uygulama katmanı saldırıları: Davranışsal analizle gelişmiş cihazlar HTTP flood’larını, Slowloris’i ve SSL tüketimini tespit edip azaltabilir
• Sıfır-gün davranışsal saldırılar: Hız tabanlı ve davranışsal tespit, bilinen imzalar gerektirmeden saldırı kalıplarını tanımlar

On-Premise’in Yapamadıkları

ISP bağlantınızı aşan volumetrik saldırılar: Veri merkezinizdeki bir on-premise cihaz, 500 Gbps’lik saldırı trafiği 10 Gbps’lik internet bağlantınızı doldurduğunda yardım edemez. Bu temel sınırlamadır.

Bu nedenle on-premise cihazlar ve ISP scrubbing tamamlayıcıdır, rekabetçi değil.

3. Bulut DDoS Koruma Servisleri

Nasıl Çalışır

Bulut DDoS koruması tüm trafiğinizi sağlayıcının küresel dağıtık ağı üzerinden yönlendirir. Temiz trafik kaynak sunucularınıza teslim edilir; saldırı trafiği kenarda düşürülür:

Bulut koruması olmadan:
  Kullanıcı → İnternet → Sunucunuz

Bulut korumasıyla:
  Kullanıcı → [Cloudflare / Akamai / AWS kenar] → Sunucunuz
                          │
                   Saldırı trafiği ağ kenarında düşürülür

Önde Gelen Bulut Çözümleri

Cloudflare En yaygın bilinen bulut DDoS sağlayıcısı. Cloudflare, dünyanın en büyük anycast ağlarından birini işletiyor — küresel 300+ PoP, 230 Tbps’yi aşan toplam kapasiteyle. Temel özellikler:

• Manuel müdahale olmadan otomatik DDoS azaltma
• Tek bir platformda Katman 3, 4 ve 7 koruması
• WAF entegrasyonu — uygulama güvenliği ve DDoS azaltma aynı sağlayıcıdan
• Altyapı düzeyi koruma için Magic Transit (BGP tabanlı, yalnızca HTTP değil)
• Ölçüsüz DDoS azaltma — saldırılar sırasında GB başına ücret yok

AWS Shield

• Shield Standard: Tüm AWS kaynakları için otomatik olarak dahildir. Yaygın L3/L4 saldırılara karşı korur.
• Shield Advanced: L7 koruması, 7/24 DDoS Yanıt Ekibi erişimi ve AWS WAF ile entegrasyon içeren ücretli katman.
• Önemli AWS altyapısına sahip organizasyonlar için en uygunudur.

Akamai Prolexic Kurumsal odaklı bulut scrubbing platformu. 20+ küresel dağıtık scrubbing merkezi işletiyor. Finansal hizmetler ve medyada güçlü referanslar.

Azure DDoS Protection Azure barındırmalı kaynaklar için Microsoft’un teklifi. Azure’da önemli iş yükleri çalıştıran organizasyonlar için en uygunudur.

Bulut Korumanın Dezavantajları

• Gecikme: Tüm trafik sağlayıcının ağından geçer. Çoğu web uygulaması için kenar PoP’larının eklediği gecikme ihmal edilebilir veya negatiftir. Gecikmeye duyarlı uygulamalar için dikkatli değerlendirin.
• Gizlilik/uyumluluk: SSL ile şifresi çözülmüş içerik dahil tüm trafik sağlayıcının altyapısından geçer. Düzenlenmiş sektörlerde dikkatli inceleme gerektirir.
• DNS bağımlılığı: DNS tabanlı bulut koruması, saldırganlar kaynak IP’nizi keşfederse atlatılabilir. Kaynak IP’leri yalnızca bulut sağlayıcısının IP aralıklarına izin verecek şekilde firewall düzeyinde koruyun.

Üç Yaklaşımın Karşılaştırması

Hibrit Model: Ciddi Organizasyonlar Üçünü Nasıl Birleştirir

Yüksek riskli ortamlarda — bankacılık, ödeme işlemcileri, devlet altyapısı, büyük e-ticaret — tek bir koruma katmanı hiçbir zaman yeterli değildir. Standart mimari üçünü birleştirir:

Saldırı trafiği
      │
      ▼
[Bulut / ISP Scrubbing]    ← Volumetrik taşmaları size ulaşmadan emer
      │
  Temizlenmiş trafik
      │
      ▼
[On-Premise Cihaz]         ← Protokol saldırılarını ve L7 anomalileri yakalar
      │
      ▼
[NGFW + WAF]               ← Uygulama güvenliği ve politika uygulaması
      │
      ▼
[Uygulama Sunucuları]

Her katman diğerlerinin yapamadıklarını halleder. Kombinasyon, DDoS saldırı türlerinin tüm yelpazesine karşı dayanıklı derinlemesine savunma oluşturur.

Gerçek Dünya Örneği: Bankacılık Sektörü

Çalıştığım bankacılık ortamında DDoS koruma yığını şöyleydi:

• Arbor TMS on-premise — protokol saldırıları için inline scrubbing, anomali tespiti için gerçek zamanlı akış analizi, otomatik trafik yönlendirmesi için BGP ile entegrasyon
• ISP scrubbing sözleşmesi — Arbor, uplink’i doyuracak volumetrik saldırı imzaları tespit ettiğinde etkinleştirildi
• Cloudflare Magic Transit — WAF entegrasyonuyla always-on bulut düzeyi koruma sağlayan halka açık web uygulamaları için
• F5 AFM — uygulama teslim katmanında ek L4 koruması

Bu gereksiz yere yedeklilik değildi — her katman diğerlerinin yapamadıklarını halletti.

DDoS Yanıt Planlaması: Teknik Olmayan Kısım

Teknoloji, DDoS hazırlığının yalnızca bir parçasıdır. Diğer kısım organizasyoneldir:

Runbook’lar: Bir saldırı başladığında tam olarak ne yapılacağını belgeleyin. Kim bildirilecek? Kim ISP scrubbing’i etkinleştirecek? Yükseltme yolu ne? Saldırı altında bunu çözmek için doğru zaman değildir.

İletişim listeleri: ISP scrubbing etkinleştirme, bulut sağlayıcı desteği, yukarı akış router erişimi, nöbetçi ağ mühendisleri. Hepsi güncel, hepsi test edilmiş.

Eşikler ve otomasyon: Otomatik azaltmanın ne zaman devreye gireceğini ve insan incelemesinin ne zaman gerekli olduğunu tanımlayın. Tam manuel yanıtlar modern saldırı oranları için çok yavaştır.

Düzenli test: Hiç test edilmemiş bir DDoS koruma yığını, gerçekte güvenmediğiniz bir DDoS koruma yığınıdır. ISP’niz ve bulut sağlayıcınızla periyodik testler planlayın.

Olay sonrası inceleme: Her önemli saldırının ardından, neyin işe yaradığını, neyin yaramadığını ve saldırı trafiğinin neye benzediğini gözden geçirin. DDoS taktikleri evrilir — koruma stratejiniz de öyle olmalıdır.

Temel Çıkarımlar

• DDoS saldırıları üç temel olarak farklı türde gelir — volumetrik, protokol ve uygulama katmanı — ve her biri farklı azaltma gerektirir.
• Hiçbir tek koruma katmanı tüm saldırı türlerini kapsamaz. Volumetrik saldırılar yukarı akış scrubbing kapasitesi gerektirir; protokol saldırıları donanım hızında paket işleme gerektirir; L7 saldırıları uygulama destekli analiz gerektirir.
• ISP scrubbing, çok büyük volumetrik saldırılar için tek seçenektir — saldırı bağlantınıza ulaşmadan emilmelidir.
• On-premise cihazlar (Arbor, Radware, F5 AFM) ayrıntılı görünürlük, uyumluluk dostu şirket içi işleme ve etkili protokol/L7 koruması sağlar — ancak ISP bağlantı kapasitesini aşan saldırıları kaldıramaz.
• Bulut servisleri (Cloudflare, AWS Shield, Akamai) büyük ölçek, küresel dağılım ve donanım yatırımı olmadan always-on koruma sunar — ancak trafik yönlendirmesini üçüncü taraf altyapıdan geçirir.
• Yüksek riskli ortamlarda, üç katman birlikte çalışır. Bu aşırı mühendislik değildir — ciddiye alınan organizasyonların pratikte kullandığı mimaridir.

İlgili Yazılar

• 🛡️ F5 BIG-IP Platform Genel Bakış — DDoS savunmanın derinliğinin bir parçası olarak F5 AFM
• 🔐 Zero Trust Zihniyeti: Güvenliği Bir Mimari Olarak Mühendislemek — Zero Trust çerçevesinde DDoS koruması
• 🛡️ Network Packet Broker (NPB) Masterclass — DDoS adli analizi için gerekli trafik görünürlüğü
• 📊 İzleme Doğru Yapıldığında — Proaktif izleme yoluyla DDoS’u erken tespit etmek

Kurumsal bir ortamda F5’e en yaygın giriş şöyle gerçekleşir: biri “load balancer çöktü” yazan bir ticket açar ve F5’i işaret eder. Sorun zaten o cümlede gizlidir.

F5 BIG-IP bir load balancer değildir. Ona öyle demek, bir veri merkezine sunucu odası demek gibidir — teknik olarak yanlış değil, ama konuyu tamamen kaçırıyor.

F5 BIG-IP bir Uygulama Teslim Controller’ı (ADC)‘dır: uygulamaları yerel ve global altyapıda yöneten, güvence altına alan, optimize eden ve yüksek erişilebilir kılan full-proxy bir platformdur. Load balancing, yaptığı belki düzine şeyden yalnızca biridir.

Bu Seriyi Nasıl Okuyalım

Bu yazı size büyük resmi verir — F5’in ne olduğu, nerede durduğu, her modülün ne yaptığı ve alternatiflere göre ne zaman mantıklı olduğu.

Ağ veya güvenlik mühendisiyseniz ve yapılandırma, iRule’lar, migrasyon saha notları ve mimari detaylara derinlemesine inmek istiyorsanız — doğrudan ilgilendiğiniz modüle atlayın:

• 🔧 F5 LTM Deep Dive — Virtual server’lar, pool’lar, iRule’lar, SSL offloading, HA ve 30 cihazlık migrasyon rehberi
• 🌐 F5 GTM ve GSLB Deep Dive — iQuery, Wide IP’ler, topoloji routing, DNS TTL stratejisi, çok DC failover tasarımı
• 🛡️ F5 WAF Deep Dive — ASM ve Advanced WAF, OWASP Top 10, bot savunması, şeffaftan engellemeye deployment stratejisi

Mimar veya karar vericiyseniz ve F5’in altyapınıza uyup uymadığını değerlendiriyorsanız — okumaya burada devam edin. Bu yazı, iRule sözdizimini anlamanızı gerektirmeden o soruyu yanıtlıyor.

F5 Kurumsal Mimaride Nerede Durur?

F5 BIG-IP, firewall ile uygulama sunucuları arasında çalışır:

İnternet
    │
[DDoS Scrubbing / ISP]
    │
[NGFW — Palo Alto / Fortinet]   ← L3/L4: routing, IP filtreleme, VPN, stateful inspection
    │
[F5 BIG-IP]                     ← L4–L7: uygulama teslimi, SSL, sağlık, routing mantığı
    │
[Backend Sunucular / Uygulama Kümeleri]

Firewall, ağ düzeyindeki kararları alır. F5, bunun üzerindeki her şeyi yönetir — SSL sonlandırma, sağlık bilincine sahip load balancing, session persistence, trafik manipülasyonu ve Katman 7 güvenliği.

Bu ayrım önemlidir çünkü bir firewall F5’in yaptığını yapmak üzere tasarlanmamıştır. Saniyede binlerce SSL oturumunu verimli biçimde sonlandıramaz, sağlık izleme için HTTP yanıt gövdelerini inceleyemez, uygulama başlıklarını anında yeniden yazamaz ya da URI yolları, çerezler veya kullanıcı kimliğine dayalı routing kararları veremez.

İki veri merkezi tasarımında mimari genişler:

               [F5 GTM]        ← DNS düzeyi: istemcileri doğru DC'ye yönlendirir
              /         \
         [DC-1]         [DC-2]
       [F5 LTM]       [F5 LTM] ← Yerel: her DC içinde trafiği dağıtır
           │               │
      Uygulama Sunucuları  Uygulama Sunucuları

GTM her iki LTM’nin üzerinde oturur ve DNS sorgularını yanıtlar — istemcileri sağlık, yük ve coğrafyaya göre uygun veri merkezine yönlendirir. Bu, çok DC failover’ını manuel yerine otomatik yapan şeydir.

Tam Modül Haritası

TMOS (Traffic Management Operating System) temeldir. Her F5 modülü onun üzerinde çalışır. Hangi modülün hangi sorunu çözdüğünü anlamak, hem mimari tasarım hem de lisanslama görüşmeleri için anahtardır.

LTM — Local Traffic Manager

Temel modül. Neredeyse her F5 deployment’ı buradan başlar.

LTM, bir full-proxy ADC‘dir: her istemci bağlantısını sonlandırır, inceler, routing ve politika kararları alır ve backend’e yeni bir bağlantı açar. Bu full-proxy konumu, uygulama trafiği üzerinde tam görünürlük ve kontrol sağlar.

LTM’nin sunduğu özellikler:

• Backend sunucu pool’larında load balancing — yalnızca TCP erişilebilirliğini değil, uygulama yanıtlarını anlayan sağlık izleme ile
• SSL/TLS offloading — backend’ler adına HTTPS sonlandırma, şifreleme yüklerini kaldırma
• Session persistence — kullanıcıları istekler genelinde aynı backend sunucusuna bağlı tutma
• iRule’lar — trafik düzeyinde hat hızında çalışan programlanabilir bir betik katmanı: başlık yeniden yazma, URI’ye göre yönlendirme, içerik ekleme, hız sınırı uygulama
• Yüksek erişilebilirlik — saniye altı failover ile Aktif-Yedek veya Aktif-Aktif kümeleme

→ F5 LTM Deep Dive: Virtual Server’lar, iRule’lar, SSL Offloading ve HA

GTM / DNS — Global Traffic Manager

LTM trafiği tek bir veri merkezi içinde yönetir. GTM trafiği veri merkezleri arasında yönetir — DNS düzeyinde.

Bir istemci webapp.sirket.com‘u çözümlediğinde, GTM DNS sorgusunu yanıtlar. Yanıtı, hangi veri merkezinin sağlıklı olduğuna, mevcut yüke ve istemcinin coğrafi olarak nerede bulunduğuna bağlıdır.

GTM’nin temel özelliği iQuery‘dir — doğrudan LTM’den gerçek zamanlı uygulama sağlık verisi sağlayan özel bir protokol. Bir backend uygulaması başarısız olduğunda ve LTM pool’unu down olarak işaretlediğinde, GTM bunu anında bilir ve DNS TTL süresinin dolmasını beklemeden yeni istemcileri o veri merkezine yönlendirmeyi durdurur.

GTM’nin sunduğu özellikler:

• Birden fazla veri merkezinde Global Server Load Balancing (GSLB)
• Bir DC çevrimdışı olduğunda otomatik DNS düzeyinde failover
• Topoloji tabanlı routing — Avrupalı kullanıcılar AB veri merkezlerine, Orta Doğulu kullanıcılar bölgesel DC’lere
• Esnek politikalar: her zaman birincil tercih et (Global Availability), eşit dağılım (Round Robin) veya bağlantı bilincine sahip (Least Connections)

→ F5 GTM ve GSLB Deep Dive: Global Trafik Yönetimi ve DNS Failover

WAF — Web Application Firewall (ASM / Advanced WAF)

Bir ağ firewall’u L3/L4’te çalışır. Bir POST isteği gövdesinin SQL injection payload içerip içermediğini inceleyemez. WAF inceleyebilir.

F5 WAF, SSL sonlandırmasından sonra HTTP/HTTPS uygulama trafiğini inceleyerek LTM virtual server’ında inline çalışır. Bu konumlama, şifresi çözülmüş içeriğe tam görünürlük sağlar.

F5 iki WAF katmanı sunar:

• ASM — bilinen saldırılara karşı imza tabanlı koruma, OWASP Top 10 kapsamı, parametre ve çerez zorunluluğu
• Advanced WAF — davranışsal bot savunması, credential stuffing koruması, JavaScript challenge’ları ve L7 DoS azaltmayı ekler

WAF’ın koruduğu şeyler: SQL injection, XSS, CSRF, parametre tampering, çerez zehirlenmesi, zorla gezinme, bot trafiği ve uygulama katmanı DoS.

→ F5 WAF Deep Dive: ASM ve Advanced WAF ile Uygulama Güvenliği

APM — Access Policy Manager

APM, F5’in kimlik ve erişim modülüdür — F5’in trafik tesliminin ötesine geçerek erişim kontrolüne girdiği yer.

• SSL VPN — BIG-IP Edge Client aracılığıyla tam ağ düzeyinde uzak erişim, Cisco AnyConnect veya Fortinet SSL VPN ile karşılaştırılabilir
• Zero Trust Network Access (ZTNA) — tam ağı açığa çıkarmadan kimlik bilincine sahip, uygulama başına erişim
• SSO — uygulamalar genelinde sorunsuz kimlik doğrulama için Kerberos, SAML, OAuth entegrasyonu
• MFA entegrasyonu — RADIUS, LDAP, Active Directory, RSA SecurID
• Endpoint inspection — erişim vermeden önce cihaz sağlığını doğrulama (AV durumu, yama seviyesi, domain üyeliği)

APM’nin bağımsız VPN çözümlerine göre avantajı: LTM ile aynı donanım ve yönetim düzlemini paylaşır. Hem uygulama teslimi hem de uzak erişim için tek platform.

AFM — Advanced Firewall Manager

AFM, F5 platformuna ağ düzeyinde firewall özellikleri ekler:

• L3/L4 stateful paket incelemesi — ADC üzerinde inline çalışan geleneksel bir ağ firewall’una benzer
• DoS ve DDoS koruması — donanım hızlarında hız sınırlama, protokol anomali tespiti, TCP SYN flood azaltma
• IP intelligence — F5’in tehdit istihbaratı beslemeleri aracılığıyla bilinen kötü IP’leri, Tor çıkış node’larını, botnet C2 adreslerini engelleme
• Ağ Adresi Çevirisi (NAT) politikaları

AFM, organizasyonların firewall ve ADC işlevlerini tek bir platformda birleştirmek istediğinde veya ADC’nin kendisine özel bir koruma katmanı ihtiyaç duyulduğunda kullanılır.

BGP ve Dinamik Routing

F5’in en az bilinen özelliklerinden biri: BIG-IP tam bir routing yığını çalıştırır.

TMOS, BGP, OSPF, route domain’li statik rotalar (VRF eşdeğeri) ve ECMP destekler. Pratikte BGP en ilgili olanıdır:

• F5, BGP routing’e katılabilir ve Virtual IP adreslerini BGP rotaları olarak duyurabilir
• Büyük kurumsal ve servis sağlayıcı ortamlarında, BGP aracılığıyla anycast VIP duyurusu, aynı VIP IP’nin birden fazla veri merkezinden duyurulmasına olanak tanır — routing doğal olarak istemcileri en yakın sağlıklı siteye yönlendirir
• Planlı bakım pencerelerinde BGP çekilmesi, manuel DNS değişikliklerine gerek kalmadan trafiği otomatik olarak DR sitelerine kaydırır

Çalıştığım bankacılık ortamında, planlı bakım sırasında VIP duyurularını dinamik olarak çekmek için F5 ile çekirdek routing katmanı arasında BGP kullandık — temiz, otomatik, DNS değişikliği gerektirmiyor.

Link Controller

Link Controller, birden fazla ISP bağlantısında giden internet bağlantısını yönetir:

• Birden fazla upstream ISP bağlantısında load balancing
• Maliyet tabanlı routing — daha ucuz bağlantıları tercih et, gerektiğinde premium bağlantılara geç
• Bağlantı arızasında otomatik yeniden yönlendirme ile ISP sağlık izleme

Basit aktif-yedek yerine akıllı dağılım isteyen çok ISP bağlantısı olan organizasyonlar için en ilgili modüldür.

iRule’lar ve iRules LX

iRule’lar, F5’in programlanabilir trafik katmanıdır — TMOS veri düzleminde hat hızında çalışan Tcl tabanlı betikler. Modüller genelinde uygulanır ve trafiğin herhangi bir yönünü manipüle edebilir: başlıklar, URI’ler, çerezler, routing kararları, SSL özellikleri.

iRules LX, daha karmaşık mantık ve harici API entegrasyonları için bunu bir Node.js çalışma zamanıyla genişletir.

iRule’lar, standart dışı uygulama gereksinimleri olan organizasyonlar için F5’i benzersiz biçimde esnek kılan şeydir — hiçbir profil veya politika kullanım senaryosunu karşılamadığında, bir iRule genellikle karşılar.

F5 Ne Zaman Mantıklıdır — Ne Zaman Değil?

F5 BIG-IP güçlü, operasyonel açıdan olgun ve pahalıdır. Onu kullanma kararı yalnızca itibara değil, belirli gereksinimlere dayanmalıdır.

F5 doğru seçimdir:

• SSL/TLS sonlandırma hacmi yüksek olduğunda — fiziksel cihazlardaki donanım hızlandırması, yazılım çözümlerinin ekonomik olarak karşılayamadığı saniyede binlerce oturumu yönetir
• Uygulamalar, daha basit proxy’lerin uygulama kodu değişiklikleri olmadan ifade edemeyeceği karmaşık trafik mantığı (iRule’lar) gerektirdiğinde
• Birden fazla veri merkezi otomatik DNS düzeyinde failover (GTM) gerektirdiğinde
• Düzenleyici gereklilikler ayrıntılı denetim loguyla WAF zorunlu kıldığında
• Uygulama teslimi, VPN ve L7 güvenliği için tek bir platforma ihtiyaç duyulduğunda — operasyonel karmaşıklığı azaltmak
• Görev-kritik uygulamalar bağlantı durumu yansıtma ile saniye altı HA failover gerektirdiğinde

Alternatifleri değerlendirin:

• Altyapınız tamamen cloud-native olduğunda — AWS ALB, Azure Load Balancer veya GCP Load Balancing çoğu kullanım senaryosunu şirket içi donanım gerektirmeden karşılar
• Trafik hacimleri ılımlı ve Nginx Plus veya HAProxy gereksinimlerinizi çok daha düşük maliyetle karşıladığında
• Uygulamalar durumsuz ve session persistence gerekli olmadığında
• TCO birincil kısıt ve açık kaynak çözümler ekibiniz için operasyonel olarak uygulanabilir olduğunda

Dürüst özet: şirket içi altyapıya ve görev-kritik uygulama gereksinimlerine sahip bankacılık, telekom ve büyük kurumlarda F5 baskın platform olmayı sürdürüyor. Cloud-native veya maliyet kısıtlı ortamlarda, F5 lisanslamaya bağlanmadan önce alternatifleri ciddiye alın.

Bu Seri

Bu yazı başlangıç noktasıdır. Her modülün özel bir deep dive’ı vardır:

• 🔧 F5 LTM Deep Dive: Virtual Server’lar, iRule’lar, SSL Offloading ve HA — Full-proxy mimarisi, pool yapılandırması, health monitor’lar, iRule örnekleri, session persistence, HA kümeleme ve sıfır downtime 30 cihaz migrasyon rehberi
• 🌐 F5 GTM ve GSLB Deep Dive: Global Trafik Yönetimi ve DNS Failover — Wide IP’ler, iQuery, topoloji routing, TTL stratejisi, aktif-aktif ve aktif-yedek DC desenleri
• 🛡️ F5 WAF Deep Dive: ASM ve Advanced WAF ile Uygulama Güvenliği — Güvenlik politikası modelleri, OWASP Top 10 kapsamı, bot savunması, L7 DoS koruması ve şeffaftan engellemeye deployment stratejisi

İlgili Yazılar

• 🛡️ Network Packet Broker (NPB) Masterclass — Tam yığın genelinde trafik görünürlüğü
• 🔐 Zero Trust Zihniyeti: Güvenliği Bir Mimari Olarak Mühendislemek — APM ve WAF’ın Zero Trust’ta yeri
• 🏗️ IT Altyapısı Ürünler Koleksiyonu Değildir — ADC yerleşiminin arkasındaki sistem düşüncesi
• 🎯 Ağ Altyapısı Ürün Seçimi: Stratejik Kriterler — ADC satıcılarını nesnel olarak nasıl değerlendirirsiniz

802.1X projeleri dışarıdan bakınca network işi gibi görünür; çünkü dokunulan yer switch portlarıdır, SSID’lerdir, RADIUS’tur. Ama gerçek hayatta 802.1X’in başarısı çoğu zaman network cihazlarının üzerinde değil; Active Directory düzeninde, sertifika altyapısında (PKI) ve uç cihaz yönetiminde belirlenir. Bunun nedeni basit: 802.1X, portun VLAN’ını değil, kurumun “kimlik modelini” konuşmaya zorlar. Yani “hangi port hangi VLAN"dan, “hangi kimlik hangi yetkiyle ağa girer” düzenine geçersin.

Bu geçiş, bir kurumun alışkanlıklarını değiştirir. Çünkü 802.1X devreye girdiğinde network, artık “kablo takınca çalışan” bir şey olmaktan çıkar; doğrulama geçemeyen cihaz için karantina, misafir için portal, yanlış OU’da duran bilgisayar için yanlış VLAN gibi sonuçlar üretir. Bu yüzden ben 802.1X’i bir özellik olarak değil, kurumsal bir yetkinlik olarak görüyorum: kimlik, envanter, politika ve operasyonun aynı masaya oturduğu bir yetkinlik.

Özet (sadece kilit):

• 802.1X port güvenliği değil, kimlik mimarisidir.
• Başarı network’ten çok AD/PKI/endpoint disiplinine bağlıdır.

Kimlik tabanlı erişimin arkasındaki Zero Trust zihniyeti için: Zero Trust Zihniyeti: Güvenliği Ürün Değil Mimari Olarak Tasarlamak

1) Planlama: VLAN planı yoksa 802.1X “kural motoru” değil “kaos motoru” olur

802.1X’e geçerken herkesin ilk refleksi şudur: “RADIUS kurarız, switch’e yazarız, biter.” Sahada bunun bittiği yer genelde ilk pilot kullanıcıdır. Çünkü pilot kullanıcı bağlanır ve bir anda şu soru çıkar: “Bu kullanıcı hangi VLAN’a gidecek?” İşte 802.1X’in seni zorladığı yer burasıdır.

Eğer kurumda anlamlı bir VLAN/segmentasyon planı yoksa, 802.1X devreye alındığında bütün eksikler görünür hale gelir. Muhasebe ile üretim aynı segmentteyse, kamera ile kullanıcı laptop’u aynı ağdaysa, printer VLAN’ı diye bir kavram hiç yoksa; 802.1X bu yapıyı “otomatikleştiremez”, sadece “otomatik şekilde yanlış” yapar.

Bu yüzden proje başlamadan önce kullanıcı ve cihazları “sınıflara” ayırmak gerekir: departmanlar (muhasebe, finans, HR…), cihaz tipleri (printer, IP phone, camera, badge reader…), sunucu segmentleri (AD/DC, file, mail, web/DMZ), misafir segmenti, karantina segmenti. Bu segmentler yalnızca IP planı değildir; aynı zamanda erişim politikasının zeminidir. Bunlar 802.1X’ten sonra “sonradan düşünülürse”, proje bitmez.

Özet:

• VLAN planı = politika planı.
• 802.1X, segmentasyon kararını “ertelenemez” hale getirir.

2) Network hazırlığı: 802.1X devreye girmeden önce her VLAN manuel çalışmalı

802.1X’e geçmeden önce VLAN’ların switch ve firewall üzerinde tanımlı olması yetmez; manuel test edilmesi gerekir. Çünkü 802.1X devreye girdiğinde sorun çıktığında kök nedeni ayırmak zorlaşır: VLAN mı yanlış, firewall kuralı mı eksik, RADIUS mu yanlış, sertifika mı bozuk?

Benim sahada en çok önerdiğim akış şu: VLAN’ları oluştur, routing ve firewall kurallarını oturt, sonra bir test portunu statik VLAN’a al ve bir kullanıcıyla “olması gereken erişim” testlerini yap. Bu manuel test geçmeden 802.1X’e geçmek, gözü kapalı araç kullanmak gibi.

Bu aşamada ayrıca management network konusu kritik. Switch’lerin, WLC’nin, AP’lerin yönetim IP’leri ayrı bir management VLAN’da olmalı. “Management VLAN” yoksa, 802.1X pilotu sırasında bile cihaz yönetim erişimini kaybedip çok gereksiz kriz yaşanıyor.

Özet:

• 802.1X’ten önce VLAN + FW kuralları manuel test edilmeden ilerlenmez.
• Management network ayrı değilse, proje gereksiz risk taşır.

3) AD tarafı: OU düzeni olmayan yerde 802.1X hep “istisna yönetimi"ne döner

802.1X projelerinde en kritik noktalardan biri, kullanıcıyı ve bilgisayarı sınıflandırma işinin “nerede” yapıldığıdır. Çoğu kurumda kullanıcılar Users altında, bilgisayarlar Computers altında durur; departman ayrımı ya hiç yoktur ya da “görsel düzen” seviyesindedir. 802.1X devreye girdiğinde bu yapı yetmez.

Benim sahada “best practice” diye gördüğüm yapı şudur: her departman için bir OU yapısı oluşturmak ve kullanıcıyı da bilgisayarı da o OU’nun altında tutmak. Kullanıcı OU=Finance altında ama bilgisayar dağınıksa, GPO dağıtımı bozulur, sertifika auto-enrollment bozulur, 802.1X policy eşleştirme bozulur.

Benim önerdiğim yöntem: önce tek bir departmandan tek bir pilot kullanıcı ve pilot cihaz seç. OU taşımayı yap. 1 hafta–10 gün gözlemle. Sorun çıkarsa OU/GPO düzeltmelerini yaparsın, sonra genişlersin.

Özet:

• OU düzeni, 802.1X’in görünmeyen omurgasıdır.
• OU taşıma kontrollü yapılmazsa GPO/erişim yan etkileri doğar.

4) Group Policy: 802.1X projelerinde “tek tek elle ayar” ölçeklenmez

802.1X’i pilotta elle kurarsın; üretime geçince GPO’suz yürüyemezsin. Wired AutoConfig, WLAN AutoConfig, EAP ayarları, sertifika seçimi, authentication öncelikleri… Bunları tek tek elle yönetmek hem hataya açık hem sürdürülemez.

GPO tarafında genelde üç şey yapılır: kablolu 802.1X profillerinin dağıtımı, kablosuz 802.1X profilleri ve sertifika auto-enrollment. Ayrıca “kullanıcı bazlı 802.1X” ile “bilgisayar bazlı 802.1X” aynı anda devredeyken Windows’un hangi sırayla deneyeceği önemlidir. Çoğu tasarımda “önce bilgisayar auth, sonra kullanıcı auth” modeli istenir.

Özet:

• GPO olmadan 802.1X üretime taşınmaz.
• Auth sırası (machine vs user) sahada fark yaratır.

5) RADIUS / NPS / NAC: “Konuşuyor” yetmez; hangi cevabı verdiği önemlidir

RADIUS tarafı çoğu ekipte “Switch’i tanıttık, secret verdik, oldu” gibi görülür. Bu sadece iletişimin başladığı yerdir. Asıl konu: RADIUS, switch’e hangi VLAN / hangi ACL / hangi policy cevabını veriyor?

• Basit dünyada RADIUS sadece “accept/reject” döner, VLAN statik kalır.
• Olgun dünyada RADIUS “accept” ile birlikte dinamik VLAN atar, dACL/ACL iter.

Sahada sık yapılan hata: network cihazlarını RADIUS client olarak tanımlarken management IP yerine farklı IP’ler kullanmak, yanlış VRF/route yüzünden RADIUS’a erişememek, source-interface yanlışlığı… Ben her projede önce en basit testle başlarım: switch’ten RADIUS’a reachability, RADIUS’ta log, sonra bir test port.

Özet:

• RADIUS “iletişim kurdu” diye proje bitmez; “hangi policy cevabı dönüyor” önemlidir.
• Reachability/source-interface/VRF hataları en klasik kök nedendir.

6) EAP yöntemleri: PEAP mi, EAP-TLS mi, Computer mı User mı?

PEAP (kullanıcı adı/şifre) neden pratik ama riskli: PEAP kolaydır ama kullanıcı kişisel laptop’undan veya telefonundan da aynı kullanıcı adı/şifreyle ağa girebilir. Zero Trust mantığında hedef, sadece kullanıcıyı değil cihazı da doğrulamaktır.

Computer authentication neden iyi ama bazı organizasyonlarda can yakar: Bilgisayar doğrulaması kişisel cihazları engeller. Ancak ortak bilgisayar kullanılan yerlerde kullanıcı bazlı segmentasyon istiyorsan tek başına yeterli olmaz.

EAP-TLS (sertifika) neden “en doğru” ama neden disiplin ister: EAP-TLS’de şifre sızsa bile sertifika yoksa erişim yoktur. Ancak PKI’nın ayakta durması, template’lerin doğru olması, auto-enrollment’ın doğru işlemesi şarttır.

Özet:

• PEAP pratik ama “kurumsal cihaz” güveni zayıf kalır.
• Computer auth güçlü ama ortak PC senaryolarında sınırlıdır.
• EAP-TLS en güvenlisi; PKI disiplini şarttır.

7) PKI ve Certificate Template’ler: 802.1X’in sessiz kırılma noktası

EAP-TLS tasarlıyorsan, Windows Certificate Services (AD CS) üzerinde en az iki şey düşünmek zorundasın:

1. İstemci sertifikaları: (User certificate, Computer certificate)
2. RADIUS server’ın sunacağı server certificate

İstemci sertifikalarının dağıtımı çoğu yapıda auto-enrollment ile yapılır. Sahada en sık görülen hata: template hazırlanır ama güvenlik izinleri yanlış olduğu için kullanıcı/cihaz sertifika alamaz; ya da alır ama yanlış EKU/KeyUsage yüzünden EAP-TLS’de kullanılamaz.

NPS (veya NAC) istemciye bir server certificate sunar. İstemci bu sertifikaya güvenmezse “man-in-the-middle” gibi algılar ve bağlanmaz. Bu yüzden RADIUS server sertifikasının zinciri (CA) istemciye güvenilir olarak dağıtılmalıdır — bunun pratik yolu Root CA ve intermediate CA’ları GPO ile “Trusted Root Certification Authorities” alanına basmaktır.

Ayrıca NPS, istemcinin sunduğu sertifikayı doğrularken CRL kontrolü yapmak isteyebilir. CRL erişimi bozuksa, doğrulama gecikir veya fail olur. Bu detay sahada “arada bağlanmıyor” gibi sinir bozucu problemlerin klasik sebebidir.

Özet:

• Template izinleri/amaçları yanlışsa TLS biter.
• Auto-enrollment + CA trust dağıtımı GPO ile standardize edilmelidir.
• CRL erişimi bir gün patlayınca herkes “802.1X bozuldu” sanır.

8) Switch portunda Dot1X ve MAB birlikte: sıranın doğru yazılması gerçek hayatı kurtarır

Sahada en yaygın ve en mantıklı model: önce dot1x dene; dot1x fail olursa MAB’a düş. Çünkü laptop gibi akıllı uçlar 802.1X yapabilsin; printer/kamera gibi akıllı olmayanlar MAB ile yürüsün.

MAB’ı yanlış önceliklendirdiğinde, domain’e bağlı laptop bile MAB ile bağlanıp yanlış VLAN’a düşebilir. “Tek tek port bazlı ilerlemek” yaklaşımı kritik: departman departman ilerlemek; her departmanda önce 1–2 pilot kullanıcı, 1 hafta gözlem, sonra genişleme.

Özet:

• Dot1X → fail olursa MAB sırası çoğu ortam için en sağlıklısıdır.
• Port bazlı kontrollü rollout, “bir günde geçiş"ten daha hızlı bitirir.

9) Profiling: “Sadece MAC” dönemi bitti

MAC authentication, tek başına artık yeterli güvenlik değildir. Bu yüzden gelişmiş NAC çözümleri profiling yapar: OUI kontrolü, DHCP fingerprint, CDP/LLDP, cihaz açıklaması birlikte değerlendirilir. Böylece sahte cihazın “ben printerım” diyerek MAB üzerinden VLAN alması zorlaşır.

Özet:

• MAC tek başına kimlik değildir; profiling kimliğe yaklaşır.
• Birden fazla sinyal kullanmak sahadaki suistimali azaltır.

10) Quarantine VLAN ve Guest VLAN: İkisi aynı şey değil

Quarantine: şirketin cihazı/hesabı var ama doğrulamadan geçemiyor. Karantina VLAN’ın amacı cihazı tamamen kesmek değil; problemi çözebileceği minimum erişimi vermektir — AD’ye/CA’ya erişsin, şifre değiştirsin.

Guest: şirketin cihazı değil. Burada genelde sadece internete izin verirsin; AD/kerberos/LDAP gibi iç kaynaklara erişim hiç gereksizdir.

Özet:

• Quarantine “bizim ama sorunlu”; Guest “bizden değil”.
• İkisini aynı VLAN’a koymak pratikte güvenlik ve operasyonu bozar.

11) Guest portal: Sponsor login, SMS, sosyal login ve MAC randomization gerçeği

Sponsor login yaklaşımı kurumsal yapılarda çok işe yarar: misafir “kimi ziyaret ediyorum” der; sistem AD’den o kişiyi bulur; onay maili/push gider; onaylanınca misafir internete çıkar.

Modern telefonlar Wi-Fi’de MAC randomization yaptığında, kullanıcı Wi-Fi’yi kapatıp açınca cihaz “yeni cihaz” gibi görünebilir ve tekrar doğrulama ister. Bu kullanıcı deneyimini bozar — helpdesk’e “internet gitti” çağrısı yağar.

Özet:

• Portal modeli güvenlik kadar UX tasarımıdır.
• MAC randomization misafir akışını bozabilir; buna göre tasarlanmalıdır.

12) Posture: 802.1X’in “son kalesi” ama yanlış kurarsan operasyonu yorar

Posture, kullanıcı/cihaz kimliği doğru olsa bile, cihazın güvenlik durumu uygun değilse erişimi sınırlamaktır. Posture kontrolünde tipik olarak şunlar sorgulanır: OS versiyonu, patch seviyesi, disk encryption durumu, AV var mı ve güncel mi, EDR agent çalışıyor mu.

Posture’un bir bedeli var: çoğu zaman endpoint üzerinde agent gerekir. Bu yüzden mümkünse “yeni agent” eklemek yerine, zaten kurulu olan ajanları reuse etmek akıllıcadır. Cisco ortamında AnyConnect, Fortinet tarafında FortiClient, bazı yapılarda Trellix gibi EDR/AV ajanları kullanılabilir.

Posture tasarımında en çok önerdiğim pratik yaklaşım: posture’u ilk aşamada “deny” mekanizması olarak değil, “gözlem ve raporlama” mekanizması olarak başlat. Posture, bir günde değil, bir süreçte olgunlaşır.

Özet:

• Posture “kimlik + sağlık” kontrolüdür; drift’i yakalar.
• Yeni agent maliyetlidir; mevcut agent’ları reuse etmek akıllıcadır.
• İlk gün deny değil; önce ölç, sonra sıkılaştır.

13) Temel 802.1X → Profiling/Portal → Posture: Olgunluk seviyeleri

• Seviye 1: Dot1X + MAB — Windows NPS ile olur. Düşük maliyet, sınırlı yetenek.
• Seviye 2: Profiling + Guest Portal — Cisco ISE, Aruba ClearPass devreye girer. İş “cihazı tanıma ve misafiri yönetme"ye döner.
• Seviye 3: Posture — En çok güvenlik getirisi, en yüksek operasyonel maliyet. Organizasyonun endpoint yönetim kabiliyeti, agent stratejisi ve helpdesk kapasitesi gerçekçi değerlendirilmelidir.

Kapanış: 802.1X “kurulum” değil, kurum içi sözleşmedir

802.1X projeleri teknik olarak switch’te birkaç komut, RADIUS’ta birkaç policy gibi görünebilir. Ama gerçekte 802.1X, kurum içinde şu sözleşmeyi zorunlu kılar: “Kimlik nasıl taşınır, cihaz nasıl tanınır, misafir nasıl yönetilir, sorunlu cihaz nereye düşer, güvenlik hangi noktada başlar?”

802.1X’in başarısı cihazların gücünden çok, AD düzeninin, GPO disiplininin, PKI yönetiminin ve kademeli rollout kültürünün toplamıdır. 802.1X’i böyle ele aldığında, sadece güvenliği artırmazsın; operasyonu da merkezileştirirsin.

İlgili Yazılar

Mimari & Güvenlik

• 🔐 Zero Trust Zihniyeti: Güvenliği Ürün Değil Mimari Olarak Tasarlamak — Kimlik tabanlı erişimin mimari temeli
• 🏗️ IT Altyapısı Bir Ürün Koleksiyonu Değildir — Sistem düşüncesi ve ürün seçimi
• 📊 Monitoring Zihniyeti: Sadece Görmek Değil, Anlamak — Policy ihlallerini tırmanmadan yakalamak

Pratik Mühendislik

• 🛡️ Network Packet Broker (NPB) Masterclass — Trafik görünürlüğü ve güvenlik stratejisi
• 🎯 Ağ Altyapısında Ürün Seçimi: Stratejik Kriterler — NAC vendor değerlendirmesi