Wireshark ile Ağ Paket Analizi: SPAN, TAP ve Filtrelerle Teşhis

“Uygulama yavaş” şikâyeti geldiğinde izleme grafikleri genellikle temiz görünür ve tartışma başlar: ağ mı, sunucu mu, DNS mi? Bu tartışmayı bitiren tek şey paket düzeyindeki kanıttır. Wireshark ile analizin iki yarısı vardır ve ikisi de aynı derecede önemlidir: doğru noktadan doğru yöntemle yakalamak, sonra izi okuyup TCP, DNS ve DHCP sorunlarını yerine oturtmak. Aşağıda ikisini de konsolda uyguladığımız sırayla anlatıyoruz.

Ne zaman paket yakalamak gerekir?

Paket yakalama pahalı bir araçtır: depolama, analiz zamanı ve gizlilik yükü getirir. İlk adım değildir. Arayüz sayaçları, akış verisi ve loglar sorunu daraltamadığında devreye girer. Tipik durumlar:

• Bant genişliği grafikleri normalken belirli bir uygulamanın yavaş olması
• Aralıklı bağlantı kopmaları, oturum sıfırlanmaları (RST) veya zaman aşımları
• İstemcinin IP almaması ya da geç alması, isim çözümlemenin uzun sürmesi
• Üretici destek ekibinin veya uygulama sahibinin “ağ paket düşürüyor” iddiasını doğrulamak ya da çürütmek

Katman katman genel sorun giderme sırası için ağ yavaşlığında sorun giderme kontrol listesi başlangıç noktasıdır. Trafiğin kimden kime aktığını görmek içinse paket yerine NetFlow, sFlow ve IPFIX gibi akış verisi çoğu zaman yeter. Paket yakalama, bu ikisinin “neden” sorusunu cevaplayamadığı yerde başlar.

Yakalama noktası seçimi: SPAN, RSPAN, TAP ve uç nokta

Aynı oturumun iki farklı noktadan alınmış izleri farklı hikâye anlatır. Bir TCP yeniden iletimi istemci tarafında görünüp sunucu tarafında görünmüyorsa kayıp aradaki yoldadır. Yakalama noktasını test etmek istediğiniz hipotez belirler. Rastgele port aynalamak zaman kaybıdır.

SPAN’de sahada en sık karşılaştığımız tuzak aşırı aboneliktir. 1 Gbps bir kaynak port her iki yönde (rx+tx) aynalandığında toplam 2 Gbps’e kadar trafik 1 Gbps hedef porta sığmayabilir; fazlası düşer. İzde görünen “kayıp” bu durumda gerçek değildir. Uç noktada yakalarken de TSO/GSO gibi segment offload özellikleri yüzünden MTU’dan büyük çerçeveler, checksum offload yüzünden “incorrect checksum” uyarıları görülür. Bunlar ağ sorunu değildir; yakalamanın sürücüden önce yapılmasının sonucudur. Yeni başlayanların ilk yanlış alarmı genellikle budur.

Cisco SPAN oturumu yapılandırma örneği

Aşağıdaki örnek, Cisco Catalyst üzerinde bir sunucu portunun her iki yöndeki trafiğini analiz bilgisayarının bağlı olduğu porta kopyalar:

monitor session 1 source interface GigabitEthernet1/0/10 both
monitor session 1 destination interface GigabitEthernet1/0/48
!
show monitor session 1

Hedef port oturum boyunca normal anahtarlama işlevini kaybeder. Yanlışlıkla uplink’i hedef seçerseniz bağlantıyı kendiniz kesersiniz; komutu girmeden önce port numarasını iki kez okuyun. Uzak bir switch’teki trafiği merkezdeki analiz noktasına taşımak için RSPAN kullanılır:

! Her iki switch’te ve aradaki trunk’larda
vlan 999
 remote-span
!
! Kaynak switch
monitor session 2 source interface GigabitEthernet1/0/5 both
monitor session 2 destination remote vlan 999
!
! Analiz noktasının bağlı olduğu switch
monitor session 2 source remote vlan 999
monitor session 2 destination interface GigabitEthernet1/0/48

Capture filtre ve display filtre örnekleri

