Ağ Danışmanlığında Teknik Sınırları 3 Adımda Çizme

Ağ topolojisini tasarlayıp teslim ettikten sonra telefonun çalıp “Mustafa Bey, internet bitti” denmesi kadar sinir bozucu çok az şey vardır. Saha tecrübemin bana öğrettiği en büyük ders şu oldu: Sınırlarını teknik kurallarla ve net protokollerle çizmediğin her ağ, günün sonunda seni boğar. Eğer projenin başında nerede duracağını belirlemezsen, gecenin bir yarısı hiç alakan olmayan bir sanallaştırma sunucusunun vSwitch ayarını yaparken bulursun kendini.

Bu yazıda, altyapı projelerinde “benim sorumluluğum nerede biter, müşterinin sistem yöneticisinin veya yazılımcısının sorumluluğu nerede başlar” çizgisini nasıl çektiğimi üç temel adımda ve somut teknik senaryolarla anlatıyorum. Amacım hem kendi akıl sağlığımı korumak hem de teslim ettiğim işin sürdürülebilir olmasını sağlamak.

Sorumluluk Matrisini L2/L3 Seviyesinde Tanımlamak

Ağ projelerinde en sık yaşanan kavga, fiziksel switch’ler ile sanal katman (hypervisor) arasındaki geçiş bölgesinde yaşanır. Ben omurga switch üzerinde VLAN 10, 20 ve 30’u tanımlayıp 802.1Q trunk portunu hazırladıktan sonra işimi tamamlamış sayarım. Ancak karşı taraftaki sistem yöneticisi sanallaştırma sunucusu üzerinde port gruplarını yanlış yapılandırdığında fatura hemen “ağ çalışmıyor” diye bana kesilir.

Bu karmaşayı önlemek için sorumluluk sınırını fiziksel switch portunun çıkışında bitiriyorum. Eğer paket benim switch’imden etiketli (tagged) olarak çıkıyor ve karşı tarafa ulaşıyorsa, benim görevim resmi olarak tamamlanmıştır. Sanal makinenin içindeki işletim sisteminin IP alamaması veya VLAN etiketini çözememesi tamamen sistem ekibinin sorumluluğundadır.

Aşağıdaki gibi bir Cisco IOS yapılandırmasını teslim ettiğim an, hattın karşı ucundaki sunucunun vSwitch ayarları müşterinin sorumluluğuna geçer:

interface GigabitEthernet1/0/24
 description TO_ESXI_HOST_01
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30
 spanning-tree portfast trunk
!

Eğer bu porttan gelen paketlerin doğru VLAN etiketine sahip olduğunu show interfaces trunk komutuyla doğruladıysam, benim için o hat temizdir. Bu sınırı net çizmediğinizde, sunucu ekibinin yaptığı yanlış bir sanal switch konfigürasyonunun faturası kolayca ağ ekibine kesilir ve sorumluluk dağılır. O yüzden bu kuralı asla esnetmem.

”IP Dağıttı, Gerisi Bende Değil”: DHCP ve DNS Sınırları

Ağ yöneticisinin en büyük kabusu, istemci cihazların IP alamaması veya yanlış DNS çözümlemesi yapmasıdır. RFC 2131 (DHCP) ve RFC 1035 (DNS) standartlarına göre çalışan bu servislerde sınırımı her zaman gateway cihazında çizerim. DHCP sunucusunun havuzunun (scope) dolması veya DNS sunucusunun negative caching (olumsuz önbellekleme) yapması ağın değil, sistem servislerinin problemidir.

Bir projede kullanıcılar “bazı siteler açılmıyor” diye şikayet ediyordu. Yaptığım analizde, yerel DNS sunucusunun çözemediği adresler için NXDOMAIN yanıtı döndüğünü ve istemcilerin bu yanıtı uzun süre önbelleğe aldığını gördüm. Ağda paket kaybı yoktu, routing tabloları temizdi; sorun tamamen yerel DNS sunucusunun forwarder ayarlarındaydı.

