ICMP Nedir? Ping, TTL ve Tracert Komutu

Bir kargo gönderdiğinizde asıl merak ettiğiniz şey kolinin içi değildir. Yola çıktı mı, hangi aktarma merkezinde, teslim edildi mi, edilmediyse neden. Kargo firması bunun için ayrı bir kanal işletir: kolinin kendisi bir yerde yolculuk ederken, size gelen kısa bildirimler o yolculuğun durumunu anlatır. Bildirimin içinde ürün yoktur, ürün hakkında haber vardır.

ICMP tam olarak bu bildirim kanalıdır. Ağda taşınan asıl veri IP paketlerinin içinde gider; ICMP ise o paketlerin başına ne geldiğini söyler. Teslim edilemedi, süresi doldu, adres bulunamadı, koli kapıdan geçmiyor.

Bu makale, sistem yöneticilerinin her gün kullandığı ama çoğu zaman yüzeyini okuduğu bir protokolü açıyor. ping yazdığınızda gerçekte ne gönderiliyor, tracert bir yolu nasıl çıkarıyor, ve ekranda beliren dört farklı hata mesajı neden dört farklı hikâye anlatıyor. Anlatılan her ölçüm bu makale için laboratuvarda üretildi; ham çıktılar olduğu gibi duruyor.

Elinizde şu an çözmeniz gereken bir arıza varsa ve ekranda bir hata mesajı duruyorsa, doğrudan ping hatalarının ayrıldığı bölüme atlayabilirsiniz.

Bu makale Kurumsal Network Kurulumu ana hizmetinin teşhis ve sorun giderme koluna odaklanır.

ICMP Nedir? IP’nin Hata Bildirim Protokolü

ICMP (Internet Control Message Protocol), IP ağında paketlerin başına gelenleri bildiren kontrol protokolüdür. Türkçesi İnternet Kontrol Mesaj Protokolü’dür ve adındaki üç kelime işini tam olarak tarif eder: internet üzerinde, kontrol amaçlı, mesaj taşır. Veri taşımaz.

Ayrımı kargo örneğine oturtalım. Sipariş ettiğiniz ürün kolinin içindedir ve o koli IP paketidir. Kargo firmasının size gönderdiği “gönderiniz aktarma merkezine ulaştı” bildirimi ise ICMP mesajıdır. Bildirimin içinde ürün yoktur; bildirim ürün hakkındadır.

Bu ayrım pratik bir sonuç doğurur. ICMP’yi kapattığınızda veri akmaya devam eder, ama ne olup bittiğini öğrenme kanalı kapanır. Koliler yola çıkar, bazıları ulaşır bazıları ulaşmaz, ve siz hiçbir bildirim almazsınız. Makalenin ilerleyen bölümlerinde bunun ölçülebilir bedelini göreceğiz.

ICMP, ağ protokolleri ailesinin en eski üyelerinden biridir ve RFC 792 belgesiyle 1981 yılında tanımlanmıştır. Kırk yılı aşkın süredir neredeyse değişmeden çalışıyor olması bir tesadüf değil: yaptığı iş, taşıdığı veriden bağımsız olarak her ağda aynı.

ICMP’nin Portu Neden Yoktur?

ICMP’nin port numarası yoktur ve bu bir eksiklik değil, tanımın doğrudan sonucudur. Bu soru sahada ve arama motorlarında sık sorulur, çünkü güvenlik duvarı kuralı yazan herkes önce portu arar.

Port numarası TCP ve UDP başlıklarında bulunur. Bu iki protokolün işi, gelen veriyi bir makinedeki belirli bir uygulamaya teslim etmektir: 443 numaralı kapıdan giren web sunucusuna, 22 numaralı kapıdan giren SSH servisine gider. Port, binanın içindeki daire numarasıdır.

ICMP ise hiçbir uygulamaya teslimat yapmaz. Muhatabı işletim sisteminin ağ katmanıdır, yani binanın kendisidir. Kargo bildirimi size gelir, kolinin içindeki ürünü sipariş eden departmana değil.

Bunun günlük karşılığı şudur: güvenlik duvarında ICMP kuralı yazarken port seçemezsiniz, mesaj tipi seçersiniz. “8 numaralı tipe izin ver, 13 numaralı tipi engelle” dersiniz. Mesaj tiplerinin ne olduğunu birazdan tek tek göreceğiz.

ICMP Neden IP’nin İçinde Taşınır Ama Bir Taşıma Protokolü Değildir?

ICMP mesajları IP paketlerinin içine konarak taşınır, ama ICMP bir taşıma protokolü değildir. Bu cümle ilk okunduğunda çelişkili görünür ve tam da bu yüzden yazılması gerekir.