Wireshark’ta iki ayrı filtre dili vardır ve karıştırılması en sık yapılan hatadır. Capture filtresi BPF (libpcap) sözdizimini kullanır ve yakalama sırasında uygulanır; dışarıda bırakılan paket hiç kaydedilmez. Display filtresi Wireshark’ın kendi sözdizimidir ve kaydedilmiş iz üzerinde görünümü daraltır. Uzun süreli veya yoğun hatlarda capture filtresi disk ve CPU’yu korur. Kısa ve hedefi belirsiz yakalamalarda geniş yakalayıp display filtresiyle daraltın.

Eski Wireshark sürümlerinde DHCP display filtresi bootp idi; 3.0 ve sonrasında dhcp kullanılır. Alan adlarının tam listesi için Wireshark dokümantasyonu ve display filter referansı birincil kaynaktır.

TCP sorunlarını okumak: retransmission, zero window, RTT

Wireshark, TCP sıra ve onay numaralarını takip ederek anormallikleri tcp.analysis alanlarıyla işaretler. En hızlı başlangıç tcp.analysis.flags filtresidir; ardından işaretler tek tek okunur:

• tcp.analysis.retransmission ve tcp.analysis.fast_retransmission: Segment karşıya ulaşmadı veya onayı geri gelmedi. Yeniden iletimin hangi yönde ve hangi yakalama noktasında görüldüğü, kaybın yerini daraltır.
• tcp.analysis.duplicate_ack: Alıcı sıra dışı segment aldı ve eksik segmenti istiyor; çoğunlukla kaybın ilk işaretidir.
• tcp.analysis.zero_window: Alıcının alım tamponu doldu ve göndericiye “dur” diyor. Bu genellikle ağı değil, alıcı uygulamanın veya sunucunun veriyi yeterince hızlı okuyamadığını gösterir.
• tcp.analysis.window_full: Gönderici, alıcının ilan ettiği pencerenin tamamını kullandı; yüksek gecikmeli hatlarda küçük pencere boyutu throughput’u sınırlar.

Gecikmenin kaynağını ayırmak için iki ölçüm birlikte okunur. Ağ RTT’si üçlü el sıkışmadan çıkar: Wireshark, SYN ile el sıkışmayı tamamlayan ACK arasındaki süreyi tcp.analysis.initial_rtt (iRTT) alanında verir. İstemci tarafında alınan izde SYN ile SYN/ACK arasındaki süre, istemciden sunucuya giden yolun gecikmesidir. Uygulama yanıt süresi ise istemcinin isteği ile sunucunun ilk veri yanıtı arasındaki süredir. El sıkışma birkaç milisaniyede tamamlanıyor ama sunucu her isteğe saniyeler sonra yanıt veriyorsa sorun ağ altyapısında değil, sunucu veya uygulamadadır. Bu ayrım “sorun sizde” tartışmasını kanıtla kapatır. Ekran görüntüsü yeter.

Tipik bir saha senaryosu: dosya kopyalaması yavaş, sunucu tarafında alınan izde sık tcp.analysis.zero_window var, yeniden iletim yok. Sunucu diske yazma veya işleme hızına takılmıştır. Hattı büyütmek sonucu değiştirmez.

DNS ve DHCP akışlarının analizi

DNS gecikmesi kullanıcıya “uygulama açılırken bekliyor” olarak yansır ve çoğu zaman ağa fatura edilir. Wireshark her DNS yanıtına sorguyla arasındaki süreyi dns.time alanında ekler. İşe yarayan filtreler:

dns.time > 0.5                      # yarım saniyeden uzun süren yanıtlar
dns.flags.rcode != 0               # NXDOMAIN, SERVFAIL gibi hatalı yanıtlar
dns.flags.response == 0 && !dns.response_in   # yanıtı hiç gelmeyen sorgular

Yanıtı gelmeyen sorgu, istemcinin ikinci DNS sunucusuna düşmesine ve zaman aşımı kadar beklemesine yol açar. Kurumsal çözümleyici tasarımı ve iç/dış ad alanı ayrımı için kurumsal DNS mimarisi yazısına bakabilirsiniz.

DHCP’de normal akış Discover, Offer, Request, ACK sırasıdır (DORA). Mesaj tipi dhcp.option.dhcp alanındadır: 1 Discover, 2 Offer, 3 Request, 5 ACK, 6 NAK. İzde yalnızca Discover var ve Offer gelmiyorsa bakılacak yerler relay yapılandırması, DHCP snooping güven ayarı ve sunucuya erişimdir. Sahada bu tablonun en sık nedeni, yeni eklenen bir uplink’in snooping’de trusted işaretlenmemesidir. Offer görünüyor ama istemci Request göndermiyorsa istemci tarafına geçilir. Relay ve snooping yapılandırma hataları DHCP relay ve DHCP snooping yazısında ayrıntılı anlatılıyor. Relay arkasındaki istemcilerde, sunucu tarafındaki izde paketler istemciden değil relay ajanının IP adresinden unicast olarak gelir ve giaddr alanı doludur; istemciyi izde bulmak için MAC adresini chaddr alanında arayın.

