Bölüm 61:Trafik Çözümleme

60. bölümde gönderenin tıkanıklık penceresini yavaş başlangıçla 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 anahtarın önünde durup portların ışığına bakmak ölçüm sayılmaz. 10 Mbit/s’lik bir kanalda 64 baytlık tek bir çerçeve 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 çerçevelerin kendisi gerekiyor, ve anahtarlı bir ağda kopya kendiliğinden eline geçmiyor. Trafiği kopyalamanın üç yolu vardı: ayna port, pasif optik ayırıcı, 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. Bilgi toplama listesinin son sorusu zaten 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 tek şey oluyor:

sudo tcpdump -i eth0 -w kanit.pcap 'tcp port 443 and host 192.0.2.10'

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?

Üst düzey çözümleyicilerin uzman analiz kipi, performansı düşüren aşırı yeniden gönderimi kendisi bulup işaretliyor. Bulduğunu da filtrelenebilir bir alana çeviriyor. ARP’taki çifte adres uyarısı bu yüzden arp.duplicate-address-detected adıyla aranabiliyor; alan protokolde değil, aracın kendi tespitinde doğuyor.

Onay kümülatifti: 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.20 numaralı istemci, 203.0.113.9 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 gidiş-dönüş süresinin 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 gidiş-dönüş süresiyle 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 kümülatiflik yüzünden bir sonraki onay o boşluğu kapatabiliyor. Kayıtta o kayıp hiç iz bırakmıyor.

İki grafik, tek zaman ekseni

Akış grafiği 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:

Pencere grafiği ise tek bir başlık alanının zaman içindeki değeri. Alıcının ilan ettiği alma penceresi tanıdık; bu eğri tam olarak 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. Yeniden gönderimin akış grafiğindeki satırı ile pencere eğrisinin düştüğü nokta aynı ana denk geliyorsa yavaşlamanın kaynağı alıcıdır. Denk gelmiyorsa kayıp yolda olmuş ve alıcı buna hiç tepki vermemiştir. 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.

Çözünürlüğü örnekleme aralığı belirliyor ve çözümleyicilerin varsayılanı bir saniye. Aynı aralığı 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 akışta ne okunur?

Yakalama arayüzünü kurarken şifreli bir akışın içeriğini açmayı buraya bırakmıştım. Borcu şimdi ödüyorum.

Açık anahtarlı kripto veriyi taşımıyor, yalnızca kanalı kuruyor. El sıkışmada karşıya geçirilen master secret, o oturumun bütün diğer anahtarlarının üretildiği kök. Bir anahtar türetme fonksiyonu bu kökten dört anahtar çıkarıyor: her yön için ayrı bir şifreleme anahtarı, her yön için ayrı bir MAC anahtarı.

Çözümleyiciye verdiğin şey bu türetilmiş malzeme, uzun ömürlü özel anahtar değil. O 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 ortadaki bir saldırgan segmentleri yeniden sıralayabiliyor.

Port numarası da açıkta duruyor. 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.

Özet

Peki, ne öğrendik?

• 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 çerçevenin kendisini yakalar.
• Dinleme noktası kurulur. Anahtarlı bir ağda kopya kendiliğinden gelmez, aralıklı arızada tek çare günlerce takılı kalan bir cihazdır.
• Üç 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.
• Kümülatif 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, başlığı bırakır. TCP başlığı açıkta aktığı için sıra numarası, onay ve pencere şifreli akışta da okunur.

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ü?