Mekanizma şöyle işler. Bir ICMP mesajı üretildiğinde, tıpkı herhangi bir veri gibi bir IP paketinin yük kısmına yerleştirilir ve IP başlığındaki protokol alanına 1 yazılır. Alıcı makine paketi açtığında bu numarayı görür ve içeriği bir uygulamaya değil, kendi ağ yığınına verir.

Peki neden taşıma protokolü sayılmıyor? Çünkü taşıma protokolünün tanımı iki uçtaki uygulamalar arasında veri taşımaktır. TCP bir web tarayıcısıyla web sunucusunu konuşturur; UDP bir DNS istemcisiyle DNS sunucusunu. ICMP’nin böyle bir müşterisi yoktur. Ağın kendisi hakkında, ağın kendisine konuşur.

Kargo örneğinde karşılığı nettir: bildirim SMS’i de aynı telefon hattı üzerinden gelir, ama SMS’i gönderen kargo firmasının bilgi işlem sistemidir, gönderiyi bekleyen müşteri değil. Aynı hat, farklı muhatap.

Sorulması gereken soru: ICMP mesajı IP paketiyle taşınıyorsa ve o IP paketi de yolda kaybolabiliyorsa, hata bildiriminin kendisi kaybolduğunda ne olur? Cevap rahatsız edicidir: hiçbir şey olmaz. ICMP’nin teslim garantisi yoktur. Kaybolan bir hata mesajı yeniden gönderilmez, kimse onu beklemez. Bu yüzden ICMP’den gelen sessizlik bir bilgi değildir, bilginin yokluğudur. Makale boyunca en çok işimize yarayacak cümle budur.

Ping Nasıl Atılır? Echo Request ve Echo Reply Çifti

ping komutu hedefe bir ICMP echo request mesajı gönderir ve karşılığında echo reply bekler. Komutu her gün kullanan çoğu kişi bu iki mesajın adını hiç duymamıştır, oysa ping’in yaptığı işin tamamı bu çiftten ibarettir.

Windows’ta ping atmak için komut istemine hedefin adresini yazmanız yeterlidir:

ping 192.168.1.15

Laboratuvarda bu komutu Ubuntu çalışan bir sunucuya karşı çalıştırdığımızda dönen cevap şu:

Pinging 192.168.1.15 with 32 bytes of data:
Reply from 192.168.1.15: bytes=32 time<1ms TTL=64
Reply from 192.168.1.15: bytes=32 time<1ms TTL=64
Reply from 192.168.1.15: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.1.15:
    Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),

Bu çıktıda dört bilgi var ve dördü de ayrı şey söylüyor:

1. Reply from 192.168.1.15: cevap gerçekten hedefin adresinden geldi. Bu satırdaki adresin sorduğunuz adres olup olmadığı, makalenin ilerleyen bölümünde teşhisin ana anahtarı olacak.
2. bytes=32: gönderilen yükün boyutu. Windows varsayılan olarak 32 bayt anlamsız veri koyar; bu veri hiçbir işe yaramaz, sadece paketi doldurur.
3. time<1ms: isteğin gidip cevabın dönmesi arasında geçen süre. Aynı yerel ağdaki iki makine arasında bir milisaniyenin altındadır.
4. TTL=64: cevabın taşıdığı yaşam süresi sayacı. Bu değer hem yolun uzunluğu hem karşıdaki işletim sistemi hakkında ipucu verir ve kendi bölümünde ele alınacak.

Aynı anda sunucu tarafında paket yakalaması aldığımızda ağda görünen tam olarak şudur:

IP 192.168.1.224 > 192.168.1.15: ICMP echo request, id 1, seq 914, length 40
IP 192.168.1.15 > 192.168.1.224: ICMP echo reply, id 1, seq 914, length 40

Bir istek, bir cevap. seq alanı sıra numarasıdır ve her ping’de bir artar; id alanı ise aynı anda çalışan farklı ping komutlarının cevaplarını karıştırmamak içindir.

Ping’in Adı Nereden Geliyor?

Komutun adı sonardan gelir. 1983’te Mike Muuss bu aracı yazarken, denizaltı sonarının su altına bir ses darbesi gönderip yankısını dinlemesinden esinlendi ve programa ping adını verdi. Mekanizma gerçekten aynıdır: bir sinyal gönderirsiniz, geri dönmesini beklersiniz, dönüş süresinden mesafe hakkında fikir edinirsiniz.

Bu köken bir ayrıntı gibi görünür ama bir yanlış anlamayı da açıklar. Türkiye’de ping kelimesi çoğunlukla oyun gecikmesi veya internet hızı bağlamında kullanılır; oysa aracın kendisi bir hız ölçer değil, bir varlık yoklamasıdır. Gecikme süresi yan üründür.

Ping Cevap Veriyor: Bu Tam Olarak Neyi Kanıtlar?

