ping ile Bağlantı Testi ve Paket Kaybı Analizi

Bykomut

Ağ sorunlarını giderirken elimizin altındaki en temel araçlardan biri ping komutudur. Basit görünse de doğru kullanıldığında paket kaybı tespitinden gecikme analizine kadar pek çok kritik bilgiyi bize sunabilir. Bu yazıda ping komutunun derinliklerine ineceğiz, gerçek dünya senaryolarında nasıl kullanacağımızı göreceğiz ve paket kaybı analizini sistematik bir şekilde nasıl yapacağımızı ele alacağız.

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

ping, ICMP (Internet Control Message Protocol) Echo Request paketleri göndererek hedef sistemin erişilebilir olup olmadığını ve yanıt sürelerini ölçen bir araçtır. Hedef sistem ICMP Echo Reply ile yanıt verirse bağlantının çalıştığını anlarsınız. Temel mantık bu kadar basit, ama içinde barındırdığı metrikler çok daha fazla şey anlatır.

Bir ping çıktısında göreceğiniz temel değerler şunlardır:

  • icmp_seq: Paketin sıra numarası, kayıp paketleri tespit etmek için kullanılır
  • ttl: Time To Live değeri, paketin kaç router’dan geçtiğini anlamanıza yardımcı olur
  • time: Round-trip time (RTT), yani paketin gidip gelme süresi milisaniye cinsinden
  • packet loss: Gönderilen paketler arasında yanıt alınamayan oranı

Temel Kullanım ve Parametreler

Linux ve Windows’ta ping komutunun syntax’ı biraz farklıdır. Linux’ta varsayılan olarak sürekli çalışır, Windows’ta ise 4 paket gönderip durur.

# Linux - temel kullanım (Ctrl+C ile durdurun)
ping google.com

# Linux - belirli sayıda paket gönder
ping -c 10 google.com

# Windows - temel kullanım (varsayılan 4 paket)
ping google.com

# Windows - sürekli ping
ping -t google.com

Sık kullandığım parametreler şöyle sıralanabilir:

Linux ping parametreleri:

  • -c [sayı]: Gönderilecek paket sayısını belirler
  • -i [saniye]: Paketler arası bekleme süresi (varsayılan 1 saniye)
  • -s [byte]: Paket boyutunu belirler (varsayılan 56 byte)
  • -t [ttl]: Time To Live değerini ayarlar
  • -W [saniye]: Her paket için bekleme timeout süresi
  • -f: Flood ping, mümkün olduğunca hızlı paket gönderir (root gerektirir)
  • -q: Sessiz mod, sadece özet gösterir
  • -I [arayüz]: Hangi ağ arayüzünden gönderileceğini belirler

Windows ping parametreleri:

  • -n [sayı]: Gönderilecek paket sayısı
  • -t: Sürekli ping
  • -l [byte]: Paket boyutu
  • -i [ttl]: TTL değeri
  • -w [ms]: Timeout milisaniye cinsinden

Paket Kaybı Analizi

Paket kaybı, ağ sorunlarının en önemli göstergelerinden biridir. Ama her paket kaybı aynı anlama gelmez. Önce ne kadar kayıp ciddi bir sorundur, onu netleştirelim:

  • %0-1: Normal, kabul edilebilir
  • %1-5: Hafif sorun, izlenmeli
  • %5-10: Ciddi sorun, müdahale gerekebilir
  • %10 ve üzeri: Kritik, acil müdahale gerekli

Paket kaybını düzgün analiz etmek için yeterince paket göndermeniz gerekir. 4-5 paketle sağlıklı bir sonuç alamazsınız.

# 100 paket göndererek güvenilir istatistik al
ping -c 100 192.168.1.1

# Daha uzun süre izlemek için 500 paket
ping -c 500 -i 0.5 8.8.8.8

# Sadece özet almak için quiet mod (büyük testlerde kullanışlı)
ping -c 200 -q 10.0.0.1

Tipik bir çıktı şöyle görünür:

--- google.com ping statistics ---
100 packets transmitted, 97 received, 3% packet loss, time 99142ms
rtt min/avg/max/mdev = 12.341/15.823/45.234/4.123 ms

Buradaki mdev değerine dikkat edin. Bu, gecikme dalgalanmasını (jitter) gösterir. Yüksek mdev değeri, bağlantının tutarsız olduğuna işaret eder. VoIP veya video konferans kullanan ortamlarda yüksek jitter ses/görüntü kalitesini ciddi şekilde düşürür.

Gerçek Dünya Senaryosu 1: Aralıklı Bağlantı Sorunu

