Bölüm 69: Trafik Çözümleme
Ağlar'a “Sen”i Katmak kitabının bir bölümü: adres çubuğuna yazdığın tek bir isteğin peşinden bakırla fiberin fiziğine inip karşı taraftan geri dönen uzun bir teknik yolculuk.
Kısım 9: Karşı Tarafta ve Dönüşte (Bölüm 65-70)
Tüm bölümler
- Giriş
- Adres Çubuğundan İsteğe
- Paket Anahtarlamalı Yol
- İsimden Adrese
- DNS Kayıtları
- Önbellek, Tazelik ve Güven
- Port Numarası ve Soket
- Bağlantısız Taşıma: UDP
- Üç Adımlı El Sıkışma
- Simetrik Şifreleme
- Açık Anahtarlı Kriptografi
- TLS El Sıkışması
- Sertifika Zinciri
- HTTP Mesajının Anatomisi
- Durum, Çerez ve Oturum
- HTTP/2'den HTTP/3'e
- İçerik Dağıtım Ağları
- Diğer Uygulama Protokolleri
- Katmanlı Mimari
- Hizmet ve Protokol
- Encapsulation ve Başlıklar
- Paket Yakalama ve Çözümleme
- Ağ Interface Kartı
- Fiziksel Adresleme
- Hata Sezme ve CRC
- Adres Çözümleme: ARP
- Ortam Erişimi: CSMA/CD
- Switch'ler
- Ağ Topolojileri
- Sanal Yerel Ağlar
- Kablosuz Erişim: 802.11
- Radyo Kanalı ve Kapasite
- Kablosuz Ağ Güvenliği
- Hücresel Ağlar
- Spektrum ve Kuşaklar
- Hareketlilik ve Aktarma
- Adres Kiralama: DHCP
- Adresin Anatomisi
- Adres Tükenmesi ve IPv6
- Router Mimarisi
- Kuyruk Yönetimi
- Cihaz Yapılandırma
- Routing Protokolleri
- Kontrol Düzlemi ve SDN
- Ağ İzleme ve Yönetimi
- Alanlar Arası Routing
- Adres Çevirisi
- Ara Kutular
- Tünelleme ve IPsec
- Firewall'lar
- Ağ Saldırıları
- Operatör ve Metro Ağları
- Bitten Sinyale
- Sembol Hızı ve Kanal Kapasitesi
- Multiplexing Teknikleri
- İletim Ortamları
- Bakır Kablo Sonlandırma
- Fiber Sonlandırma
- Fiber Optik İletim
- Bakır Erişim Ağı: DSL
- DSL'de Hız ve Mesafe
- Pasif Optik Ağlar
- Kablo Erişim Ağları
- Kablo Modem ve CMTS
- Denizaltı Kabloları
- Veri Merkezi Ağları
- Encapsulation Çözme
- Güvenilir Aktarım
- Tıkanıklık Denetimi
- Trafik Çözümleme
- Gecikme Bütçesi
- Soket Programlama
- Eşten Eşe ve Protokol Tasarımı
- Uyarlanır Video Akışı
- Gerçek Zamanlı Ses ve Görüntü
- Kablosuz Sensör Ağlarının Mimarisi
- Sensör Ağlarında Ortam Erişimi
- Sensör Ağlarında Yönlendirme ve IP
- Zaman Eşitleme ve Konum Bulma
- Sensör Ağı Uygulamaları
- Mobil Kablosuz Sensör Ağları
- Son Söz
68. bölümde gönderenin tıkanıklık penceresini slow start ile büyütüp kayıpta yarıya indirdiğini anlattım, ama o anlatının kanıtını vermedim.
Kanıt paketlerin kendisinde duruyor. Yeniden gönderim de, alıcının ilan ettiği pencere de yakalanmış bir dosyada satır satır görünür. Peki o dosyaya hangi soruyu sorarsın?
Işığa bakarak ölçemezsin
Bir switch’in önünde durup portların ışığına bakmak ölçüm sayılmaz. 10 Mbit/s’lik bir kanalda 64 baytlık tek bir frame telde 51,2 µs kalıyor. Göz bunu göremez.
Cihaz da bunu bildiği için etkinlik ışığını yaklaşık 50 ms boyunca yanık tutuyor. Yanma süresi gerçek iletim süresinin yaklaşık 976 katı. Işık sana bir şeyin geçtiğini söylüyor, ne kadar geçtiğini değil.
Ölçmek için frame’lerin kendisi gerekiyor ve switch’li bir ağda kopya kendiliğinden eline geçmiyor. Trafiği kopyalamanın üç yolu vardı: 21. bölümdeki ayna port (SPAN), 44. bölümdeki pasif ayırıcı (TAP) ve sürekli takılı prob. Hangisini seçeceğini arızanın huyu belirliyor.
Arıza aralıklıysa üçüncüsü tek çare. Kesintili hata anlık bakışla yakalanmaz; cihazın günlerce takılı kalması ve durmadan yazması gerekir. Arıza ararken sorulacak ilk sorulardan biri de budur: sorun güvenilir biçimde yeniden üretilebiliyor mu?
Günlerce yazan bir kayıt diski de doldurur. İki filtreden ilki, yani yakalama filtresi, o günlerde diski ayakta tutan şey oluyor:
sudo tcpdump -i eth0 -w kanit.pcap -C 100 -W 50 'tcp port 443 and host 203.0.113.10'-C 100 -W 50 kaydı 100 MB’lık elli dosyaya böler ve dolunca en eskisinin üstüne yazar; disk hiç dolmaz. Filtre ise kernel’ın içinde çalışıyor. tcpdump tırnak içindeki ifadeyi BPF (Berkeley Packet Filter) adlı küçük bir sanal makinenin koduna derleyip kernel’a veriyor ve eşleşmeyen paket kullanıcı alanına hiç kopyalanmıyor; tcpdump -d o derlenmiş kodu gösteriyor. Fikir 1990’ların başında Berkeley’de doğdu, 21. bölümde adı geçen eBPF de onun torunu.
Dosya eline geçtikten sonrası artık bir yöntem işi oluyor. Hipotez kurar, sınarsın. En bariz olanı önce denersin ve her turda tek bir şeyi değiştirirsin. Aramayı ortadan bölmek de aynı disiplinin parçası: ikili arama 1.048.576 bileşenli bir sistemde tek arızalı bileşeni yirmi sınamayla buluyor ama şartı ağır: arızanın kararlı olması gerekiyor.
Yeniden gönderim kayıtta neye benziyor?
Wireshark’ın uzman bilgisi (Expert Info), performansı düşüren aşırı yeniden gönderimi kendisi bulup işaretliyor. Bulduğunu da tcp.analysis.retransmission ya da tcp.analysis.duplicate_ack gibi filtrelenebilir alanlara çeviriyor. ARP’taki çifte adres uyarısı da bu yüzden arp.duplicate-address-detected adıyla aranabiliyor; alan protokolde değil, aracın kendi tespitinde doğuyor.
67. bölümde onay birikimliydi: tek bir onay kendinden öncekileri kapsıyordu. Kayıtta bunun iki ayrı izi var.
Birincisi üç yinelenen ACK. Aynı onay numarasının üç kez tekrarlanması, eksik bir segmentten sonra üçünün daha ulaştığını söylüyor.
Somut bir kayıtta bu şöyle duruyor. 198.51.100.7 numaralı istemci, 203.0.113.10 adresindeki sunucudan bir sayfa çekiyor. Yanıtın altıncı segmenti listede hiç yok, ama yedincisi ve sekizincisi yerinde. İstemcinin ardından yolladığı üç satır aynı onay numarasını taşıyor. Dördüncü satırda eksik segment geri geliyor ve numarası öncekilerin arasına oturuyor. Zaman damgaları arasındaki fark RTT’nin altında. Gönderen beklememiş.
İkinci iz daha sinsi. Kaybolan bir onay ile erken tetiklenmiş bir zaman aşımı kayıtta neredeyse aynı görünüyor: ikisinde de gönderen aynı segmenti ikinci kez yolluyor.
Ayıran şey tekrarın önünde ne durduğu. Aynı sıra numarasının önünde üç yinelenen onay varsa hızlı yeniden gönderim çalışmış demektir. Hiç yinelenen onay yokken tekrar geldiyse sayaç dolmuştur. İki gönderim arasındaki süreyi RTT’yle karşılaştırmak da aynı ayrımı verir: altındaysa onaylar tetiklemiştir, üstündeyse zaman aşımı.
Bir de hiç tekrarın olmadığı durum var. Alıcının onayı yolda kaybolduysa gönderen bekliyor, ama onay birikimli olduğu için bir sonraki onay o boşluğu kapatabiliyor. Kayıtta o kayıp hiç iz bırakmıyor.
İki grafik, tek zaman ekseni
Flow grafiği (Wireshark’ta Flow Graph) aynı bağlantının iki ucunu tek zaman eksenine diziyor. Başlangıç sıra numarasını takas eden SYN, SYN-ACK ve ACK burada üç ayrı satır oluyor; aynı anda soket durumu LISTEN’dan ESTABLISHED’a geçiyor. Kaybolan segment de, ardından gelen yinelenen onaylar da aynı eksende sıralanıyor.
Bağlantının bütün ömrünü tek bir eksende görelim:
- El sıkışma üç satır. Kaydın ilk üç satırı bağlantının kurulduğu andır: istemciden SYN, sunucudan SYN ve ACK birlikte, sonra istemciden ACK. Aynı anda sunucudaki soket LISTEN durumundan ESTABLISHED durumuna geçer.
- Ortadaki segment kayboluyor. Sunucu yanıtı segment segment gönderiyor. İkincisi yolda düşüyor ve istemcinin listesinde hiç görünmüyor; ardından gelen üç segment ise yerinde duruyor.
- Alıcı aynı onayı yineliyor. Onay numarası kümülatif olduğu için istemci boşluğun ötesini onaylayamıyor. Gelen her segmente aynı onay numarasıyla karşılık veriyor ve kayıtta üç yinelenen ACK birikiyor.
- Gönderen beklemeden yolluyor. Üçüncü yinelenen onay hızlı yeniden gönderimi tetikliyor. Eksik segment zaman aşımı dolmadan tekrar gidiyor ve numarası kayıtta öncekilerin arasına oturuyor.
- Pencere ilanı daralıyor. Boşluk kapandıktan sonraki onay, pencere alanında daha küçük bir değer taşıyor. Aynı eksende çizilen pencere eğrisinin düştüğü nokta bu satırdır.
Pencere grafiği ise tek bir başlık alanının zaman içindeki değeri; Wireshark onu TCP Stream Graphs altında çiziyor. Alıcının ilan ettiği alma penceresi 67. bölümden tanıdık; bu eğri o alanın her ölçümdeki değeri. Eğri dibe yaklaşıyorsa frene basan taraf ağ değil, alıcının kendisi.
Eğrinin sıfıra değdiği an ayrı bir olay. Alıcı orada kabul edebileceği bayt kalmadığını ilan etmiş oluyor. Gönderen o noktada elindeki veriyle birlikte bekliyor, çünkü izin tükenmiş durumda.
İki grafiğin asıl değeri üst üste konduklarında çıkıyor. Hız düştüğünde pencere eğrisi de dibe iniyorsa frene basan alıcıdır. Eğri yüksekte dururken yeniden gönderimler sıklaşıyorsa sorun yolda, tıkanıklıkta ya da kayıptadır. Tek eksenin işi bu ayrımı görünür kılmak.
Grafikleri okurken elindeki birim tam boy segment, yani 1.460 bayt. Basamaklar bu birimin katları hâlinde çıkıyor.
Zaman içindeki hızı çizen I/O grafiğinde çözünürlüğü örnekleme aralığı belirliyor. Aynı ölçümü bir saniyelik aralıkla komut satırında da alabilirsin:
tshark -r kanit.pcap -q -z io,stat,1Çıktı her saniye için paket ve bayt sayısını ayrı satırda döküyor.
Şifreli flow’da ne okunur?
21. bölümde yakalama interface’ini kurarken şifreli bir flow’un içeriğini açmayı buraya bırakmıştım. Sıra geldi.
11. bölümde gördüğün gibi açık anahtarlı kripto veriyi taşımıyor, yalnızca kanalı kuruyor. El sıkışmanın ürettiği ortak sır, o oturumun bütün anahtarlarının türetildiği kök.
Kökten aşağısı sürüme göre değişiyor ve ikisini karıştırmamak gerekiyor. TLS 1.2 her yön için bir şifreleme anahtarı ve ayrı bir MAC anahtarı çıkarıyordu. TLS 1.3 ayrı MAC anahtarını tümden kaldırdı: HKDF tabanlı bir anahtar takvimi önce trafik sırlarını üretiyor, her trafik sırrından da bir AEAD anahtarı ile bir başlangıç vektörü çıkıyor. Şifreleme ile bütünlük tek bir işlemde birleştiği için ikinci bir anahtara gerek kalmıyor.
Çözümleyiciye verdiğin şey bu türetilmiş malzeme, uzun ömürlü özel anahtar değil. Pratikte yolu şu: tarayıcıyı SSLKEYLOGFILE ortam değişkeniyle başlatırsan Chrome da Firefox da her oturumun sırlarını o dosyaya yazar, Wireshark da dosyayı okuyup kaydı açar. Sunucunun özel anahtarı sunucuda kalıyor ve hiçbir yere kopyalanmıyor. Elindeki malzeme yalnızca tek bir oturumu açıyor, bir sonraki oturumun kökü baştan üretiliyor. Kaydı çözebilmen sunucuyu taklit edebilmen anlamına gelmiyor.
Anahtar elinde olmasa bile kayıt susmuyor. TCP başlığı şifrelenmiyor. Sıra numarası, onay numarası ve pencere alanı açıkta akıyor; bir SSH oturumunun içeriğini okuyamasan da yeniden gönderimlerini ve pencere eğrisini çizebiliyorsun. Aynı açıklığın okura yaramayan bir öbür yüzü de var. Sıra numaraları görünür olduğu için yolun ortasındaki biri, TLS içeriği korusa bile, doğru numaralı sahte bir RST segmenti uydurup bağlantıyı kesebiliyor. 15. bölümdeki QUIC’in taşıma başlığının çoğunu da şifrelemesinin bir sebebi bu: dışarıdan bakan onun pencere eğrisini çizemiyor.
Port numarası da açıkta duruyor. 41. bölümdeki Telnet TCP 23’ten, SSH TCP 22’den, HTTPS ise varsayılan olarak 443’ten bağlanıyor. Telnet şifresiz aktığı için dinlemedeki veri doğrudan ele geçiyor. İkisini aynı düzenekte yan yana kaydettiğinde fark tek bakışta görünüyor.
Kablosuzda da kalıp değişmiyor. Paylaşılan sır doğrudan kullanılmıyor; her oturum için tek kullanımlık yeni bir AES oturum anahtarı üretiliyor. 32. bölümde gördüğün gibi WPA2-PSK’da parolayı bilen ve dört adımlı el sıkışmayı yakalayan Wireshark o oturumu açabiliyor; WPA3’te açamıyor.
Özet
- Işık bir ölçüm aleti değil: etkinlik LED’i gerçek iletim süresinin yaklaşık bin katı kadar yanık kalır; ölçmek isteyen frame’in kendisini yakalar.
- Dinleme noktası kurulur: switch’li bir ağda kopya kendiliğinden gelmez, aralıklı arızada tek çare günlerce takılı kalan bir cihazdır; BPF filtresi diski ayakta tutar.
- Üç yinelenen ACK bir sayımdır: eksik segmentten sonra üçünün ulaştığını ilan eder ve göndereni zaman aşımından önce harekete geçirir.
- Birikimli onay iz siler: kaybolan bir onayın yerini sonraki onay doldurabildiği için her kayıp yeniden gönderime dönüşmez.
- Pencere grafiği tek bir alanı çizer: eğrinin dibe inmesi, frene basanın ağ değil alıcının kendisi olduğunu söyler.
- Şifre içeriği kapatır, TCP başlığını bırakır: sıra numarası, onay ve pencere şifreli flow’da da okunur; QUIC bunları da gizler.
Kayıt elinde, grafikler çizili, hangi segmentin ne zaman kaybolduğu belli. Geriye tek bir soru kalıyor: tuşa bastığın andan ilk baytın ekrana düştüğü ana kadar bütün bu yolculuk kaç milisaniye sürdü?
70. bölüme devam et: Gecikme Bütçesi