Başarılı bir ping, hedef makinenin ağ yığınının ayakta olduğunu ve iki yönlü bir yolun bulunduğunu kanıtlar. Üzerinde çalışan hiçbir servis hakkında bilgi vermez. Sahada en pahalı yanılgılardan biri bu cümlenin ikinci yarısının atlanmasıdır.

Kargo örneği burada tam oturur: bildirim size kolinin binaya teslim edildiğini söyler. İçindeki ürünün sağlam olup olmadığını, doğru departmana ulaşıp ulaşmadığını, hatta kutunun açılıp açılmadığını söylemez. Teslim onayı bir kapı onayıdır, içerik onayı değil.

Ping cevap verirken çalışmayan bir sistemin listesi uzundur:

• Web sunucusu servisi durmuştur, makine ayaktadır
• Veritabanı bağlantı havuzu dolmuştur, makine cevap vermeye devam eder
• İlgili port güvenlik duvarında kapalıdır, ICMP açıktır
• Uygulama çalışıyordur ama yanlış yapılandırmayla hata döndürüyordur

Bu ayrımın ölçülmüş hâli ve servis seviyesinde nasıl test edileceği port ve bağlantı arızası tespiti makalesinde duruyor; orada ping başarılıyken servis testinin başarısız olduğu bir çıktı yan yana gösteriliyor.

Ters yönü de aynı derecede önemlidir: ping cevap vermiyor olması makinenin kapalı olduğunu kanıtlamaz. Bugün pek çok sunucu ve iş istasyonu, güvenlik politikası gereği echo request’e hiç cevap vermez. Windows’un varsayılan güvenlik duvarı da bunlardan biridir.

Ping’in Cevap Verme Düzeni de Bir Bilgidir

Tek bir ping’in sonucu kadar, arka arkaya atılan pinglerin ritmi de teşhis taşır: düzensiz aralıklarla gelip kesilen cevaplar çoğu zaman kapalı bir cihazı değil, sürekli yeniden başlayan bir cihazı gösterir. Bu bilgi cevabın içeriğinde değil, cevapların arasındaki boşluktadır.

Kargo bildirimlerine dönelim. Bir gönderi için arka arkaya “işleme alındı, işleme alındı, işleme alındı” bildirimleri geliyorsa, sistem çalışıyor demektir; ama gönderi ilerlemiyor demektir. Bildirimin varlığı iyi haber, tekrarı kötü haberdir. Ping’de de böyledir: cevabın gelmesi cihazın ayakta olduğunu söyler, cevapların kesilip kesilip geri gelmesi ise cihazın aynı noktaya sürekli döndüğünü söyler.

Bu vakanın öğrettiği şey teşhis sırasını değiştiriyor: ping’i bir kez atıp “cevap veriyor” demek yetmez. Cevabın düzenli mi düzensiz mi geldiği, aynı hedefe kaç saniyede bir ulaşıldığı ve ping ayaktayken üst katman servislerinin de ayakta olup olmadığı ayrı ayrı okunur. Bir cihazın ağ yığını, yönetim arayüzünden çok daha erken açılır; arada kalan pencerede ping cevap verir ve cihaz hâlâ kullanılamaz durumdadır.

Ping Sustuğunda: Dört Mesaj, Dört Farklı Hikâye

Ping başarısız olduğunda ekrana yazılan mesaj rastgele bir hata metni değildir; her biri sorunun hangi katmanda olduğunu söyler. Bu bölüm makalenin merkezidir, çünkü bu dört mesajı ayırt edebilen bir kişiyle ayırt edemeyen bir kişi arasındaki fark saatlerle ölçülür.

Dört senaryoyu aynı laboratuvarda, aynı hedefe karşı üretip yan yana koyduk. Sonuçları önce tablo olarak veriyorum, ardından her birini tek tek açacağız.

Son iki satırdaki kalın vurgular tesadüf değil. Bu iki mesaj hedef hakkında hiçbir şey söylemez, ve bunu bilmemek insanın saatlerini yanlış yerde aratır.

Request Timed Out: Sessizlik Bilgi Değildir

Request timed out hiçbir cevabın gelmediği anlamına gelir, başka bir şey değil. En sık görülen ve en az bilgi taşıyan mesaj budur.

Laboratuvarda bu durumu üretmek için sunucudaki güvenlik duvarına echo request’i sessizce düşüren bir kural koyduk:

sudo iptables -I INPUT 1 -p icmp --icmp-type echo-request -j DROP

Windows tarafında dört ping attık ve dördü de aynı satırı verdi:

Pinging 192.168.1.15 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Aynı anda sunucu tarafında yakalanan trafik ise şuydu:

IP 192.168.1.224 > 192.168.1.15: ICMP echo request, id 1, seq 881, length 40
IP 192.168.1.224 > 192.168.1.15: ICMP echo request, id 1, seq 882, length 40
IP 192.168.1.224 > 192.168.1.15: ICMP echo request, id 1, seq 883, length 40
IP 192.168.1.224 > 192.168.1.15: ICMP echo request, id 1, seq 884, length 40

Bu iki çıktıyı birlikte okumak öğreticidir:

1. Dört istek gerçekten gitti ve hedefe ulaştı. Yakalama sunucunun kendi arayüzünde alındı, yani paketler oraya vardı.
2. Sıfır cevap döndü. Hedef paketi aldı, baktı ve çöpe attı. Gönderene tek kelime söylemedi.
3. Gönderen taraf bu iki durumu ayırt edemez. Paketin hiç ulaşmaması ile ulaşıp sessizce atılması, ekranda tamamen aynı satırı üretir.

Bu sırada bir şey daha ölçtük ve sonucu ayrı bir kapı açıyor: ping tamamen susarken makinenin ARP kaydı hâlâ yerindeydi.

Interface: 192.168.1.224
  Internet Address      Physical Address      Type
  192.168.1.15          00-0c-29-a0-71-9a     dynamic

Yani ikinci katman sağlıklı çalışıyor, iki makine birbirinin donanım adresini biliyor, ve buna rağmen ping sessiz. Bu ayrımın neden teşhisin ilk adımı olduğu ve ARP tablosunun nasıl okunacağı ARP ve MAC adresi makalesinde ölçümlerle anlatılıyor.

Destination Net Unreachable: Reddetmek ile Yok Saymak Farklıdır

Bu mesaj bir cevabın geldiğini gösterir: karşı taraf paketi kabul etmediğini açıkça bildirmiştir. Aynı güvenlik duvarı, aynı hedef, tek farkla: kuralı sessizce düşürmek yerine reddetmeye çevirdik.

sudo iptables -I INPUT 1 -p icmp --icmp-type echo-request -j REJECT --reject-with icmp-admin-prohibited

Ekranda görünen değişti:

Reply from 192.168.1.15: Destination net unreachable.

Ağda görünen ise şuydu:

IP 192.168.1.224 > 192.168.1.15: ICMP echo request, id 1, seq 880, length 40
IP 192.168.1.15 > 192.168.1.224: ICMP host 192.168.1.15 unreachable - admin prohibited filter, length 68

Burada dikkat edilecek üç nokta var:

1. Mesajın ağdaki adı ile ekrandaki adı aynı değil. Yakalama aracı ona admin prohibited filter diyor, yani “yönetici yasakladı”; Windows ping ise bunu Destination net unreachable diye özetliyor. İki farklı isim, tek paket. Ekrandaki metin ham gerçeğin bir çevirisidir ve çeviri her zaman sadık değildir.
2. Cevabın uzunluğu 68 bayt, oysa istek 40 baytdı. ICMP hata mesajları, hangi pakete ait olduklarını göstermek için o paketin başlığından bir parça geri taşır. Hata mesajı, hatayı doğuran şeyin kimliğini yanında getirir.
3. Reply from ifadesi burada da geçiyor ama gelen şey bir echo reply değil. Ping komutu, aldığı her ICMP cevabını bu kalıpla yazar; kelimenin varlığı işlerin yolunda olduğu anlamına gelmez.

Bu ikisini yan yana koyduğumuzda ortaya çıkan ayrım şudur: DROP ile REJECT arasındaki fark güvenlik duvarında tek kelimedir, ama teşhis eden kişi için gece ile gündüz farkıdır. Reddeden bir sistem size bir sınır olduğunu söyler; sessizce düşüren sistem sizi belirsizlikte bırakır. Bu, güvenlik duvarı politikası yazarken bilinçli verilmesi gereken bir karardır ve firewall kurulumu tarafında ayrıca ele alınıyor.

İlk Ping Neden Sık Sık Timeout Verir?

Art arda atılan pinglerde ilkinin Request timed out verip sonrakilerin düzgün çalışması, çoğu zaman bir arıza değil ARP’ın izidir. Ölçümlerimizde de tam olarak bu oldu: reddetme kuralı aktifken iki ping attık, ilki timeout verdi, ikincisi Destination net unreachable döndü.

Sebep, ping’in gönderilebilmesi için önce hedefin donanım adresinin bilinmesi gerektiğidir. Makine o adresi bilmiyorsa ARP ile sorar, ve beklerken elindeki ICMP paketini kuyruğa almaz, siler. Yani ilk echo request ağa hiç çıkmaz; ARP cevabı geldikten sonra ancak ikinci ping bir paket üretebilir.

Bunun kanıtı bizim kendi yakalamamızda duruyor: iki ping attık, ağda tek bir echo request göründü. Kayıp olan paket düşürülmedi, hiç oluşturulmadı.

Pratik sonucu şudur: bir hedefi ilk kez pinglediğinizde çıkan tek satırlık timeout’a bakıp hüküm vermeyin. Teşhis için anlamlı olan, ARP çözüldükten sonraki pinglerdir. Aynı sebeple, uzun süre konuşulmamış bir hedefte önbellek kaydı tazeliğini yitirmişse ilk paket yine gecikebilir. ARP kayıtlarının ne zaman tazelendiği ve hangi durumda olduğu ARP önbelleği ve durumları makalesinde ele alınıyor.

Destination Host Unreachable: Cevap Var, Ama Kimden?

Bu mesaj bir cevabın geldiğini gösterir, ancak cevabı çoğu zaman hedef değil kendi makineniz üretir. Ayrımı yakalayan kişi teşhiste bir kat aşağı iner.

Laboratuvarda kimsenin kullanmadığı bir adrese ping attık:

Pinging 192.168.1.250 with 32 bytes of data:
Request timed out.
Reply from 192.168.1.224: Destination host unreachable.

İkinci satırdaki adrese bakın: 192.168.1.224. Bu, ping’i atan makinenin kendi adresidir. Yani “hedefe ulaşılamıyor” diyen taraf hedef değil, sizin bilgisayarınızdır.

Mekanizma şöyle işler: aynı yerel ağdaki bir adrese paket gönderebilmek için makinenin önce o adresin donanım karşılığını öğrenmesi gerekir. Bunu ARP ile sorar. Kimse cevap vermezse çerçeveyi kime göndereceğini bilemez ve paketi hiç yollayamaz. Bu durumda kendi ağ yığını, ping komutuna bir ICMP mesajı üretip “bu hedefe ulaşamıyorum” der.

Dolayısıyla mesajın anlamı şudur: hedefe giden yol bulunamadı. Hedefin kapalı olduğu, açık olduğu, hatta var olduğu bile iddia edilmiyor.

Aynı mesaj bir router’dan da gelebilir. O zaman gelen adres kendi makineniz değil, yolun üzerindeki bir cihaz olur ve anlamı değişir: “ben bu paketi bir sonraki adıma teslim edemedim.” İki durumu ayıran tek şey, Reply from satırındaki adrestir.

Teşhis kuralı olarak yazalım: bu mesajı gördüğünüzde önce metni değil adresi okuyun. Kendi adresinizse sorun yerel ağdadır ve ARP tablosuna bakılır; başka bir adresse sorun o cihazın ötesindedir ve yönlendirme tablosuna bakılır.

General Failure: Paket Hiç Çıkmadı

PING: transmit failed. General failure. bir ICMP mesajı değildir ve karşı taraf hakkında hiçbir şey söylemez. Bu bölümdeki diğer üç mesaj ağdan gelen bir cevaptı; bu ise makinenin kendi içinden gelen bir arıza bildirimidir.

Anlamı tek cümleyle şudur: yerel ağ yığını bu paketi ağa veremedi. Sebep geçerli bir kaynak adresin bulunamaması, hedefe giden bir rotanın olmaması ya da ağ kartının devre dışı olması olabilir. Ortak nokta, paketin makineden hiç çıkmamış olmasıdır.

Bunu ölçmek için, aynı yakalama penceresinde önce normal bir ping attık, ardından makinede bulunmayan bir kaynak adresle ping attık:

ping -S 10.99.99.99 192.168.1.15

Ekranda görünen:

Pinging 192.168.1.15 from 10.99.99.99 with 32 bytes of data:
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.

Ağda görünen ise yalnızca kontrol grubuna ait satırlardı:

IP 192.168.1.224 > 192.168.1.15: ICMP echo request, id 1, seq 914, length 40
IP 192.168.1.15 > 192.168.1.224: ICMP echo reply, id 1, seq 914, length 40
IP 192.168.1.224 > 192.168.1.15: ICMP echo request, id 1, seq 915, length 40
IP 192.168.1.15 > 192.168.1.224: ICMP echo reply, id 1, seq 915, length 40

Okuma anahtarı iki maddedir:

1. Kontrol grubu yakalandı. Normal pinglere ait dört satır ağda görünüyor, yani yakalama düzgün çalışıyordu ve ölçüm aracı sağlamdı.
2. Test grubu hiç görünmedi. Ekranda üç hata satırı varken ağda o üç denemeye ait tek bir çerçeve bile yok.

Sonuç: ekranınızda üç satır hata var ve ağda sıfır paket. Karşı tarafın bundan haberi bile olmadı.

Bu vakadan çıkan kural, protokolü tanımanın neden saha deneyiminin yerine geçmediği ama onu yönlendirdiğidir: saha deneyimi protokol bilgisini pekiştirir; protokol bilgisi olmadan biriken deneyim ise sezgiye dönüşür. Sezgi çoğu zaman doğru yeri gösterir, ama yanıldığında nerede yanıldığını söylemez.