Bir kullanıcı “internet bazen çalışıyor bazen çalışmıyor” şikayetiyle geldi. Bu klasik bir aralıklı bağlantı sorunudur. Böyle durumlarda uzun süreli ping testi şart.

# Timestamp ile uzun süreli ping - Linux
ping -D -c 1000 -i 1 8.8.8.8 | while read line; do echo "$(date '+%Y-%m-%d %H:%M:%S') $line"; done | tee ping_log.txt

# Alternatif olarak ping çıktısını dosyaya kaydet
ping -c 500 192.168.1.1 >> /var/log/ping_test.log 2>&1 &

Bu testi başlatıp birkaç saat bırakabilirsiniz. Log dosyasını incelediğinizde hangi saatlerde kayıp yaşandığını görebilirsiniz. Eğer kayıplar belirli saatlerde yoğunlaşıyorsa (örneğin öğle saatleri), bu bant genişliği tükenmesine işaret edebilir.

Aralıklı kayıpların log dosyasında nasıl göründüğüne bakalım:

64 bytes from 192.168.1.1: icmp_seq=45 ttl=64 time=1.23 ms
64 bytes from 192.168.1.1: icmp_seq=46 ttl=64 time=1.31 ms
Request timeout for icmp_seq 47
Request timeout for icmp_seq 48
64 bytes from 192.168.1.1: icmp_seq=49 ttl=64 time=245.67 ms
64 bytes from 192.168.1.1: icmp_seq=50 ttl=64 time=1.28 ms

Bu çıktı çok şey anlatıyor. Sequence 47 ve 48 kayıp, ardından 49’un 245ms ile gelmesi geçici bir tıkanma (congestion) veya bağlantı kopup gelme yaşandığına işaret eder.

Gerçek Dünya Senaryosu 2: Gateway mi, ISP mi?

Ağda bağlantı sorunu yaşandığında ilk sorulması gereken soru: “Sorun nerede?” Ping testi bu konuda katman katman analiz yapmamıza olanak tanır.

# Adım 1: Loopback testi - ağ stack'i çalışıyor mu?
ping 127.0.0.1

# Adım 2: Kendi IP adresini pingle - ağ kartı çalışıyor mu?
ping 192.168.1.100  # kendi IP'niz

# Adım 3: Default gateway'i pingle - yerel ağ çalışıyor mu?
ping 192.168.1.1

# Adım 4: ISP DNS veya yakın bir noktayı pingle
ping 8.8.8.8

# Adım 5: Alan adı çözümlemesiyle pingle - DNS çalışıyor mu?
ping google.com

Bu adımları sırayla yaparsanız sorunun tam olarak nerede olduğunu tespit edebilirsiniz. Eğer 3. adım başarısız oluyorsa sorun yerel ağdadır (kablo, switch, router). 4. adım başarısız ama 3. başarılıysa sorun ISP tarafındadır. 5. adım başarısız ama 4. başarılıysa DNS sorunudur.

Paket Boyutu ile Test

Bazen standart boyuttaki paketler giderken büyük paketler kaybolur ya da parçalanır. Bu durum MTU (Maximum Transmission Unit) sorunlarına işaret eder. VPN kullanımında bu sorunla sık karşılaşılır.

# Farklı boyutlarda paket testi
ping -c 20 -s 100 8.8.8.8
ping -c 20 -s 500 8.8.8.8
ping -c 20 -s 1000 8.8.8.8
ping -c 20 -s 1400 8.8.8.8
ping -c 20 -s 1472 8.8.8.8

# Fragmentasyon olmadan gönder (DF bit) - MTU tespiti için
ping -c 10 -s 1472 -M do 8.8.8.8

Eğer büyük boyutlu paketlerde kayıp başlıyorsa veya “Frag needed” hatası alıyorsanız, MTU sorunuyla karşı karşıyasınız demektir. Bu genellikle VPN tünellerinde ya da bazı ISP bağlantılarında (özellikle PPPoE) görülür.

# Windows'ta DF bit ile MTU testi
ping -f -l 1472 8.8.8.8

Flood Ping ile Stres Testi

Yerel ağda bir switch veya cihazın kapasitesini test etmek istediğinizde flood ping işe yarar. Ancak bunu üretim ortamında dikkatli kullanın, ağı etkileyebilirsiniz.

# Flood ping - root yetkisi gerekli
sudo ping -f -c 10000 192.168.1.1

# Flood ping ile istatistik
sudo ping -f -c 5000 -q 192.168.1.1

Bu test sırasında switch’in işlemci yükünü, fan sesini ve cevap sürelerini gözlemleyin. Eğer flood ping sırasında ciddi kayıp yaşıyorsanız cihazın donanımsal olarak yetersiz kaldığına işaret edebilir.