Bu gibi durumlarda sorumluluğumu kanıtlamak için istemci tarafında doğrudan aşağıdaki dig sorgusunu çalıştırır ve sorunun ağdan bağımsız olduğunu gösteririm:

dig @192.168.10.1 mustafaerbay.xs --trace

Eğer sorgu benim gateway cihazımdan dışarıya kayıpsız çıkıyor ama içerideki Active Directory DNS sunucusunda takılıyorsa, sistem yöneticisine “DNS kayıtlarını düzeltin” der ve aradan çekilirim. Kendi geliştirdiğim yan ürünlerin altyapısında da her zaman harici ve yedekli DNS sorgulama mekanizmaları kurarak bu tür sinsi hataların önüne geçiyorum.

Firewall ve Erişim Politikalarında “Kural Defteri” Metodu

Yazılımcılar genellikle bir servis çalışmadığında ilk olarak firewall kurallarını suçlarlar. “Mustafa Abi, port kapalı herhalde” cümlesini her duyduğumda sakin kalıp telnet veya nc (netcat) test sonuçlarını isterim. Çoğu zaman sorun firewall’un portu engellemesi değil, uygulamanın ilgili portu 0.0.0.0 yerine 127.0.0.1 adresine bağlamış (bind) olmasıdır.

Firewall yönetiminde sınır çizmek için “Kural Defteri” metodunu uyguluyorum. Herhangi bir erişim izni verilmeden önce, talep eden ekipten kaynak IP, hedef IP, protokol ve port bilgilerini içeren yazılı bir onay alırım. Bu onay olmadan hiçbir kuralı aktif etmem ve geçici kurallara asla izin vermem.

Bir sunucuda servisin portu gerçekten dinleyip dinlemediğini doğrulamak için sistem ekibine şu komutun çıktısını sorarım:

ss -tulpn | grep 8080

Eğer çıktı aşağıdaki gibi sadece localhost’u gösteriyorsa, firewall üzerinde kural açmanın hiçbir anlamı yoktur çünkü uygulama dış dünyaya kapalıdır:

tcp   LISTEN 0      128      127.0.0.1:8080      0.0.0.0:*    users:(("node",pid=1234,fd=18))

PostgreSQL veritabanı bağlantı havuzu (connection pool) şişmesi yüzünden ağın çöktüğü iddiaları da bu kategoriye girer. Veritabanı sunucusunun soket limitine ulaştığını ve yeni bağlantı kabul etmediğini bu yöntemle kanıtladığınızda, sorunun ağda değil yazılım mimarisinde olduğu net biçimde ortaya çıkar.

VPN ve ZTNA Entegrasyonlarında İstemci Sınırı

Uzaktan çalışma modellerinin artmasıyla birlikte VPN ve Zero Trust Network Access (ZTNA) projeleri hayatımızın merkezine oturdu. Ancak burada da ciddi bir sınır problemi var. Şirket ağını güvenli hale getirmek benim işimken, evdeki kullanıcının 10 yıllık eski ADSL modeminin Wi-Fi kanal çakışmasını çözmek benim işim değil.

VPN tünellerinde sınırımı istemci yazılımının başarılı bir şekilde “Connected” durumuna geçmesi ve şirket içi DNS sunucusuna ping atabilmesiyle çizerim. Eğer kullanıcının evindeki internet servis sağlayıcısı (ISP) CGNAT arkasındaysa veya MTU (Maximum Transmission Unit) boyutu uyuşmazlığı varsa, bu durum ağ danışmanının sorumluluğunda olamaz.

Özellikle MTU/MSS uyuşmazlıkları yüzünden web sayfalarının yarım yüklenmesi gibi sinsi sorunları çözmek için firewall tarafında TCP MSS Clamping uygular ve sorumluluğu ağ katmanında sabitlerim:

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Kendi yan ürünümün VPS altyapısını taşırken de benzer bir MTU uyuşmazlığı yaşamıştım. Tünel üzerinden geçen paketlerin boyutunu optimize etmediğinizde, paketler yolda parçalanır (fragmentation) ve bu da paket kaybı gibi görünür. Bu ayrımı iyi yapmak ve istemciye “sorun senin bilgisayarında veya modeminde” diyebilmek gerekir.