TTL Nedir? Paketin Ömrü ve Sonsuz Döngü Sigortası

TTL (Time To Live), bir IP paketinin kaç yönlendiriciden geçebileceğini belirleyen sayaçtır. Adı “yaşam süresi” anlamına gelse de ölçtüğü şey zaman değil, adım sayısıdır.

Mekanizma sade ve acımasızdır:

1. Paketi üreten makine TTL alanına bir başlangıç değeri yazar. Linux ve modern Windows sistemlerde bu genellikle 64 veya 128’dir.
2. Paket bir yönlendiriciden her geçtiğinde o yönlendirici değeri bir azaltır.
3. Değer sıfıra düşerse yönlendirici paketi atar ve gönderene bir ICMP time exceeded mesajı yollar.

Neden var olduğu, olmasaydı ne kırılırdı sorusuyla anlaşılır. Yönlendirme tabloları yanlış yapılandırıldığında iki cihaz aynı paketi birbirine sonsuza kadar gönderebilir: A der ki “bu B’ye gider”, B der ki “bu A’ya gider”. TTL olmasaydı o paket ağda ölümsüz olarak dönerdi ve her döngüde bant genişliği yerdi. Yeterince yanlış rota birikince ağ kendi kuyruğunu yiyerek çökerdi.

Kargo örneğinde karşılığı, kolinin üzerindeki aktarma merkezi sayacıdır: her merkez bir kaşe basar, kaşe sayısı sınırı aşarsa koli daha fazla dolaştırılmaz, geri bildirim verilerek işlemden çıkarılır.

TTL Değeri Karşı Taraf Hakkında Ne Söyler?

Ping çıktısındaki TTL=64 değeri, cevabı üreten sistem hakkında ipucu taşır. Sistemler farklı başlangıç değerleri kullanır: Linux ve Unix türevleri genellikle 64, Windows 128, bazı ağ cihazları 255 ile başlar.

Cevapta gördüğünüz sayı, başlangıç değerinden yolda geçilen yönlendirici sayısı kadar eksiktir. Laboratuvar ölçümümüzde Ubuntu sunucudan dönen cevap TTL=64 taşıyordu; aradan hiçbir yönlendirici geçmediği için değer başlangıç hâlindeydi. Aynı sunucu bir yönlendiricinin arkasında olsaydı 63 görürdük.

Bu bir teşhis aracıdır ama kesin kanıt değildir: başlangıç değerleri yapılandırmayla değiştirilebilir. Yön gösterir, hüküm vermez.

Tracert Komutu Nasıl Çalışır? TTL’i Artırarak Yol Çıkarma

tracert komutu, TTL sayacını kasıtlı olarak düşük tutup her adımda bir artırarak yolun üzerindeki cihazları tek tek ortaya çıkarır. Yaptığı iş bir hile gibi görünür ve gerçekten öyledir: protokolün hata mekanizmasını bir keşif aracına çevirir.

Windows’ta komut tracert, Linux ve macOS’ta traceroute adını taşır. İşleyiş aynıdır ve TTL bölümünde anlattığımız mekanizmanın doğrudan sonucudur:

1. İlk paket TTL değeri 1 ile gönderilir. İlk yönlendirici bunu bir azaltır, sıfır olur, paketi atar ve geriye bir time exceeded mesajı yollar. Böylece birinci adımın adresi öğrenilmiş olur.
2. İkinci paket TTL 2 ile gönderilir. Birinci yönlendiriciyi geçer, ikincide sıfırlanır ve bu kez ikinci cihaz kendini ele verir.
3. Bu, hedefe ulaşılana kadar sürer. Hedef, süresi dolmuş bir paket yerine normal bir cevap döndüğünde yolculuk biter.

Yani tracert, yolu haritadan okumaz; her adımda kasıtlı olarak bir paketi öldürüp cenaze bildiriminin nereden geldiğine bakar.

Bu mekanizmayı doğrudan görmek için tracert kullanmadan, ping komutunun TTL parametresiyle elle yaptık. Her satırda TTL’i bir artırdık:

ping -i 1 8.8.8.8
ping -i 2 8.8.8.8
ping -i 3 8.8.8.8

Sonuç:

TTL=1  ->  Reply from 192.168.1.1: TTL expired in transit.
TTL=2  ->  Reply from 172.17.1.126: TTL expired in transit.
TTL=3  ->  Reply from 10.170.8.113: TTL expired in transit.
TTL=4  ->  Reply from 10.170.8.114: TTL expired in transit.
TTL=5  ->  Reply from 10.170.8.109: TTL expired in transit.

Beş satır, beş farklı adres, ve hepsi aynı hata mesajını taşıyor. Bu çıktı tracert’in ürettiği listenin ta kendisidir; aradaki tek fark, komutun bunu otomatik yapması ve süreleri de ölçmesidir.

Aynı hedefe tracert çalıştırdığımızda beklendiği gibi aynı yol çıktı:

  1     2 ms     5 ms     1 ms  192.168.1.1
  2     3 ms     3 ms     6 ms  172.17.1.126
  3     6 ms     4 ms     4 ms  10.170.8.113
  4     4 ms     3 ms     3 ms  10.170.8.114
  5     4 ms     *        *     10.170.8.109
  6    14 ms    15 ms    13 ms  72.14.210.191

Tracert Çıktısındaki Yıldızlar Ne Anlama Gelir?

Yıldız işareti kopukluk değil, cevapsızlık anlamına gelir ve ikisi aynı şey değildir. Yukarıdaki çıktının beşinci satırı bunun canlı örneği: aynı ölçüm turunda 10.170.8.109 adresli cihaz, tracert’in üç denemesinden ikisine yıldız verdi.

Oysa aynı cihaz, birkaç saniye önce elle yaptığımız TTL merdiveninde sorunsuz cevap vermişti. Yani cihaz ayaktaydı, yol açıktı, paketler geçiyordu.

Sebep şudur: bir yönlendiricinin asıl işi paket iletmektir, hata mesajı üretmek değil. Bu yüzden pek çok cihaz ICMP hata üretimini hız sınırına tabi tutar, bazıları da güvenlik politikası gereği hiç üretmez. Tracert her adım için üç paket birden gönderdiğinden, sınıra takılan denemeler cevapsız kalır ve ekrana yıldız düşer. Bunu doğrulamak kolaydır ve biz de öyle yaptık: yıldız veren adıma elle tek bir TTL paketi gönderdiğinizde cevap gelir.

Yıldızın gerçekten sorun işareti olduğu tek durum şudur: o noktadan sonraki bütün adımların da cevapsız kalması ve hedefe hiç ulaşılamaması. Ortada tek tük yıldız görmek normaldir ve pek çok kişinin sandığının aksine teşhis değeri düşüktür.

MTU ve Paket Boyutu: ICMP Kapatılınca Sessizce Kırılan Şey

Her ağ bağlantısının taşıyabileceği en büyük paket boyutu vardır ve bu sınıra MTU (Maximum Transmission Unit) denir. Ethernet ağlarında bu değer tipik olarak 1500 bayttır. Bu bölüm ICMP’yi kapatmanın bedelini somutlaştırdığı için makalenin en pratik sonucunu taşıyor.

Sorun şurada doğar: bir paket, yolun herhangi bir noktasındaki MTU’dan büyükse o adımı geçemez. İki çözüm vardır. Ya paket parçalanır, ya da gönderene “bu boyut geçmiyor, küçült” denir. İkinci mesajı taşıyan şey ICMP’dir.

Laboratuvarda bunu ölçmek için, parçalanmayı yasaklayan bayrağı açıp MTU sınırının bir bayt üstünde bir paket gönderdik:

ping -f -l 1473 192.168.1.15

Packet needs to be fragmented but DF set.

Aynı boyuttaki paketi, parçalanma yasağı olmadan gönderdiğimizde ise sorunsuz geçti:

Reply from 192.168.1.15: bytes=1473 time<1ms TTL=64

İki çıktının farkı tek bir bayrakta: -f parametresi paketin parçalanmasını yasaklıyor. Yasak olduğunda sistem paketi geçiremeyeceğini fark ediyor ve bunu bildiriyor.

Şimdi asıl mesele. Modern sistemler bu bildirimi otomatik olarak kullanır: büyük bir paket gönderirler, yoldan “geçmiyor, en fazla şu kadar” mesajı gelirse boyutu düşürüp yeniden denerler. Bu pazarlığın adı PMTUD (Path MTU Discovery) yani yol boyunca izin verilen en büyük paket boyutunun keşfidir ve RFC 1191 ile tanımlanmıştır.

Peki bu mesajı taşıyan ICMP, güvenlik duvarında tamamen kapatılmışsa ne olur? Cevap, ICMP’yi kapatmayı savunan yaklaşımın en zayıf noktasıdır:

• Bağlantı kurulur, çünkü el sıkışma paketleri küçüktür ve rahatça geçer
• Küçük veri akar, sorun görünmez
• Büyük paketler sessizce kaybolur, çünkü onları düşüren cihazın bildirimi de engellenmiştir
• Gönderen taraf neden durduğunu bilemez, çünkü ona hiçbir şey söylenmemiştir

Sahada bunun görüntüsü şudur: site açılır ama dosya indirilemez, VPN bağlanır ama üzerinden veri geçmez, oturum kurulur ama büyük sorgular takılır. Hiçbiri “ağ kopuk” gibi görünmez, hepsi uygulama arızası gibi görünür.