Belirli Ağ Arayüzünden Ping Gönderme

Birden fazla ağ arayüzü olan sistemlerde (çift NIC’li sunucular, VPN bağlantıları olan makineler) hangi arayüzden ping gönderdiğinizi kontrol etmek önemlidir.

# Belirli arayüzden ping gönder
ping -I eth0 8.8.8.8
ping -I eth1 192.168.2.1

# VPN arayüzünden test
ping -I tun0 10.8.0.1

# Belirli kaynak IP ile ping
ping -I 10.0.0.50 192.168.1.1

Bu özellikle yük dengeleme (load balancing) kurulumlarında ve failover senaryolarında hayat kurtarır. “Ping çalışıyor” dediğinizde hangi arayüzden gittiğini bilmiyorsanız yanıltıcı sonuçlar alabilirsiniz.

Windows’ta Gelişmiş ping Kullanımı

Windows ortamında da sistematik bir yaklaşım izlemek mümkün.

# Windows - 1000 paket gönder ve dosyaya kaydet
ping -n 1000 8.8.8.8 > C:ping_log.txt

# Windows - büyük paket boyutu ile test
ping -n 50 -l 1400 192.168.1.1

# PowerShell ile ping ve sonuç analizi
$result = Test-Connection -ComputerName 8.8.8.8 -Count 100 -ErrorAction SilentlyContinue
$loss = ($result | Where-Object { $_.StatusCode -ne 0 } | Measure-Object).Count
Write-Host "Paket kaybi: $loss/100"
Write-Host "Ortalama RTT: $(($result | Measure-Object -Property ResponseTime -Average).Average) ms"

PowerShell’in Test-Connection komutu klasik ping’e göre çok daha fazla kontrol ve filtreleme imkanı sunar.

Gerçek Dünya Senaryosu 3: Tek Yönlü Paket Kaybı

Bazen ilginç bir durumla karşılaşılır: karşı taraftan ping atabiliyorsunuz ama o sizden atamazken veya tam tersi. Bu asimetrik routing veya firewall kuralı sorununa işaret eder.

# Karşılıklı ping testi
# Sunucu A'dan Sunucu B'ye:
ping -c 50 10.0.0.20

# Sunucu B'den Sunucu A'ya:
ping -c 50 10.0.0.10

# Sonuçları karşılaştır
# A->B %0 kayıp, B->A %15 kayıp ise routing asimetrisi var demektir

Bu durumda traceroute ile gidiş ve dönüş yollarını ayrı ayrı incelemeniz gerekir. Paket gidiş yolu ile dönüş yolunun farklı router’lardan geçmesi normaldir ama bu yollardan biri sorunluysa tek yönlü kayıp görürsünüz.

Ping Sonuçlarını Otomatik Analiz Etme

Yüzlerce satır ping çıktısını elle incelemek yorucu. Küçük bir script ile işi otomatize edebilirsiniz.

#!/bin/bash
# ping_analiz.sh - Ping sonuçlarini analiz et

HOST=$1
PAKET_SAYISI=${2:-100}

if [ -z "$HOST" ]; then
    echo "Kullanim: $0 <hedef_ip_veya_hostname> [paket_sayisi]"
    exit 1
fi

echo "Test basliyor: $HOST - $PAKET_SAYISI paket"
echo "Baslangic zamani: $(date)"

SONUC=$(ping -c $PAKET_SAYISI -q $HOST 2>&1)

if [ $? -ne 0 ]; then
    echo "HATA: $HOST'a ulasılamadi!"
    exit 2
fi

KAYIP=$(echo "$SONUC" | grep -oP 'd+(?=% packet loss)')
MIN_RTT=$(echo "$SONUC" | grep -oP 'rtt.*= K[d.]+')
AVG_RTT=$(echo "$SONUC" | grep -oP 'rtt.*= [d.]+/K[d.]+')
MAX_RTT=$(echo "$SONUC" | grep -oP 'rtt.*= [d.]+/[d.]+/K[d.]+')
MDEV=$(echo "$SONUC" | grep -oP 'rtt.*= [d.]+/[d.]+/[d.]+/K[d.]+')

echo "=== SONUCLAR ==="
echo "Paket Kaybi   : %$KAYIP"
echo "Min RTT       : ${MIN_RTT}ms"
echo "Ortalama RTT  : ${AVG_RTT}ms"
echo "Max RTT       : ${MAX_RTT}ms"
echo "Jitter (mdev) : ${MDEV}ms"

# Degerlendir
if [ "$KAYIP" -eq 0 ]; then
    echo "Durum: MUKEMMEL - Kayip yok"