Bant Genişliği ve QoS Çatışmaları: Trafik Kimin Sorumluluğunda?

“İnternet yavaş” şikayeti, teknik derinliği olmayan ama herkesin uzman olduğu bir konudur. Ağ danışmanı olarak, hattın kapasitesini ve bu kapasitenin nasıl bölüştürüleceğini (QoS - Quality of Service) belirlerim. Ancak bir kullanıcının arka planda 4K video izleyerek tüm bant genişliğini sömürmesi, ağın tasarımıyla ilgili değil, şirketin idari politikalarıyla ilgilidir.

Bu tür durumlarda sınırımı bant genişliği sınırlama (traffic shaping) kurallarıyla çizerim. Kritik iş uygulamalarına (örneğin ERP veya VoIP ses paketleri) her zaman öncelik tanırım. Geriye kalan genel internet trafiğini ise sert limitlerle sınırlandırırım.

Linux tabanlı bir gateway üzerinde tc (traffic control) kullanarak bant genişliğini nasıl kontrol altına aldığımı gösteren basit bir kural seti:

# Sınıf tabanlı kuyruk oluşturma (HTB)
tc qdisc add dev eth0 root handle 1: htb default 30

# Kritik trafik için 10mbps garanti bant genişliği
tc class add dev eth0 parent 1: classid 1:10 htb rate 10mbit ceil 20mbit

# Genel internet trafiği için 2mbps limit
tc class add dev eth0 parent 1: classid 1:30 htb rate 2mbit ceil 5mbit

Bu kuralları devreye aldıktan sonra, “İnternet yavaş” diyen birine doğrudan QoS metriklerini gösteririm. Eğer kritik sistemlerin paketleri kayıpsız gidiyorsa, benim ağım görevini yapıyor demektir. Geri kalan idari kısımlar insan kaynaklarının veya genel yönetimin konusudur.

”Sistem Çalışıyor” İspatı: Metrikler ve İzleme Altyapısı

Tüm bu sınırları çizmenin ve kendinizi savunmanın tek yolu, elinizde kapı gibi teknik verilerin (metriklerin) olmasıdır. Bir ağ danışmanı olarak, teslim ettiğim her projeye mutlaka bağımsız bir izleme (monitoring) sistemi entegre ederim. ICMP gecikmeleri, paket kayıpları, switch portlarındaki trafik yoğunluğu ve CPU/Memory kullanımları anlık olarak kaydedilmelidir.

Tıpkı Docker container’larının disk doluluk oranını izlemediğimizde tüm sistemin kilitlenmesi gibi, ağ üzerindeki anormallikleri de önceden görmezseniz suçlu her zaman siz olursunuz. Ben genelde Prometheus ve SNMP exporter ikilisini kullanarak kritik cihazları sürekli takip ederim.

Aşağıdaki Prometheus alarm kuralı, bir switch portunda paket kaybı başladığı an beni uyarır ve sorunun kaynağını müşteri daha fark etmeden bulmamı sağlar:

groups:
  - name: network_alerts
    rules:
      - alert: HighPacketLoss
        expr: rate(node_network_receive_drop_total[5m]) > 10
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Ağ arayüzünde yüksek paket kaybı: {{ $labels.device }}"

Bu metrikler sayesinde müşteri “Ağda sorun var” dediğinde, önlerine uzun döneme yayılan çalışma süresi (uptime) ve paket kaybı grafiklerini koyabiliyorum. “Bakın, paket kaybı yok denecek kadar düşük, gecikme de normal sınırlarda. Sorun ağda değil, sizin sunucunuzun disk G/Ç (I/O) darboğazında” diyerek konuyu kapatıyorum.

Sonraki adımda, ağ üzerindeki trafiğin derinlemesine analizini yapmak ve sinsi DDoS saldırılarını önceden tespit etmek için akış tabanlı izleme (NetFlow/sFlow) sistemlerinin nasıl kurulacağını ele alacağız. Ağınızı kurallarla koruyun ki, ağınız da sizi korusun.