traceroute ve mtr ile Ağ Yolu Analizi

yazar

Ağ sorunlarını teşhis etmek bazen dedektiflik gibidir. Paketler bir noktadan diğerine giderken onlarca farklı cihazdan geçer ve bu yolculuğun herhangi bir noktasında işler ters gidebilir. İşte tam bu noktada traceroute ve mtr araçları devreye girer. Bu yazıda bu iki güçlü aracı derinlemesine inceleyeceğiz ve gerçek dünya senaryolarında nasıl kullanacağınızı göstereceğiz.

Traceroute Nedir ve Nasıl Çalışır?

traceroute, kaynak ile hedef arasındaki ağ yolunu haritalayan bir araçtır. Temel çalışma prensibi oldukça zekicedir: TTL (Time To Live) değerini manipüle eder. Her paket gönderildiğinde TTL değeri 1’den başlar ve her bir router bu değeri 1 azaltır. TTL 0’a ulaştığında router, kaynak adrese “Time Exceeded” (ICMP Type 11) mesajı gönderir. traceroute bu özelliği kullanarak yol üzerindeki her hop’u tek tek keşfeder.

Linux sistemlerde varsayılan olarak UDP paketleri kullanılırken, Windows’taki tracert ICMP Echo Request kullanır. Linux’ta da traceroute -I ile ICMP moduna geçebilirsiniz.

Temel Kullanım

traceroute google.com

Bu basit komut size şu bilgileri verir:

  • Her satır bir “hop” yani ağ cihazını temsil eder
  • Her hop için varsayılan olarak 3 prob paketi gönderilir
  • Yanıt süreleri milisaniye cinsinden gösterilir
  • * işaretleri o hop’un yanıt vermediğini gösterir

Çıktı şöyle görünür:

traceroute to google.com (142.250.74.46), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  0.412 ms  0.389 ms  0.401 ms
 2  10.0.0.1 (10.0.0.1)  5.221 ms  5.198 ms  5.187 ms
 3  213.14.8.1 (213.14.8.1)  12.441 ms  12.389 ms  12.405 ms
 4  * * *
 5  72.14.215.165 (72.14.215.165)  18.332 ms  18.287 ms  18.301 ms

Traceroute Parametreleri

traceroute‘un zengin bir parametre seti vardır. En sık kullandıklarımı sıralayayım:

-n: DNS çözümlemesi yapmaz, sadece IP adresleri gösterir. Çok daha hızlı çalışır.

-I: ICMP Echo Request kullanır (varsayılan UDP yerine). Bazı firewall’lar UDP’yi engellediğinde işe yarar.

-T: TCP SYN paketleri kullanır. Güvenlik duvarlarını aşmak için çok etkilidir.

-p PORT: Kullanılacak port numarasını belirtir. Varsayılan UDP için 33434’tür.

-m HOP_SAYISI: Maksimum hop sayısını belirler. Varsayılan 30’dur.

-w SÜRE: Her probe için bekleme süresi (saniye). Varsayılan 5’tir.

-q SAYI: Her hop için gönderilecek probe sayısı. Varsayılan 3’tür.

-s KAYNAK_IP: Kaynak IP adresini belirler. Birden fazla ağ arayüzü olan sunucularda kullanışlıdır.

-A: AS (Autonomous System) numaralarını gösterir. Hangi ISP’nin ağında olduğunuzu anlamak için harikadır.

# DNS çözümlemesi olmadan hızlı tarama
traceroute -n 8.8.8.8

# ICMP modunda çalıştır
traceroute -I 8.8.8.8

# TCP SYN ile 80 portuna
traceroute -T -p 80 example.com

# AS numaralarını göster
traceroute -A google.com

# Maksimum hop sayısını 15 ile sınırla
traceroute -m 15 -n 1.1.1.1

# Her hop için 5 probe gönder, 2 saniye bekle
traceroute -q 5 -w 2 example.com

MTR: Modern ve Gerçek Zamanlı Ağ Analizi

mtr (Matt’s Traceroute veya My Traceroute), traceroute ile ping‘in birleşimi gibi düşünebilirsiniz. Tek seferlik bir anlık görüntü almak yerine, sürekli probe paketleri göndererek gerçek zamanlı istatistikler toplar. Özellikle aralıklı (intermittent) sorunları tespit etmek için vazgeçilmezdir.

MTR Kurulumu

# Debian/Ubuntu
sudo apt install mtr

# RHEL/CentOS/Rocky Linux
sudo dnf install mtr

# Arch Linux
sudo pacman -S mtr

Temel MTR Kullanımı

# Standart interaktif mod
mtr google.com

# 100 paket gönder ve rapor üret (script/otomasyon için)
mtr --report --report-cycles 100 google.com

# DNS çözümlemesi olmadan
mtr -n google.com

# Hem hostname hem IP göster
mtr -b google.com

MTR ekranında şu kolonları görürsünüz:

  • Host: Hop’un hostname veya IP adresi
  • Loss%: Paket kayıp yüzdesi
  • Snt: Gönderilen paket sayısı
  • Last: Son probe’un yanıt süresi
  • Avg: Ortalama yanıt süresi
  • Best: En iyi (en düşük) yanıt süresi
  • Wrst: En kötü (en yüksek) yanıt süresi
  • StDev: Standart sapma (jitter göstergesi)

MTR Parametreleri

-r veya –report: Rapor modunda çalışır, sonuçları stdout’a yazar.

-c SAYI veya –report-cycles: Kaç probe döngüsü çalışacağını belirler.

-n veya –no-dns: DNS çözümlemesi yapmaz.

-b veya –show-ips: Hem hostname hem IP gösterir.

-o FORMAT: Çıktı sütunlarını özelleştir. Örneğin -o "LSDR" Loss, Sent, Drop, Received gösterir.

-i SÜRE: Probe aralığı (saniye).

-s BOYUT: Paket boyutu (byte).

-T veya –tcp: TCP SYN kullanır.

-P PORT: TCP/UDP portu belirtir.

-4: Sadece IPv4 kullan.

-6: Sadece IPv6 kullan.

-u veya –udp: UDP kullan.

–aspath: AS path bilgilerini gösterir.

# 50 döngü sonra rapor üret, DNS yok
mtr --report --report-cycles 50 -n 8.8.8.8

# TCP SYN ile 443 portuna test
mtr -T -P 443 --report --report-cycles 30 example.com

# Büyük paket boyutuyla test (MTU sorunlarını tespit için)
mtr -s 1400 --report --report-cycles 20 google.com

# IPv6 ile test
mtr -6 --report --report-cycles 30 ipv6.google.com

# Özel sütun formatıyla
mtr -r -c 100 -o "LSDR NBAW" google.com

Gerçek Dünya Senaryoları

Senaryo 1: “Site Yavaş, Sorun Nerede?”

Müşteriniz sizin sunucunuza bağlanırken yavaşlık yaşıyor. İlk refleksiniz sunucuya ping atmak olabilir ama bu tek başına yeterli değildir.

# Önce MTR ile genel bir görüntü al
mtr --report --report-cycles 50 -b musteri-ip-adresi

# Eğer sunucudan dışarı test yapacaksanız
mtr --report --report-cycles 50 -b google.com

MTR çıktısında şunu arıyorsunuz: Hangi hop’tan sonra latency belirgin şekilde artıyor? Eğer hop 5’e kadar 10ms, hop 6’da aniden 150ms görüyorsanız, sorun 5. ve 6. hop arasındaki bağlantıdadır. Bu çoğunlukla ISP’ler arası peering noktalarında yaşanır.

Önemli not: Bir hop’ta yüksek latency görüp paniğe kapılmayın. Eğer sonraki hop’larda latency normale dönüyorsa, o hop sadece ICMP paketlerine düşük öncelik veriyordur, gerçek bir sorun değildir.

Senaryo 2: Aralıklı Paket Kaybı Tespiti

En sinir bozucu ağ sorunlarından biri aralıklı paket kaybıdır. traceroute tek seferlik çalıştığında bu sorunu yakalayamayabilirsiniz.

# 200 döngü ile uzun süreli test - aralıklı sorunları yakalar
mtr --report --report-cycles 200 -n hedef-sunucu.com

# Daha kısa aralıklarla yoğun test
mtr --report --report-cycles 100 -i 0.5 -n hedef-ip

Çıktıda %5’in üzerinde paket kaybı görüyorsanız ciddi bir sorun var demektir. Hangi hop’ta başladığına bakın. Eğer hop 8’de %30 kayıp varsa ve hop 9-12’de de aynı kayıp oranı devam ediyorsa, sorun hop 8’dedir. Eğer hop 8’de %30 kayıp ama hop 9-12’de %0 ise, hop 8 sadece ICMP’ye düşük öncelik veriyor ve gerçek bir sorun yok.

Senaryo 3: Firewall Tespiti ve TCP Traceroute

Bazen UDP ve ICMP paketleri firewall’lar tarafından engellenir ve * görürsünüz. Bu durumda TCP probe kullanmak daha gerçekçi sonuçlar verir.

# HTTP trafiği gibi davranarak test
traceroute -T -p 80 -n hedef-sunucu.com

# HTTPS trafiği gibi
traceroute -T -p 443 -n hedef-sunucu.com

# MTR ile TCP test
mtr -T -P 443 --report --report-cycles 30 hedef-sunucu.com

Bir web sunucusuna erişemiyorsunuz ama ping atabiliyorsanız, TCP 80/443 traceroute ile hangi hop’ta paketin düştüğünü net olarak görebilirsiniz. Bu bilgi, ISP’nize veya veri merkezi ekibine bilet açarken çok değerlidir.

Senaryo 4: Asimetrik Routing Tespiti

Ağ sorunlarının en karmaşıklarından biri asimetrik routing’dir. Paketler A-B-C yolundan giderken, cevaplar C-D-A yolundan dönebilir. Bu durum tutarsız latency ve paket kaybına yol açar.

# Kendi sunucunuzdan hedefe
traceroute -n 8.8.8.8

# Hedef sunucu üzerinde erişiminiz varsa, oradan size
ssh hedef-sunucu "traceroute -n sizin-ip-adresiniz"