ICMP’yi Kapatmak: Güvenlik mi, Körlük mü?

ICMP’yi tamamen kapatmak, kazandırdığından fazlasını götüren bir tercihtir. Bu bölüm bir öneri değil, iki tarafın da neyi kaybettiğini gösteren bir muhasebedir.

Kapatmayı savunan argüman gerçektir ve göz ardı edilmemeli: echo request’e cevap veren bir makine, kendisini tarayan birine “buradayım” der. Saldırgan bir ağdaki canlı adresleri en ucuz şekilde ping ile bulur.

Ama ICMP’nin tamamını kapatmak bunun çok ötesine geçer. Kaybedilenler:

• Paket boyutu pazarlığı kırılır. Önceki bölümdeki sessiz arıza tam olarak budur.
• Yol teşhisi imkânsızlaşır. Tracert çalışmaz, arıza anında yolun neresinde koptuğu görülemez.
• Kendi izleme sisteminiz körleşir. Sunucu erişilebilirliğini ölçen araçların büyük kısmı ping temellidir.
• Sorun giderme süresi uzar. Reddetmek yerine sessiz kalan bir sistem, kendi ekibinizi de belirsizlikte bırakır.

Uygulanan yol ikisinin ortasıdır ve mesaj tipine göre ayrım yapar. Yaygın duruş şudur: dış dünyadan gelen echo request’e cevap verilmez, ancak time exceeded ve fragmentation needed mesajlarına izin verilir. İç ağda ise ICMP genellikle açık bırakılır, çünkü orada teşhis kabiliyeti tarama riskinden daha değerlidir.

Ne zaman gerekmediğini de söyleyelim: birkaç kişilik bir ofiste, tek bir internet bağlantısı ve basit bir yerel ağ varken ICMP’yi mesaj tipine göre ayırmak pratik bir kazanç getirmez. Bu ayrım, birden çok lokasyonu, VPN bağlantısı veya kendi sunucularını işleten yapılarda anlam kazanır.

ICMP ile Teşhis: Hangi Çıktı Neyi Söyler?

Buraya kadar ölçtüğümüz her şeyi tek tabloya indiriyorum. Ama tablodan önce, bütün teşhisi tek soruya indiren şemayı koyuyorum: bu cevabı kim üretti? Mesajın metni ikinci sorudur; birinci soru, sesin nereden geldiğidir.

Tablonun son iki satırı, sahada en çok zaman kaybettiren ikilidir ve ikisinin de ortak özelliği aynıdır: sorunun görüldüğü yer ile bulunduğu yer farklıdır.

Sonuç: Sessizliğin de Bir Anlamı Var, Ama Aynı Anlam Değil

ICMP’yi öğrenmek yeni bir araç öğrenmek değildir. Zaten kullandığınız araçların size ne söylediğini duymaya başlamaktır.

ping yazan herkes bir echo request gönderir; ama ekrandaki dört farklı cevabı ayırt edebilen kişi, arızanın hangi katmanda olduğunu ilk dakikada daraltır. Diğerleri karşı tarafı araştırırken o kendi ağ kartına bakar, ya da tam tersi. Bu makale boyunca ölçtüğümüz şey teknik olarak yedi senaryoydu; pratikte ise tek bir soruydu: bu cevabı kim üretti?

Cevabı hedef ürettiyse hedef ayaktadır ve sorun daha yukarıdadır. Cevabı yoldaki bir cihaz ürettiyse sorun o cihazın ötesindedir. Cevabı kendi makineniz ürettiyse sorun sizde başlar. Ve hiç cevap yoksa, elinizde bilgi yok demektir: sessizlik bir teşhis değil, teşhisin başlamadığı yerdir.

Kargo bildirimi benzetmesinin koptuğu yer de tam burasıdır ve makaleyi bununla kapatmak doğru olur. Gerçek kargo firması size bildirim göndermeyi taahhüt eder; göndermezse hesabını sorabilirsiniz. ICMP’de böyle bir taahhüt yoktur. Yoldaki cihaz hata mesajı üretmeyebilir, güvenlik duvarı onu düşürebilir, mesajın kendisi kaybolabilir ve kimse bunu fark etmez. Bu yüzden ICMP’den gelen bilgi değerlidir ama gelmeyen bilgi bir kanıt değildir.

Ağ teşhisinin geri kalanını, yani adreslerin nasıl çözüldüğünü ve servislerin nasıl test edildiğini ARP ve MAC adresi ve port ve bağlantı arızası makalelerinde ele aldık. Protokollerin birbirine nasıl bağlandığını görmek isterseniz ağ protokolleri rehberi bütün resmi veriyor.

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.