traceroute ve mtr ile Ağ Yolu Sorunlarını Tespit Etme

Ağda bir şeyler ters gittiğinde, “neden açılmıyor?” sorusunun cevabını bulmak bazen saatlerce sürebilir. Paket kayıpları, yüksek gecikme, belirli bir noktadan sonra kopan bağlantılar… Tüm bu sorunların ortak noktası şu: sebep genellikle görünmez. İşte tam bu noktada traceroute ve mtr devreye giriyor. Bu iki araç, ağ paketlerinin nereden geçtiğini, hangi noktada sorun yaşandığını ve gecikmenin kaynağını net bir şekilde ortaya koyuyor. Bugün bu araçları gerçek dünya senaryolarıyla birlikte derinlemesine ele alacağız.

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

Traceroute, kaynak ile hedef arasındaki tüm ağ atlamalarını (hop) görselleştiren bir tanı aracıdır. Çalışma prensibi oldukça zekicedir: TTL (Time To Live) değerini 1’den başlatarak artırır. Her router, bir paketi iletirken TTL değerini 1 azaltır. TTL sıfıra düşünce router “ICMP Time Exceeded” mesajı döner. Traceroute bu mesajları toplayarak yolu adım adım haritalar.

Linux’ta traceroute, Windows’ta ise tracert olarak kullanılır. macOS’ta her ikisi de desteklenir.

Temel Kullanım

traceroute google.com

Bu komutun çıktısı şuna benzer:

traceroute to google.com (142.250.185.46), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  0.456 ms  0.389 ms  0.412 ms
 2  10.0.0.1 (10.0.0.1)  2.341 ms  2.198 ms  2.267 ms
 3  213.14.xxx.xxx  8.123 ms  7.987 ms  8.045 ms
 4  * * *
 5  72.14.232.1  12.456 ms  12.234 ms  12.567 ms
 6  142.250.185.46  14.789 ms  14.567 ms  14.890 ms

Her satırda üç gecikme değeri görürsünüz. Bunlar aynı hop’a üç ayrı prob paketi gönderilmesinden kaynaklanır. * satırları ise o hop’taki router’ın ICMP mesajlarına yanıt vermediği anlamına gelir, panik yapmaya gerek yok.

Önemli Parametreler

-n: DNS çözümlemesi yapmadan sadece IP adresleri gösterir, daha hızlıdır.

-q 5: Her hop için gönderilecek prob sayısını belirler (varsayılan 3).

-m 50: Maksimum hop sayısını artırır (varsayılan 30).

-w 10: Her prob için bekleme süresini saniye cinsinden ayarlar.

-I: ICMP Echo paketi kullanır (UDP yerine), bazı firewall’ları geçmede işe yarar.

-T: TCP SYN paketleri kullanır, genellikle en fazla firewall’ı geçer.

-p 443: Belirli bir port numarası kullanır (TCP modu ile birlikte).

# DNS çözümlemesi olmadan hızlı trace
traceroute -n google.com

# TCP mod ile 443 portuna trace (HTTPS trafiğini simüle eder)
traceroute -T -p 443 google.com

# Maksimum 50 hop, her hop için 5 prob
traceroute -m 50 -q 5 8.8.8.8

MTR: Traceroute’un Güçlendirilmiş Hali

MTR (My TraceRoute), traceroute ile ping’i birleştiren ve bunu sürekli, gerçek zamanlı olarak yapan bir araçtır. Tek bir ölçüm yerine sürekli veri toplar, bu da intermittent (aralıklı) sorunları yakalamak için son derece değerlidir.

MTR Kurulumu

# Debian/Ubuntu
sudo apt install mtr

# RHEL/CentOS/Rocky Linux
sudo yum install mtr
# veya
sudo dnf install mtr

# macOS
brew install mtr

Temel MTR Kullanımı

mtr google.com

MTR varsayılan olarak interaktif bir terminal ekranı açar ve her saniye güncellenir. Çıktıda şu kolonları görürsünüz:

• Loss%: O hop’a giden paketlerde kayıp yüzdesi
• Snt: Gönderilen toplam paket sayısı
• Last: Son paketin gecikme süresi (ms)
• Avg: Ortalama gecikme
• Best: En iyi (en düşük) gecikme
• Wrst: En kötü (en yüksek) gecikme
• StDev: Standart sapma, gecikme tutarsızlığını gösterir

MTR Parametreleri

-r: Rapor modu, interaktif ekran açmaz, belirli sayıda paket gönderip çıkar.

-c 100: Gönderilecek paket sayısını belirler.

-n: DNS çözümlemesi yapma.

–tcp: TCP mode kullan.

–port 443: Belirli port numarası.

-b: Hem IP adresi hem de hostname göster.

-o “LSD NBAW”: Görüntülenecek kolonları belirle.

–interval 0.5: Paket gönderme aralığı (saniye).

# 100 paket gönder, rapor olarak çıktı al
mtr -r -c 100 google.com

# TCP 443 ile, DNS olmadan, 200 paket
mtr --tcp --port 443 -n -c 200 -r 8.8.8.8

# Detaylı rapor, hem IP hem hostname
mtr -r -c 50 -b google.com

Gerçek Dünya Senaryoları

Senaryo 1: Web Sunucusuna Erişilemiyor

Bir müşteri sabah 9’da arayor: “Sitemiz açılmıyor, biz mi düştük?” İlk refleks sunucuya SSH atmak olur, SSH gidiyorsa sunucu ayaktadır. Ama sorun nerede?

# Önce basit bir traceroute
traceroute -n 203.0.113.50

# Çıktı:
# 1  192.168.1.1   0.5 ms
# 2  10.0.0.1      2.1 ms
# 3  213.14.xx.xx  8.2 ms
# 4  * * *
# 5  * * *
# 6  * * *
# (devam etmiyor)

1. hop’tan sonra paketler kayboluyorsa, sorun büyük ihtimalle upstream ISP’de ya da hedef sunucunun önündeki bir router’da. Şimdi MTR ile daha detaylı bakalım:

mtr -r -c 100 -n 203.0.113.50

Eğer 4. hop’ta %100 kayıp varsa ama 5. ve 6. hop’larda kayıp yoksa, 4. hop’taki router sadece ICMP’ye cevap vermiyor demektir, bu normaldir. Ama 4. hop’tan sonra hiç yanıt gelmiyorsa sorun orada ya da ilerisindedir.

Senaryo 2: Aralıklı Yavaşlama Sorunu

“Bağlantımız bazen çok yavaşlıyor ama her zaman değil” şikayeti her sysadmin’in korkulu rüyasıdır. Intermittent sorunlar için MTR biçilmiş kaftan:

# Uzun süre, yoğun test
mtr -r -c 500 --interval 0.2 -n 8.8.8.8 > mtr_rapor.txt 2>&1

Bu komut 500 paket gönderir ve raporu dosyaya yazar. Çıktıda belirli bir hop’ta yüksek StDev (standart sapma) değeri varsa, o hop’ta gecikme tutarsızlığı var demektir. Bu genellikle o router’ın aşırı yüklendiğine işaret eder.

Raporu incelerken dikkat edilecekler:

• Bir hop’ta %2-5 kayıp başlıyorsa ve sonraki hop’larda da devam ediyorsa, sorun o noktada başlıyor
• Bir hop’ta kayıp var ama bir sonrakinde kayıp yoksa, o hop sadece ICMP trafiğini düşürüyor (transit trafiği etkiliyor olmayabilir)
• Son hop’ta yüksek kayıp varsa hedef sunucuda sorun var

Senaryo 3: Belirli Bir Ülkeye Giden Trafik Yavaş

Türkiye’deki sunucunuzdan Almanya’daki bir servise bağlanıyorsunuz ve gecikme normalin çok üzerinde. Sorun routing’de mi?

# Almanya'daki bir sunucuya trace
traceroute -n frankfurt.example.com

# TCP mode ile, çünkü hedef server ICMP'yi blokluyor olabilir
traceroute -T -p 80 -n frankfurt.example.com

Eğer paketlerin önce Türkiye’den başka bir ülkeye (mesela ABD’ye) gidip oradan Almanya’ya döndüğünü görürseniz, ISP’nizin routing politikasında sorun var demektir. Bu durumu AS (Autonomous System) bilgileriyle birlikte incelemek gerekir:

# Whois ile AS numarasını bul
whois 203.0.113.1 | grep -i "AS|origin|route"

# traceroute çıktısındaki her IP için AS bilgisi
traceroute -A -n frankfurt.example.com

-A parametresi her hop için AS numarasını gösterir. Böylece paketlerin hangi otonom sistemlerden geçtiğini görebilirsiniz.

Senaryo 4: Tek Yönlü Paket Kaybı

Çok sinir bozucu bir senaryo: traceroute gidiş yolunda sorun göstermiyor ama bağlantı hala sorunlu. Unutmayın, traceroute sadece gidiş yolunu gösterir! Dönüş yolunda da sorun olabilir.

Bu durumu test etmek için hedef taraftan da trace atmak gerekir. Erişiminiz varsa:

# Hedef sunucudan kaynak IP'ye trace
traceroute -n 85.xxx.xxx.xxx  # sizin IP'niz

Eğer hedef sunucuya erişiminiz yoksa, Looking Glass servisleri kullanılabilir. Birçok büyük ISP ve CDN’in looking glass’ı mevcuttur.

Windows Tarafında Tracert

Windows’ta tracert kullanılır ve Linux’taki traceroute’dan bazı farkları vardır:

# Temel kullanım
tracert google.com

# DNS çözümlemesi olmadan
tracert -d google.com

# Maksimum hop sayısı
tracert -h 50 google.com

# Bekleme süresini artır (ms cinsinden)
tracert -w 5000 google.com

Windows’ta MTR eşdeğeri olarak WinMTR kullanılabilir, GUI tabanlıdır ve aynı işlevi görür. PowerShell seviyeyseniz şu script işe yarar:

# PowerShell ile sürekli ping ve hop analizi
Test-NetConnection -ComputerName google.com -TraceRoute

Yaygın Yanlış Yorumlamalar

“Tüm Yıldızlar Sorun Demek Değil”

Birçok router, güvenlik politikası gereği ICMP Time Exceeded mesajlarına yanıt vermez. Bu, o router’ın düştüğü anlamına gelmez. Kritik kural: son hedefe ulaşıyorsanız aradaki yıldızlar önemsizdir.

# Bu durumu test etmek için TCP kullan
traceroute -T -p 443 -n hedef.com
# veya
traceroute -I -n hedef.com  # ICMP Echo kullan

“İlk Hop’taki Yüksek Gecikme Her Zaman Kötü Değil”

Bazı modem ve router’lar, CPU’dan geçen yönetim trafiğini (ICMP gibi) düşük öncelikli olarak işler. Bu yüzden ilk hop bazen 10-20ms görünebilir ama bu gerçek bant genişliği gecikmesini yansıtmaz.

“Paket Kaybı Yüzdesi Lineer Değil”

Bir hop’ta %50 paket kaybı görüyorsunuz ama son hedefe %0 kayıp ile ulaşıyorsunuz. Bu, o router’ın ICMP yanıtlarını rate-limit’lediği anlamına gelir. Gerçek bir sorun değildir. Ancak son hop’ta kayıp varsa bu mutlaka sorun demektir.

MTR Rapor Analizi

Gerçek bir sorunlu MTR çıktısını analiz edelim:

HOST: myserver.example.com         Loss%   Snt  Last   Avg  Best  Wrst StDev
  1. 192.168.1.1                    0.0%   100   0.4   0.5   0.3   1.2   0.1
  2. 10.0.0.1                       0.0%   100   2.1   2.3   1.9   4.1   0.3
  3. 213.14.10.1                    0.0%   100   8.2   8.4   7.9   9.1   0.2
  4. 62.99.xx.xx                   22.0%   100  45.2  44.8  12.1 198.3  38.2
  5. 72.14.xx.xx                   22.0%   100  44.9  45.1  12.0 201.2  37.9
  6. 142.250.xx.xx                  0.0%   100  14.2  14.5  13.8  16.1   0.4

Bu çıktıyı okumak:

• 1-3 arası: Yerel ağ ve ISP erişim katmanı, temiz
• 4. hop: %22 kayıp başlıyor, yüksek StDev (38ms!) – sorun burada başlıyor
• 5. hop: Aynı kayıp oranı devam ediyor – 4. hop’tan etkileniyor
• 6. hop (hedef): %0 kayıp! – Garip görünüyor

Bu durumda iki ihtimal var: Ya 4 ve 5. hop’lar ICMP’yi rate-limit ediyor, ya da gerçekten o hat zaman zaman sorun çıkarıyor. Bunu anlamak için aynı testi birkaç kez tekrarlayın ve StDev değerlerine bakın. StDev 38ms ise ciddi tutarsızlık var demektir.

Otomasyon: Düzenli MTR Raporu Alma

Sorun sürekli değil, belirli saatlerde ortaya çıkıyorsa cron ile düzenli rapor alabilirsiniz:

#!/bin/bash
# /usr/local/bin/network_check.sh

HEDEF="8.8.8.8"
RAPOR_DIR="/var/log/mtr_raporlar"
TARIH=$(date +%Y%m%d_%H%M%S)

mkdir -p "$RAPOR_DIR"

mtr -r -c 60 -n --interval 1 "$HEDEF" > "$RAPOR_DIR/mtr_${TARIH}.txt" 2>&1

# Kayıp var mı kontrol et
if grep -E "[1-9][0-9]?.[0-9]+%" "$RAPOR_DIR/mtr_${TARIH}.txt" > /dev/null; then
    echo "UYARI: Paket kaybi tespit edildi - $TARIH" | 
    mail -s "Network Sorunu" [email protected] < "$RAPOR_DIR/mtr_${TARIH}.txt"
fi

Bu scripti cron’a ekleyin:

# Her 30 dakikada bir çalıştır
*/30 * * * * /usr/local/bin/network_check.sh

Traceroute ile Güvenlik Duvarı Tespiti

Traceroute farklı protokollerle çalıştırıldığında firewall kuralları hakkında ipuçları verir. Eğer UDP traceroute çalışmıyor ama TCP ile hedefine ulaşıyorsa, arada UDP’yi bloke eden bir güvenlik duvarı var demektir:

# UDP ile dene (varsayılan)
traceroute -n 203.0.113.50

# ICMP ile dene
traceroute -I -n 203.0.113.50

# TCP 80 ile dene
traceroute -T -p 80 -n 203.0.113.50

# TCP 443 ile dene
traceroute -T -p 443 -n 203.0.113.50

Her birinin sonuçlarını karşılaştırarak hangi protokollerin bloklandığını anlayabilirsiniz.

MTR ile Yük Dengeleme Tespiti

Bazı ISP’ler ve CDN’ler ECMP (Equal-Cost Multi-Path) routing kullanır. Bu durumda aynı hedefe giden paketler farklı yollar izleyebilir. MTR’de bu durumu fark edebilirsiniz:

# Birden fazla kez çalıştır ve sonuçları karşılaştır
for i in {1..3}; do
    echo "=== Test $i ===" 
    mtr -r -c 20 -n google.com
    echo ""
done

Eğer her çalıştırmada farklı hop IP’leri görüyorsanız, load balancing yapılıyor demektir. Bu bilgi, sorun gidermede önemlidir çünkü aynı sorun her traceroute’da ortaya çıkmayabilir.

Sonuç

traceroute ve mtr bir sysadmin’in ilk başvurması gereken ağ tanı araçlarından ikisidir. Traceroute hızlı bir yol haritası için idealken, MTR uzun süreli izleme ve aralıklı sorunları yakalamak için çok daha güçlüdür.

Pratik özet olarak söylemek gerekirse: Bir ağ sorunu yaşadığınızda önce traceroute -n ile genel tabloyu görün. Sorunun tam yerini belirleyemiyorsanız mtr -r -c 100 -n ile daha kapsamlı veri toplayın. Firewall veya ICMP kısıtlaması şüphesiniz varsa -T -p 443 ile TCP moduna geçin. Sorun aralıklıysa otomatik raporlama kurarak belirli saatlerdeki verileri karşılaştırın.

Bu araçları düzenli kullanan bir sysadmin, “bağlantı sorunu var” diyen birinin nereye bakacağını dakikalar içinde belirleyebilir. Herkese stressiz ticketlar ve az paket kaybı diliyorum.