Her iki yönde de traceroute çalıştırıp karşılaştırırsanız routing asimetrisini görebilirsiniz. AS numaralarıyla birlikte çalıştırmak daha da aydınlatıcı olur:

traceroute -A -n hedef-sunucu.com

Senaryo 5: MTU Sorunları

Büyük paketler bazen yol üzerindeki bir cihazda fragmentlama sorununa yol açabilir. Bu özellikle VPN tünelleri veya eski donanımlarda görülür.

# Farklı paket boyutlarıyla test
mtr -s 1500 --report --report-cycles 20 -n hedef.com
mtr -s 1400 --report --report-cycles 20 -n hedef.com
mtr -s 1200 --report --report-cycles 20 -n hedef.com

Eğer küçük paketler geçiyor ama büyük paketler geçmiyorsa MTU probleminiz var demektir. Bu durumda ilgili arayüzde MTU ayarını düşürmeyi veya TCP MSS clamping uygulamayı düşünebilirsiniz.

İleri Düzey Kullanım

MTR Çıktısını Log Dosyasına Kaydetme

Sorun yaşandığı anlarda otomatik log almak için:

# Her 5 dakikada bir rapor al ve logla
while true; do
    echo "=== $(date) ===" >> /var/log/mtr-report.log
    mtr --report --report-cycles 30 -n 8.8.8.8 >> /var/log/mtr-report.log
    sleep 300
done

Birden Fazla Hedefe Eş Zamanlı Test

# Arka planda çalıştırarak birden fazla hedef test et
for host in google.com cloudflare.com 8.8.8.8 1.1.1.1; do
    mtr --report --report-cycles 50 -n "$host" > "/tmp/mtr-${host}.txt" &
done
wait
cat /tmp/mtr-*.txt

JSON Çıktısı ile Otomasyon

MTR’nin JSON çıktı desteği otomasyon için çok kullanışlıdır:

# JSON formatında çıktı al
mtr --report --report-cycles 50 -n --json google.com

# JSON çıktısını dosyaya kaydet
mtr --report --report-cycles 100 -n --json 8.8.8.8 > /tmp/mtr-sonuc.json

# jq ile parse et (paket kaybı olan hop'ları filtrele)
mtr --report --report-cycles 50 -n --json google.com | 
    jq '.report.hubs[] | select(.Loss > 0) | {hop: .count, ip: .host, loss: .Loss}'

Sonuçları Yorumlamak

Deneyimli bir sysadmin olarak şunu söyleyebilirim: MTR ve traceroute çıktılarını okumak bir sanattır. İşte temel yorumlama kuralları:

  • Yıldızlar (*) her zaman sorun anlamına gelmez. Birçok ISP router’ı ICMP paketlerine yanıt vermez ama transit trafiği düzgün iletir.
  • MPLS tünelleri bazen hop’ları gizler. 1-2 hop’un eksik görünmesi normaldir.
  • Latency artışı her hop’ta biraz artabilir, bu normaldir. Aniden 50ms üzeri artış varsa dikkat edin.
  • Son hop’a bak: Eğer hedefe ulaşabiliyorsanız ve son hop latency’si kabul edilebilirse, aradaki * işaretleri büyük ihtimalle sorun değildir.
  • Jitter (StDev): Standart sapmanın yüksek olması bağlantı kalitesinin tutarsız olduğunu gösterir. VoIP ve oyun gibi gecikmeye duyarlı uygulamalar için kritiktir.

Hızlı Referans: Hangi Durumda Hangisi?

Hangi aracı ne zaman kullanacağınız konusunda pratik bir yol haritası:

  • Hızlı yol keşfi için traceroute -n kullanın
  • Aralıklı sorunlar için mtr --report --report-cycles 100 kullanın
  • Firewall bypass testi için traceroute -T -p 443 kullanın
  • Otomasyon ve raporlama için mtr --json kullanın
  • MTU sorunları için farklı -s değerleriyle mtr kullanın
  • AS numaralarını görmek için traceroute -A kullanın
  • Uzun süreli izleme için loop içinde mtr --report kullanın

Sonuç

traceroute ve mtr, her sysadmin’in araç kutusunda bulunması gereken temel araçlardır. traceroute hızlı bir anlık görüntü almak için idealdir. mtr ise özellikle aralıklı sorunları yakalamak ve istatistiksel veri toplamak için çok daha güçlüdür.

Bir ağ sorunuyla karşılaştığınızda refleksiniz önce ping, sonra mtr olmalıdır. MTR size hem yol haritasını hem de o yol üzerindeki paket kayıplarını ve gecikme istatistiklerini tek seferde verir. ISP’nize veya veri merkezinize sorun bildirirken elinizde bir MTR raporu olursa, destek süreci dramatik biçimde kısalır çünkü sorunun tam olarak nerede olduğunu kanıtlamanız kolaylaşır.

Bu araçları düzenli olarak kullanmaya başladıktan sonra ağınızın “normal” davranışını öğrenirsiniz. Normal’i bilmek, anormal’i hemen fark etmenizi sağlar. Bu da proaktif sorun yönetiminin temelidir.

Yorum yapın