Ağ Tanılama Araçları (ping, traceroute ve mtr)

"Sitem bazen açılıyor, bazen açılmıyor", "sunucuya bağlanamıyorum ama başkaları bağlanabiliyor", "ping atıyorum çalışıyor ama sayfa yavaş" — bir sistem yöneticisi olarak bu cümleleri her gün duyarsınız. Bu belirsiz şikayetlerin altında neredeyse her zaman ölçülebilir bir gerçek yatar: paketler bir yerde kayboluyor, bir atlama noktasında birikiyor ya da hiç varmıyor. Sorunu "hissetmek" yerine görebilmek için elinizde üç temel araç vardır ve iyi haber şu ki üçü de neredeyse her sistemde hazır gelir: ping, traceroute ve mtr.

Bu rehberde bu üç aracı sırayla ele alacağız. Önce her birinin ne ölçtüğünü, sonra çıktılarını nasıl okuyacağınızı, en önemlisi de "bu çıktı bana neyi söylüyor, sorun bende mi yoksa yolda mı" sorusunu gerçek örneklerle yanıtlayacağız. ICMP paketlerinin filtrelendiği modern sunucularda klasik ping'in yanıltıcı olabileceğini ve bu durumda hangi TCP tabanlı alternatiflere geçeceğinizi de göstereceğiz. Amaç, bir arıza anında panik yerine metodik bir teşhis akışı yürütebilmeniz.

ping ile Erişilebilirlik ve Temel Sağlık Kontrolü#

ping, ağ tanılamasının en temel aracıdır. Hedef makineye küçük bir ICMP "echo request" paketi gönderir, karşı taraf "echo reply" ile yanıtlar ve gidiş-dönüş süresini (RTT — Round Trip Time) milisaniye cinsinden ölçer. Yani ping size iki basit ama kritik soruyu yanıtlar: "Bu makineye ulaşabiliyor muyum?" ve "Ne kadar sürede yanıt alıyorum?"

Temel kullanımı son derece basittir. Linux ve macOS'ta ping sürekli çalışır, bu yüzden -c ile paket sayısını sınırlamak iyi bir alışkanlıktır:

# 5 paket gönder ve dur
ping -c 5 clou.tr

# Paketler arası bekleme süresini kısalt (root gerekebilir)
ping -c 10 -i 0.2 sunucu-ip-adresi

# Paket boyutunu büyüt (MTU / parçalanma testi için)
ping -c 4 -s 1472 clou.tr

Windows tarafında ping varsayılan olarak 4 paket gönderip durur; sürekli çalıştırmak isterseniz ping -t clou.tr kullanırsınız. İlk gözlemlemeniz gereken şey basittir: yanıt geliyor mu, gelmiyor mu? Eğer hiç yanıt yoksa, ya hedef kapalı ya ağ yolu kopuk ya da (çok yaygın olan) hedef ICMP paketlerini kasıtlı olarak yok sayacak şekilde yapılandırılmış demektir. Bu son ihtimali akılda tutun, çünkü "ping atmıyor" ile "sunucu çalışmıyor" aynı şey değildir.

ping Çıktısını Okumak: RTT, TTL ve Paket Kaybı#

Ham çıktıya bakalım ve her satırın ne anlattığını çözelim:

$ ping -c 5 clou.tr
PING clou.tr (185.x.x.x) 56(84) bytes of data.
64 bytes from 185.x.x.x: icmp_seq=1 ttl=54 time=28.4 ms
64 bytes from 185.x.x.x: icmp_seq=2 ttl=54 time=27.9 ms
64 bytes from 185.x.x.x: icmp_seq=3 ttl=54 time=61.2 ms
64 bytes from 185.x.x.x: icmp_seq=4 ttl=54 time=28.1 ms
64 bytes from 185.x.x.x: icmp_seq=5 ttl=54 time=28.0 ms

--- clou.tr ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 27.9/34.7/61.2/13.1 ms

Buradaki üç değer sizin teşhis pusulanızdır:

• time (RTT): Her paketin gidip dönme süresi. Aynı şehirdeki bir sunucuya 1-10 ms, yurt içi farklı bir veri merkezine 15-40 ms, Avrupa'ya 40-70 ms, ABD'ye 100-150 ms tipik değerlerdir. Yukarıdaki örnekte 3. paketin 61.2 ms ile diğerlerinden yüksek olması "jitter" (gecikme dalgalanması) işaretidir; tek başına sorun değildir ama sürekli tekrar ediyorsa yol üzerinde bir tıkanıklık var demektir.
• ttl: Time To Live. Paketin geçtiği yönlendirici (hop) sayısına dair ipucu verir. Başlangıç değeri işletim sistemine göre 64, 128 veya 255'tir; gördüğünüz 54, muhtemelen 64'ten başlayıp yolda 10 atlama geçmiş bir Linux sunucusudur. TTL'in sürekli değişmesi, paketlerinizin farklı yollardan gittiğini (yük dengeleme) düşündürebilir.
• packet loss (paket kaybı): En kritik metrik budur. %0 idealdir. %1-2 çoğu uygulamada fark edilmez ama VoIP ve oyun için sorundur. %5 ve üzeri kayıp, kullanıcının "site kopuyor, yavaş" dediği durumun doğrudan sebebidir.

Şunu unutmayın: yüksek RTT tek başına "kötü" değildir; okyanus ötesi bir sunucuya doğal olarak yüksek gecikme olur. Asıl tehlike kararsızlıktır — min/avg/max arasındaki uçurum ve paket kaybı. Sabit 120 ms, dalgalanan 30-90 ms'den çoğu zaman daha sağlıklıdır.

traceroute ile Yolun Haritasını Çıkarmak#

ping size "ulaşabiliyorum/ulaşamıyorum" der ama yolda ne olduğunu söylemez. İşte burada traceroute devreye girer. Paketinizin bilgisayarınızdan hedefe giderken geçtiği her yönlendiriciyi (hop) sırayla listeler ve her birine olan gecikmeyi ölçer. Bu, sorunun kendi bağlantınızda mı, ISS'inizde mi (İnternet Servis Sağlayıcı), omurgada mı yoksa hedef veri merkezinde mi olduğunu ayırt etmenin tek yoludur.

Çalışma mantığı zekicedir: TTL değerini 1'den başlatarak paketler gönderir. TTL=1 olan paket ilk yönlendiricide "ölür" ve o yönlendirici bir "TTL exceeded" hatası döner — böylece ilk hop'u öğreniriz. Sonra TTL=2 ile ikinci hop, TTL=3 ile üçüncü... hedefe varana kadar bu böyle devam eder.

# Linux / macOS
traceroute clou.tr

# DNS çözümlemesini kapat (çok daha hızlı, sadece IP göster)
traceroute -n clou.tr

# UDP yerine ICMP kullan (bazı yollarda daha temiz sonuç)
traceroute -I clou.tr

# Windows karşılığı
tracert clou.tr

-n bayrağını kullanmanızı özellikle öneririm; her hop için ters DNS sorgusu yapmayı beklememek çıktıyı çok hızlandırır. Modern Linux dağıtımlarında traceroute yerine tracepath de bulunur ve root yetkisi gerektirmez; işlevleri büyük ölçüde örtüşür.

traceroute Çıktısını Yorumlamak#

Bir traceroute çıktısı ilk bakışta korkutucu görünür ama okuma kuralları nettir:

$ traceroute -n clou.tr
traceroute to clou.tr (185.x.x.x), 30 hops max, 60 byte packets
 1  192.168.1.1      0.512 ms   0.489 ms   0.501 ms
 2  10.20.0.1        4.221 ms   4.108 ms   4.330 ms
 3  81.x.x.x         8.774 ms   8.912 ms   9.001 ms
 4  81.x.x.x        12.443 ms  12.221 ms  12.560 ms
 5  * * *
 6  185.x.x.1       28.115 ms  27.998 ms  28.203 ms
 7  185.x.x.x       28.440 ms  28.512 ms  28.399 ms

Her satır bir hop'tur ve her hop için üç ölçüm yapılır (bu yüzden üç süre görürsünüz). Yorumlarken şu prensiplere bağlı kalın:

• İlk hop genellikle kendi yönlendiricinizdir (192.168.1.1 gibi). Buradaki gecikme yüksekse sorun ev/ofis ağınızın içindedir.
• Yıldızlar (* * *) her zaman kötü değildir. 5. hop'ta gördüğünüz * * * çoğu zaman o yönlendiricinin ICMP hata mesajı üretmeyi düşük öncelikli görmesi (rate-limit) ya da güvenlik nedeniyle yanıt vermemesidir. Paketler yine de sonraki hop'a ulaşıyorsa — 6. hop yanıt veriyorsa — endişelenmeyin. Asıl sorun, yıldızların hedefe kadar sürüp gitmesidir.
• Gecikmenin nerede zıpladığına bakın. Hop'lar arasında kademeli artış normaldir. Ama bir hop'ta gecikme aniden 15 ms'den 180 ms'ye fırlıyor ve sonrasında öyle kalıyorsa, o atlama noktası (genellikle bir uluslararası çıkış veya yoğun bir omurga) darboğazdır.
• Son hop hedefinizdir. Buraya kadar geldiyseniz temel erişim sağlıklıdır.

Şunu vurgulamak isterim: tek bir hop'ta yüksek gecikme görüp panik yapmayın. Ara yönlendiriciler kendilerine yönelik ICMP'yi düşük öncelikte işler; oradaki 200 ms sadece "yönlendirici bana cevap vermeyi umursamadı" anlamına gelebilir. Önemli olan son hedefe olan gecikme ve kaybın nerede başlayıp devam ettiğidir.

mtr ile Canlı ve Birleşik Analiz#

ping erişimi, traceroute yolu gösterir. mtr (My TraceRoute) ise ikisini birleştirir ve sürekli çalışarak yolun her hop'unu canlı olarak izler. Traceroute'un tek seferlik fotoğrafı yerine, mtr size hareketli bir film sunar — hangi hop'ta ne kadar paket kaybı biriktiğini zaman içinde görürsünüz. Aralıklı (intermittent) sorunları yakalamak için elinizdeki en güçlü araç budur.

# Etkileşimli canlı ekran
mtr clou.tr

# Rapor modu: 100 döngü çalış, sonucu bir kerede yazdır (ticket'a eklemek için ideal)
mtr -rwc 100 clou.tr

# Sadece IP (ters DNS yok)
mtr -n clou.tr

Rapor modu çıktısı şöyle görünür ve gerçek altın buradadır:

$ mtr -rwc 100 clou.tr
HOST: istemci                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1               0.0%    100    0.5    0.6   0.4   1.9   0.2
  2.|-- 10.20.0.1                 0.0%    100    4.1    4.3   3.9   9.8   0.7
  3.|-- 81.x.x.x                  0.0%    100    8.7    9.1   8.4  22.1   1.8
  4.|-- 81.x.x.x                 12.0%    100   45.2   48.6  12.4 210.3  35.1
  5.|-- 185.x.x.1                 0.0%    100   28.1   28.4  27.9  31.2   0.6
  6.|-- 185.x.x.x                 0.0%    100   28.4   28.5  27.9  29.9   0.4

Bu tablo bir teşhis mucizesidir. Loss% sütunu her hop'taki paket kaybını, Avg/Best/Wrst gecikmenin ortalamasını ve uçlarını, StDev ise kararlılığı (standart sapma) gösterir. Şimdi kritik yorumlama kuralı: 4. hop'ta %12 kayıp görüyoruz ama 5. ve 6. hop'ta kayıp %0'a düşüyor. Bu, 4. hop'un aslında sorunsuz olduğu anlamına gelir! O yönlendirici sadece kendisine yönelik ICMP'yi rate-limit'liyor; paketleri sorunsuzca ilerletiyor. Gerçek bir sorun olsaydı, kayıp o hop'tan itibaren son hedefe kadar taşınırdı.

Kural şudur: Bir hop'taki kaybın anlamlı olması için, o kaybın sonraki tüm hop'larda ve son hedefte de sürmesi gerekir. Ortada beliren ve sonra kaybolan kayıp, neredeyse her zaman ara yönlendiricinin ICMP'yi umursamamasıdır — gerçek bir arıza değil. Bu tek kural, gereksiz yere ISS'nizi aramaktan sizi defalarca kurtarır.

ICMP Engelli Sunucularda TCP Alternatifleri#