elif [ "$KAYIP" -le 1 ]; then
    echo "Durum: IYI - Minimal kayip"
elif [ "$KAYIP" -le 5 ]; then
    echo "Durum: DIKKAT - Kayip var, izlenmeli"
else
    echo "Durum: KRITIK - Acil mudahale gerekli!"
fi

Bu script’i çalıştırmak için:

chmod +x ping_analiz.sh
./ping_analiz.sh 8.8.8.8 200
./ping_analiz.sh web-sunucusu 500

Sürekli İzleme için ping ile Basit Monitoring

Cron ile periyodik ping testi yaparak proaktif monitoring kurabilirsiniz.

#!/bin/bash
# /usr/local/bin/ping_monitor.sh
# Cron: */5 * * * * /usr/local/bin/ping_monitor.sh

HEDEFLER=("8.8.8.8" "192.168.1.1" "web-sunucusu.local")
LOG_DOSYA="/var/log/ping_monitor.log"
ESIK=5  # Yuzde kac kayiptan sonra uyari verilsin

for HEDEF in "${HEDEFLER[@]}"; do
    SONUC=$(ping -c 20 -q -W 2 $HEDEF 2>&1)
    KAYIP=$(echo "$SONUC" | grep -oP 'd+(?=% packet loss)' || echo "100")
    ZAMAN=$(date '+%Y-%m-%d %H:%M:%S')

    echo "[$ZAMAN] $HEDEF - Kayip: %$KAYIP" >> $LOG_DOSYA

    if [ "$KAYIP" -gt "$ESIK" ]; then
        echo "UYARI: $HEDEF adresinde %$KAYIP paket kaybi!" | 
        mail -s "Ping Alarmi: $HEDEF" [email protected]
    fi
done

ICMP Engellendiğinde Ne Yaparsınız?

Bazı sistemler veya firewall’lar ICMP paketlerini engeller. Bu durumda ping yanıt vermez ama bu sistem kapalı anlamına gelmez. Bunu ayırt etmek önemlidir.

Ping’e yanıt vermeyen bir host için şunları yapabilirsiniz:

  • traceroute veya tracert ile son hop’u inceleyin, host’a kadar ulaşılıyorsa ICMP engeli vardır
  • nmap ile port taraması yapın, açık portlar varsa sistem çalışıyordur
  • curl veya wget ile HTTP/HTTPS bağlantısı deneyin
  • telnet veya nc ile belirli bir port’a bağlanmayı deneyin
  • Windows’ta ping‘e yanıt vermemesi için Advanced Firewall’daki “File and Printer Sharing (Echo Request)” kuralının kapalı olabileceğini unutmayın

ping Çıktısındaki TTL Değerini Okumak

TTL değeri ilginç bilgiler içerir. Varsayılan TTL değerleri işletim sistemine göre değişir:

  • Linux: Varsayılan TTL 64
  • Windows: Varsayılan TTL 128
  • Cisco/Network ekipmanları: Genellikle TTL 255

Aldığınız TTL değeri, hedefteki başlangıç TTL’sinden geçilen router sayısının çıkarılmasıyla oluşur. Örneğin TTL=56 geldiyse ve hedef Linux ise (64), aradaki 8 router var demektir. Bu sayede ağ topolojisi hakkında fikir edinebilirsiniz.

Sonuç

ping komutu, göründüğünden çok daha güçlü bir tanı aracıdır. Doğru parametrelerle kullanıldığında ve sonuçları sistematik bir şekilde yorumlandığında size şu soruların cevabını verebilir:

  • Bağlantı kesintisi nerede yaşanıyor?
  • Sorun kalıcı mı, aralıklı mı?
  • Gecikme değerleri normal mi?
  • MTU sorunları var mı?
  • Yük altında ağ nasıl davranıyor?

Ağ sorunlarını giderirken her zaman ping‘i ilk adım olarak kullanın ve sonuçları katmanlı olarak yorumlayın. Gateway’den başlayıp dışarıya doğru ilerleyin. Paket kaybının yüzdesine bakın ama jitter değerini de göz ardı etmeyin. Log tutun, çünkü aralıklı sorunlar tam test anında kendini göstermeyebilir.

Son olarak şunu vurgulayalım: ping cevap vermiyorsa bu her zaman sorun anlamına gelmez. Karşı taraf ICMP engelliyor olabilir. Ama hem ping çalışıyor hem de servis çalışmıyorsa sorun uygulama katmanındadır, ağ değil. Bu ayrımı yapmak, gereksiz ağ incelemelerine zaman harcamanızı önler ve sizi doğru yöne yönlendirir.

Benzer Konular

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir