Bir üretim tesisinde veya orta ölçekli bir ofiste 400-500 civarı IP alan cihazın olduğu tek bir “flat” network (düz ağ) gördüğümde, orada sadece bir güvenlik açığı değil, aynı zamanda ciddi bir performans sızıntısı olduğunu biliyorum. Herkesin herkesle doğrudan konuşabildiği, yazıcıların sürekli broadcast yayın yaptığı ve bir muhasebe bilgisayarının üretim bandındaki PLC cihazına doğrudan erişebildiği bir ortamda “sistem yönetiyorum” demek biraz iyimserlik olur.
Geçtiğimiz yıllarda bir üretim ERP’si üzerine çalışırken, network tarafındaki bu karmaşanın yazılım tarafında nasıl “anlamsız” timeout hatalarına yol açtığını bizzat deneyimledim. Network segmentasyonu sadece “firewall kuralı yazalım” demek değil; bu işin bir de L2 (Layer 2) bacağı, broadcast domain yönetimi ve donanım limitleri var. Bu yazıda, saha tecrübemle VLAN segmentasyonunu nasıl kurguladığımı ve performans-güvenlik dengesini nerede tuttuğumu teknik detaylarıyla paylaşıyorum.
Flat Network Tuzağı ve Broadcast Trafiğinin Görünmez Maliyeti
Çoğu yerde network kurulumu “tak-çalıştır” mantığıyla başlıyor. Bir adet /23 veya /22 blok (510 veya 1022 host) tanımlanıyor, DHCP sunucuya veriliyor gazı ve her şey çalışıyor gibi görünüyor. Ancak broadcast trafiği dediğimiz şey, ağdaki her bir cihazın kapısını çalan bir “gürültü” gibidir. Bir cihaz ARP (Address Resolution Protocol) isteği attığında, o segmentteki tüm cihazların CPU’su bu paketi işlemek için milisaniyelik de olsa uyanır.
Sahada gördüğüm en büyük hatalardan biri, kalabalık bir flat networkte mDNS, LLMNR ve ARP paketlerinin toplam trafiğin azımsanmayacak bir kısmına ulaşmasıydı. Bu durum, özellikle gecikmeye (latency) duyarlı üretim cihazlarında veya gerçek zamanlı veri akışı sağlayan sensor gateway’lerde jitter (gecikme dalgalanması) yaratıyor. Ben genellikle bir broadcast domain’i maksimum 250 host (bir /24 blok) ile sınırlandırmayı tercih ediyorum. Eğer cihaz sayısı artıyorsa, bu mantıksal bir ayrım değil, teknik bir zorunluluktur.
# Bir Linux makinede saniyedeki broadcast paketlerini izlemek için
tcpdump -n "broadcast or multicast" -i eth0 | pv -l > /dev/nullYukarıdaki basit komutla ağdaki gürültüyü izleyebilirsiniz. Eğer saniyede 100’den fazla satır akıyorsa, o segmentte segmentasyon vaktiniz gelmiş de geçiyor demektir. Segmentasyon yaptığımda, sadece güvenliği sağlamıyorum; aynı zamanda anahtar (switch) işlemcilerinin üzerindeki yükü de optimize ediyorum.
L2 vs L3 Segmentasyon: Performans Nerede Kayboluyor?
Segmentasyon yaparken en kritik karar, trafiğin nerede sonlanacağıdır. Tüm VLAN’ları bir Firewall (L3) üzerinde sonlandırmak güvenliği maksimize eder ama performanstan çalar. Eğer içeride 10Gbps veri transferi yapan bir backup sunucunuz varsa ve tüm bu trafik Firewall üzerinden (Router-on-a-stick) geçiyorsa, Firewall’un CPU’sunu “boğarsınız”.
Kendi projelerimde ve danışmanlık verdiğim yerlerde genellikle “Inter-VLAN Routing” işini L3 yetenekli core switch’lere bırakıyorum. Güvenlik kritik olan yerleri (örneğin muhasebe segmenti ile misafir ağı arası) Firewall üzerinden geçirirken, üretim bandındaki operatör ekranları ile uygulama sunucusu arasındaki trafiği L3 switch üzerinde ACL (Access Control List) ile yönetiyorum.
| Yöntem | Güvenlik Seviyesi | Performans (Throughput) | Karmaşıklık |
|---|---|---|---|
| Router-on-a-stick | Çok Yüksek | Düşük (Interface limitli) | Orta |
| L3 Switch (SVI) | Orta | Çok Yüksek (Wire-speed) | Düşük |
| Firewall (Sub-interfaces) | En Yüksek | Orta (DPI yüklü ise düşük) | Yüksek |
Burada asıl dikkat edilmesi gereken nokta MTU (Maximum Transmission Unit) değerleridir. VLAN’lar arası geçişte eğer bir tarafta Jumbo Frame (9000 byte) açık, diğer tarafta kapalı ise paketler parçalanmaya (fragmentation) başlar ve bu da MSS (Maximum Segment Size) mismatch sorunlarına yol açar. Bir keresinde bir üretim ERP’sinde raporların neden bu kadar yavaş geldiğini araştırırken, sorunun SQL sorgusunda değil, 1500 MTU’luk bir gateway üzerinden 9000 MTU’luk paket geçirmeye çalışan bir switch konfigürasyonu olduğunu bulmuştum.
Switch Hardening: VLAN Sadece Bir Etiket Değildir
VLAN oluşturup bırakmak, kapıyı kilitleyip anahtarı üzerinde bırakmaya benzer. 802.1Q tagging sistemini kurduğunuzda, switch üzerindeki portların güvenliğini de sağlamanız gerekir. “VLAN Hopping” gibi saldırılar hala gerçek ve basit bir konfigürasyon hatasıyla tüm segmentasyonunuzu bypass edebilirler.
Öncelikle, kullanılmayan tüm portları kapatıyorum ve bunları “Blackhole VLAN” dediğim, hiçbir yere çıkışı olmayan (örneğin VLAN 999) bir gruba atıyorum. Ayrıca, native vlan değerini asla 1 olarak bırakmıyorum. Switch yönetim trafiğini (Management VLAN) ise kullanıcı datasıyla asla karıştırmıyorum.
Aşağıda, kurumsal bir switch üzerinde uyguladığım temel hardening adımlarının bir örneğini görebilirsiniz:
! Switch port güvenliği ve DHCP Snooping
interface GigabitEthernet0/1
switchport mode access
switchport access vlan 10
switchport port-security
switchport port-security maximum 2
switchport port-security violation shutdown
ip dhcp snooping limit rate 10
!
ip dhcp snooping vlan 10
ip arp inspection vlan 10Buradaki ip arp inspection ve ip dhcp snooping komutları, networkün can damarıdır. Bunlar olmadan yapılan segmentasyon, sadece kağıt üzerinde bir düzen sağlar. Gerçek dünyada birisi gidip networke yanlışlıkla bir modem takarsa, DHCP snooping sayesinde tüm networkün çökmesini engellemiş olursunuz.
Yönetim VLAN’ı (Management) ve Out-of-Band (OOB) Erişimi
Sistem yöneticisi olarak en büyük korkum, yaptığım bir kural değişikliği sonrası switch’e veya sunucuya erişimimi kaybetmektir. Bu yüzden, yönetim trafiğini her zaman ayrı bir VLAN’da tutarım. Bu VLAN’a sadece belirli IP’lerden (genellikle benim yönetim workstation’ım veya bir jumpbox) erişim izni veririm.
Bir müşteri projesinde, tüm switchlerin yönetim IP’leri ana kullanıcı networkündeydi. Bir broadcast storm yaşandığında switchlere SSH ile bağlanıp sorunu çözmek imkansız hale gelmişti çünkü switch CPU’su o kadar meşguldü ki SSH paketlerine cevap veremiyordu. O günden beri, fiziksel olarak mümkünse ayrı bir kablolama ile “Out-of-Band” yönetim ağı, değilse de en azından en yüksek öncelikli (QoS/DSCP işaretli) bir Management VLAN kuruyorum.
network güvenliği yazımda bahsettiğim gibi, yönetim ağında permit kuralları yazarken “any” ifadesinden kaçınmak hayat kurtarır. Sadece sizin bildiğiniz, statik IP atanmış bir yönetim bloğu, ağdaki bir malware’in switchlerinize brute-force denemesi yapmasını en baştan engeller.
Zero-Trust Yaklaşımı: VLAN’ın Yetmediği Yerler
Geleneksel VLAN segmentasyonu “güvenli bölge” ve “güvensiz bölge” ayrımına dayanır. Ancak modern dünyada, özellikle uzaktan erişimin (VPN/ZTNA) bu kadar arttığı bir dönemde, bir cihazın sadece “üretim VLAN’ında” olması onun güvenilir olduğu anlamına gelmez. İşte bu noktada ZTNA (Zero Trust Network Access) prensiplerini network katmanına indirmek gerekiyor.
Benim uyguladığım yöntem; VLAN’ları sadece birer “trafik düzenleyici” olarak kullanıp, asıl yetkilendirmeyi cihaz tabanlı yapmak. Eğer bir operatör paneli (HMI) ağa dahil olacaksa, switch portu üzerinden MAC tabanlı değil, mümkünse 802.1X sertifika tabanlı bir doğrulama ile içeri alıyorum. Eğer sertifikası yoksa, onu otomatik olarak sınırlı yetkili bir “Quarantine VLAN” içine atıyorum.
Bu yaklaşım, özellikle “birisi gelip kabloyu çıkardı, kendi laptopunu taktı” senaryolarını tamamen bitiriyor. Evet, konfigürasyon yükü biraz artıyor ama tecrübem şunu gösterdi: Başta harcamadığınız o kısa konfigürasyon süresi, bir incident anında katlanarak uykusuzluk ve prestij kaybı olarak geri dönüyor.
İzleme ve Troubleshooting: VLAN Flap ve Loop Sorunları
Segmentasyonu yaptık, kuralları yazdık, her şey harika. Peki, bir sorun olduğunda nerede patladığımızı nasıl anlarız? Network segmentasyonunun en sinsi sorunu “VLAN Flapping” ve Spanning Tree (STP) döngüleridir. Özellikle birden fazla switchin birbirine bağlı olduğu topolojilerde, bir loop oluştuğunda tüm segmentleriniz felç olabilir.
Benim monitoring dashboard’larımda (Prometheus + Grafana ile SNMP üzerinden topladığım veriler) mutlaka “STP Topology Change” alarmı bulunur. Eğer durduk yere bir topoloji değişikliği mesajı alıyorsam, bir yerlerde birisi kablolarla oynuyor veya bir switch arızalanıyor demektir.
# Cisco cihazlarda STP durumunu kontrol etmek için
show spanning-tree summary
show spanning-tree vlan 10Ayrıca, her VLAN’ın gateway IP’sine (SVI) düzenli ICMP request atan ve gecikme süresini ölçen bir scriptim var. Eğer bir VLAN’da gecikme normal seviyesinden belirgin biçimde fırlıyorsa, o segmentte bir cihazın “delirdiğini” (nic babbling) veya bir broadcast loop başladığını anında görebiliyorum. PostgreSQL tuning yazısında anlattığım veri tabanı performans sorunlarının yarısının aslında bu tip network dalgalanmalarından kaynaklandığını görmek şaşırtıcı olabilir.
Sonuç: Doğru Dengeyi Kurmak
VLAN segmentasyonu bir varış noktası değil, sürekli devam eden bir süreçtir. Şirket büyüdükçe, yeni cihazlar eklendikçe bu yapıyı güncellemek gerekir. Benim altın kuralım şudur: Güvenliği L3/Firewall katmanında, performansı L2/Switch katmanında, düzeni ise disiplinli bir dökümantasyonda ara.
Segmentasyonu sadece “IP’leri bölmek” olarak görmeyin. Bu, organizasyonel akışın networke yansımasıdır. Üretim, muhasebe, kamera sistemleri ve IoT cihazları kendi kum havuzlarında oynamalı ama birbirlerine ihtiyaç duyduklarında kontrollü bir kapıdan geçmeliler.
Bir sonraki yazıda, bu network yapısı üzerinde koşan Linux servislerinin güvenliğini nasıl sıkılaştırdığımı (auditd ve cgroup limitleri ile) detaylandıracağım. Networkü böldük, şimdi sıra o networkün içindeki hostları korumakta.