Modern sunucuların ve bulut sağlayıcılarının önemli bir kısmı, DDoS yüzeyini azaltmak için ICMP echo paketlerini (yani klasik ping'i) filtreler. Bu durumda ping "100% packet loss" der ama sunucu gayet çalışıyordur — web sitesi açılır, SSH bağlanır. Yani ICMP kaybı bu senaryoda tamamen yanıltıcıdır. Bu noktada gerçek servis portlarını (80, 443, 22) test eden TCP tabanlı araçlara geçmelisiniz.

En kullanışlı araç tcping mantığında çalışan yöntemlerdir. nc (netcat), nmap ve mtr'nin TCP modu bu iş için biçilmiş kaftandır:

# netcat ile belirli bir portun açık olup olmadığını test et (-z tarama, -v ayrıntılı)
nc -zv clou.tr 443

# nmap ile port ve gecikme (ICMP olmadan servis kontrolü)
nmap -p 80,443,22 clou.tr

# mtr'yi TCP 443 üzerinden çalıştır — ICMP engelliyse bile yol analizi
mtr --tcp --port 443 clou.tr

# curl ile HTTP seviyesinde zamanlama ölçümü (DNS, bağlantı, TLS ayrı ayrı)
curl -o /dev/null -s -w "DNS: %{time_namelookup}s | Bağlantı: %{time_connect}s | TLS: %{time_appconnect}s | Toplam: %{time_total}s\n" https://clou.tr

Bu curl komutunu özellikle sevin: size sorunun DNS çözümlemesinde mi, TCP el sıkışmasında mı, TLS anlaşmasında mı yoksa sunucunun yanıt üretmesinde mi olduğunu ayrıştırır. "Site yavaş" şikayetinin gerçek katmanını bulmanın en hızlı yoludur. DNS aşaması yüksekse sorun ping/traceroute'ta değil, ad çözümlemesindedir — bu konuyu DNS nedir rehberimizde derinlemesine ele aldık.

Aşağıdaki tablo, hangi durumda hangi aracı seçeceğinizi özetler:

Metodik Teşhis Akışı: Bir Örnek Senaryo#

Araçları öğrenmek yetmez; onları doğru sırayla kullanmak gerekir. Diyelim ki bir müşteri "sunucum ara ara erişilemez oluyor" diyor. İzleyeceğiniz akış şudur. Önce ping -c 20 ile temel kaybı ölçün — sürekli mi yoksa aralıklı mı kayıp var? Kayıp varsa mtr -rwc 200 çalıştırıp kaybın hangi hop'ta başlayıp son hedefe kadar taşındığını bulun. Kayıp ilk 1-2 hop'ta (kendi ağınız/ISS'iniz) başlıyorsa sorun sizde ya da sağlayıcınızdadır; ortada bir uluslararası çıkışta başlıyorsa omurga sorunudur; yalnızca son hedefte varsa sunucu ya da veri merkezindedir.

Sunucunuza yönetici olarak erişiminiz varsa, bir de sunucunun içinden dışarıya doğru ters yönde mtr çalıştırın — sorun çift yönlü olmayabilir. Bu tür sunucu tarafı tanı ve müdahaleyi tek başınıza yürütmek istemiyorsanız sunucu yönetimi hizmetimiz devreye girer; ekibimiz bu ölçümleri sizin adınıza alıp veri merkeziyle iletişimi yürütür. Temel Linux komutlarıyla arası iyi olmayan ekip arkadaşlarınız için Linux temel komutları rehberimiz de iyi bir başlangıç noktasıdır. Erişilebilirlik ve gecikmenin altyapı kaynaklı olup olmadığını ise ağ durumu ve uptime izleme araçlarımızla sürekli takip edeb, kesintileri anında görebilirsiniz.

Sıkça Sorulan Sorular#

ping çalışıyor ama sitem açılmıyor, sebebi ne olabilir?#

ping yalnızca ICMP seviyesinde makinenin ayakta olduğunu gösterir; web sunucusunun (80/443 portu) çalıştığını değil. Bu durumda makine açık ama Nginx/Apache servisi durmuş, güvenlik duvarı web portlarını kapatmış ya da DNS yanlış IP'ye işaret ediyor olabilir. curl -v https://siteniz ve nc -zv siteniz 443 komutlarıyla HTTP katmanını doğrudan test edin; sorunun ağ değil uygulama katmanında olduğunu büyük olasılıkla göreceksiniz.

traceroute çıktısında yıldız (* * *) görüyorum, bağlantım kopuk mu?#

Hayır, tek başına yıldızlar bağlantının koptuğu anlamına gelmez. Birçok ara yönlendirici, güvenlik veya performans nedeniyle kendisine yönelik ICMP hata mesajlarını yanıtlamaz ya da düşük öncelikte işler. Eğer yıldızları takip eden sonraki hop'lar tekrar yanıt veriyorsa ve son hedefe ulaşabiliyorsanız yolunuz sağlıklıdır. Sorun ancak yıldızlar o noktadan hedefe kadar kesintisiz sürüyorsa gerçektir.

mtr, ping ve traceroute'tan daha mı iyi, hangisini kullanmalıyım?#

mtr, ping ile traceroute'un işlevlerini birleştirip sürekli çalıştığı için özellikle aralıklı (bazen olan, bazen olmayan) sorunları yakalamada üstündür. Ancak tek seferlik hızlı bir "açık mı kapalı mı" kontrolü için ping, statik bir yol haritası için traceroute daha pratiktir. En sağlıklı yaklaşım üçünü birbirinin alternatifi değil tamamlayıcısı olarak görmek; hızlı bakış için ping, detaylı ve kalıcı analiz için mtr -rwc 100 kullanmaktır.

Yüksek ping (RTT) süresi her zaman kötü müdür?#

Hayır. Coğrafi olarak uzak bir sunucuya doğal olarak yüksek gecikme olur; İstanbul'dan ABD'deki bir sunucuya 120 ms tamamen normaldir. Asıl önemli olan gecikmenin kararlı olmasıdır. Sürekli sabit bir yüksek değer, dalgalanan ve zaman zaman fırlayan bir düşük değerden çoğu uygulama için daha iyidir. RTT'yi mutlak bir sayı olarak değil, paket kaybı ve standart sapma ile birlikte değerlendirin.

Paket kaybını hangi hop'tan itibaren ciddiye almalıyım?#

Bir hop'ta beliren kaybın anlamlı sayılması için o kaybın sonraki tüm hop'larda ve son hedefte de devam etmesi gerekir. Ortada bir hop'ta görülüp sonraki hop'larda %0'a düşen kayıp, neredeyse her zaman o yönlendiricinin ICMP'yi düşük öncelikte işlemesidir ve gerçek bir sorun değildir. Kayıp son hedefe kadar taşınıyorsa ve %2'nin üzerindeyse müdahale gerektiren gerçek bir arıza var demektir.

Windows'ta bu araçların karşılığı nedir?#

Windows'ta ping aynı isimle gelir (sürekli çalıştırmak için ping -t), traceroute'un karşılığı tracert, yol boyunca istatistik için ise pathping komutu vardır ve pathping mtr'ye en yakın yerleşik araçtır. Daha zengin bir canlı analiz için WinMTR gibi ücretsiz üçüncü parti bir uygulamayı kurabilirsiniz; TCP tabanlı testler için ise Test-NetConnection -Port 443 siteniz PowerShell komutu netcat'in yerini tutar.

Kapanış#

Ağ sorunları sanıldığı kadar gizemli değildir; doğru araçları doğru sırayla kullandığınızda neredeyse her zaman ölçülebilir bir cevaba ulaşırsınız. ping ile erişilebilirliği ve gecikmeyi görün, traceroute ile yolun neresinde takıldığınızı bulun, mtr ile aralıklı kayıpları canlı yakalayın ve ICMP engelli hedeflerde nc, nmap, curl -w gibi TCP tabanlı araçlara geçin. En kritik alışkanlık ise şu tek kuralı içselleştirmektir: bir hop'taki kayıp, ancak son hedefe kadar sürüyorsa gerçektir.

Bu tanılamaları kendi başınıza yürütmek yerine altyapısı sağlam, düşük gecikmeli ve profesyonelce izlenen bir ortam istiyorsanız Clou.TR yanınızda. Türkiye ve Avrupa lokasyonlu sanal sunucularımıza, yüksek performanslı VDS çözümlerimize ve tüm bu ağ tanılamalarını sizin adınıza yapan sunucu yönetimi hizmetimize göz atın. Hızlı, kararlı ve 7/24 izlenen bir barındırma için hosting paketlerimizi inceleyebilir, kesintileri anında görmek için ağ araçlarımızı kullanabilirsiniz.