tshark ile uzun süreli halka tampon yakalama

Aralıklı sorunlar, birisi Wireshark’ı açtığında ortaya çıkmaz. Böyle durumlarda sorunu “bekleyen” bir yakalama kurulur: tshark (veya doğrudan dumpcap) belirli boyutta dosyalar yazar, en eski dosyayı silerek sabit disk alanında döner. Sorun yaşandığında ilgili zaman aralığındaki dosyalar korunur.

# 100 MB'lık 50 dosya: en fazla yaklaşık 5 GB disk
tshark -i eth1 -f "host 10.10.20.15" \
  -b filesize:102400 -b files:50 \
  -w /data/capture/srv15.pcapng

# Yalnız başlıklar yeterliyse paket başına 128 bayt saklamak
dumpcap -i eth1 -s 128 -b filesize:102400 -b files:50 -w /data/capture/hdr.pcapng

# Kaydedilmiş iz üzerinde komut satırından analiz
tshark -r srv15_00012_<zaman>.pcapng -Y "tcp.analysis.retransmission" \
  -T fields -e frame.time -e ip.src -e ip.dst -e tcp.stream
tshark -r srv15_00012_<zaman>.pcapng -q -z conv,tcp
tshark -r srv15_00012_<zaman>.pcapng -q -z io,stat,60

filesize değeri kilobayt cinsindendir; tshark halka tampondaki her dosyanın adına sıra numarası ve zaman damgası ekler. Analiz makinesinin saati NTP ile senkron olmalı. Kullanıcının bildirdiği sorun saati ile iz zaman damgası tutmazsa doğru dosyayı bulmak saatler alır.

Gizlilik ve saklama dikkatleri

Şifrelenmemiş protokollerde paket izi kullanıcı adları, e-posta içerikleri ve kişisel veriler barındırabilir. Yakalama bir yetkilendirmeyle başlar ve sınırlarla yürür:

• Yakalama amacı, kapsamı (host/port) ve süresi değişiklik veya olay kaydına yazılır.
• Mümkünse capture filtresiyle kapsam daraltılır, snaplen ile yük kısmı kesilir.
• İz dosyaları erişimi kısıtlı bir dizinde tutulur, analiz bitince silinir; dışarıya (üretici desteği vb.) gönderilecekse önce anonimleştirme veya kırpma yapılır.
• Kişisel veri işleme açısından kurum politikası ve KVKK yükümlülükleri dikkate alınır.

Karmaşık performans sorunlarında yakalama noktasının seçimi, iz analizi ve bulguların raporlanması için network performans analizi ve sorun giderme hizmetimizden destek alabilirsiniz.

Sık sorulan sorular

SPAN ile yakalanan izde görülen paket kaybı gerçek midir?

Her zaman değil. Kaynak portların toplam trafiği hedef portun kapasitesini aşarsa switch aynalanan kopyaları düşürür ve izde sahte kayıp görünür. Gerçek kaybı doğrulamak için aynı oturumu uç noktada veya TAP ile ikinci bir noktadan yakalayıp karşılaştırın.

Capture filtresi mi display filtresi mi kullanmalıyım?

Yoğun hatlarda ve uzun süreli yakalamalarda capture filtresi disk ve CPU yükünü azaltır, ama dışarıda bırakılan paket geri gelmez. Hedef belirsizse geniş yakalayıp display filtresiyle daraltmak daha güvenlidir.

Zero window görmek ağ sorunu olduğunu gösterir mi?

Genellikle hayır. Zero window, alıcının tamponunun dolduğunu ve uygulamanın veriyi yeterince hızlı okuyamadığını gösterir. Sorun çoğunlukla alıcı sunucu, disk veya uygulama tarafındadır.

Şifreli trafikte Wireshark işe yarar mı?

Evet. TLS ile şifrelenmiş trafikte uygulama içeriği görünmez, ama TCP el sıkışması, yeniden iletimler, pencere boyutları, gecikmeler ve TLS el sıkışması görünür. Ağ kaynaklı sorunların teşhisi için bu bilgiler çoğu zaman yeterlidir.