Linux'ta MTR ile Ağ Yolu Nasıl Analiz Edilir?

Sesli Dinle — Makale

MTR, Linux terminalinde hedefe kadar görülen ağ yolunu tekrarlanan yoklama paketleriyle inceler. IPv4'te TTL, IPv6'da ise Hop Limit (sıçrama limiti) alanı paketin geçebileceği yönlendirici sayısını sınırlar; MTR bu değeri adım adım artırarak ara düğümleri bulur. Her düğüm için gidiş-dönüş süresini ve yanıtsız kalan yoklamaların oranını hesaplar. Bu nedenle tek seferlik yol görünümünden çok, ölçüm süresi boyunca değişen belirtileri izlemek için kullanılır.

Rapor bir arızanın yerini tek başına kanıtlamaz. Ara yönlendiriciler ICMP yanıtlarını sınırlayabilir veya düşük öncelikte işleyebilir; bu durumda bir ara düğümde yüksek kayıp görünürken sonraki düğümler ve son hedef kayıpsız yanıt verebilir.

Ölçümü yalnız yönetmeye veya test etmeye yetkili olduğunuz hedeflerde, sınırlı döngü sayısıyla ve kayıt altına alınmış koşullarda çalıştırın. Son hedef, ara düğümler, kullanılan protokol ve tekrar zamanı birlikte değerlendirilmelidir.

Linux'ta MTR Komutu Nasıl Çalıştırılır?

MTR çoğu Linux dağıtımında paket deposundan kurulabilir; paket adı ve ayrı grafik arayüzünün bulunup bulunmaması dağıtıma göre değişir. Önce komutun erişilebilir olduğunu kontrol edin.

Kurulum ve Yetki Kontrolü

mtr --version

Komut bulunamazsa dağıtımınızın paket yöneticisinde MTR paketini arayın ve dağıtımın resmi paket talimatını izleyin. Paket kurulumu, yoklama paketleri için gereken düşük seviyeli ağ yetkilerini yardımcı bileşen veya Linux yetenekleri üzerinden düzenleyebilir; izin hatasını çözmek için çalıştırılabilir dosyalara gelişigüzel geniş yetki vermeyin.

Etkileşimli İzleme

mtr hedef.example

hedef.example yalnız yer tutucudur; yönetmeye veya ölçmeye yetkili olduğunuz ana makine adı ya da IP adresiyle değiştirilmelidir. Etkileşimli ekran istatistikleri yeniler; ölçümü sonlandırmak için arayüzde q tuşunu veya terminal kesme komutunu kullanabilirsiniz.

Etkileşimli mod kısa gözlem için uygundur, ancak olay kaydı veya destek talebi için sonucun sabit bir rapora dönüştürülmesi gerekir. Aksi halde ekran yenilendikçe önceki değerler kaybolabilir veya kopyalanması güçleşebilir.

Sınırlı Döngüyle Paylaşılabilir MTR Raporu

mtr --report --report-wide --show-ips --report-cycles 50 hedef.example

--report ölçümü tamamlayıp istatistikleri yazdırır, --report-cycles 50 her atlama için sınırlı sayıda yoklama döngüsü belirler, --report-wide uzun adların kesilmesini azaltır ve --show-ips ana makine adıyla IP adresini birlikte gösterir. Elli döngü evrensel bir eşik değildir; kısa süreli dalgalanmayı görmek ile hedefe gereksiz trafik göndermemek arasında kontrollü bir başlangıç örneğidir.

Ad çözümlemesinin raporu yavaşlattığından veya isimleri değiştirdiğinden şüpheleniyorsanız --no-dns kullanabilirsiniz. IPv4 ve IPv6 yollarını ayrı incelemek için sırasıyla -4 ve -6 seçenekleri kullanılmalıdır; iki adres ailesinin farklı ağ yolları izlemesi normaldir.

ICMP Yerine TCP veya UDP ile MTR Ölçümü

mtr --report --tcp --port 443 --report-cycles 50 hedef.example

Varsayılan ICMP yoklamaları filtreleniyorsa, yetkili olduğunuz HTTPS hedefini TCP üzerinden 443 numaralı bağlantı noktasında ölçebilirsiniz. Bu yoklama, HTTPS isteğinin veya TLS görüşmesinin başarıyla tamamlanacağını göstermez. UDP için --udp seçeneği bulunur. ICMP, TCP ve UDP sonuçları farklı güvenlik duvarı ve trafik politikalarından geçebileceği için farklı protokollerle alınan raporlar aynı ölçüm serisi gibi birleştirilmemelidir.

MTR Çıktısı Nasıl Okunur?

Standart rapor, her atlamayı bir satırda gösterir. Sütunların birlikte okunması gerekir; tek bir yüksek değer, sonraki satırlar ve son hedef görülmeden yorumlanmamalıdır.

MTR'nin gecikme sütunları çoğunlukla milisaniye cinsinden gidiş-dönüş süresidir. Bunlar tek yön gecikmesi değildir; iki yönün farklı ağ yolları izlemesi ve dönüş yönündeki kuyruklar sonucu etkileyebilir.

Ara Düğüm ve Son Hedef Birlikte Değerlendirilir

Aşağıdaki çıktı yalnız yorumlama yöntemini göstermek için hazırlanmış varsayımsal bir örnektir.

Host              Loss%  Snt  Last   Avg  Best  Wrst  StDev
1. 192.0.2.1        0.0%   50   1.2   1.1   0.8   2.6    0.3
2. 198.51.100.1    42.0%   50   8.4   8.1   7.7  12.0    0.8
3. 198.51.100.2     0.0%   50  12.5  12.3  11.8  16.1    0.7
4. 203.0.113.10     0.0%   50  18.2  18.0  17.4  23.5    0.9

İkinci atlamadaki yüzde 42 kayıp sonraki atlamalara ve hedefe taşınmadığı için, bu satır doğrudan veri iletim kaybı kanıtı değildir. Ara yönlendirici MTR yoklamalarına sınırlı yanıt veriyor olabilir; gerçek iletim sorunu olsaydı benzer kaybın sonraki satırlarda ve hedefte de görünmesi beklenirdi.

Paket Kaybı ve Gecikme Belirtilerini Yorumlama

MTR raporu, sorunun kesin kaynağını değil, hangi bölümden sonra ölçümlerin değiştiğini gösteren bir gözlem kaydıdır. Yorumun gücü, belirtinin hedefe kadar sürmesine ve aynı koşullarda tekrarlanmasına bağlıdır.

Ara Düğümde Görülen Kayıp

Bir ara düğümde yüksek Loss% görülürken sonraki düğümler düşük kayıp veya sıfır kayıpla yanıt veriyorsa, en olası açıklamalardan biri ICMP yanıt sınırlaması ya da kontrol trafiğine düşük öncelik verilmesidir. Bir atlamanın yüzde 100 kayıp göstermesine rağmen daha sonraki atlamaların yanıt vermesi de yolun orada koptuğu anlamına gelmez; o cihaz yalnız kendi yanıtını göndermiyor olabilir.

Hedefe Kadar Süren Kayıp

Kayıp belirli bir atlamada başlıyor ve sonraki atlamalarla son hedefte benzer düzeyde sürüyorsa, uçtan uca iletim sorunu ihtimali güçlenir. Yine de tek raporla belirli bir yönlendiriciyi veya ağ işletmecisini kesin sorumlu ilan etmek doğru değildir; dönüş yolu, eş maliyetli yük dengeleme, geçici kuyruklanma ve hedefin yanıt politikası görünümü değiştirebilir.

Kayıp yalnız son hedefte görünüyorsa hedef makine, güvenlik duvarı veya hizmet sağlayan altyapı yoklamaları sınırlıyor olabilir. Uygulama trafiğinde de hata görülüyorsa MTR sonucu; hizmet günlüğü, arayüz sayaçları ve aynı anda yapılan uç nokta ölçümleriyle birlikte incelenmelidir.

Kalıcı Gecikme Artışı

Bir atlamada gecikme yükseliyor ve sonraki tüm atlamalarda aynı yeni seviyeye yakın kalıyorsa, o noktadan sonra daha uzun fiziksel yol, kuyruklanma veya yoğun bir bağlantı etkili olabilir. Yalnız tek ara düğüm yüksek gecikme gösterip sonraki düğümler yeniden düşük değerlere dönüyorsa bu, ara cihazın kendi ICMP yanıtını geç işlemesinden kaynaklanabilir.

Best değeri, ölçüm sırasında görülen en düşük gidiş-dönüş süresidir ve daha az kuyruklanmış bir örneğe yaklaşabilir; fiziksel tek yön gecikmesini vermez. Wrst ile Best arasındaki fark ve yüksek StDev, ortalama makul görünse bile zaman zaman belirgin gecikme sıçramaları yaşandığını gösterebilir.

Yol Değişiklikleri ve Yük Dengeleme

Aynı atlama numarasında farklı IP adresleri görülmesi, birden fazla eşdeğer ağ yolunun kullanılmasıyla ilişkili olabilir. Ayrıca ölçümler farklı zamanlarda farklı çıkışlara yönlenebilir. Bu nedenle iki raporu karşılaştırırken yalnız tek IP adresi satırını değil, hedef adresini, tüm atlama dizisini, ölçüm zamanını ve kullanılan protokolü birlikte kaydedin.

MTR ile Traceroute Arasındaki Farklar

Traceroute, hedefe giden ara düğümleri kısa bir ölçüm dizisiyle gösteren anlık bir yol görünümüdür. MTR aynı temel atlama keşfini tekrarlanan yoklamalarla sürdürür ve her düğüm için kayıp, ortalama, en iyi, en kötü ve değişkenlik istatistikleri toplar.

• Tek seferlik yol görünümü gerektiğinde traceroute daha kısa bir kayıt üretir.
• Zaman içinde gecikme ve yanıt kaybı değişimini görmek gerektiğinde MTR daha fazla örnek sunar.
• Her iki araç da uygulama günlüğü, arayüz hata sayacı veya paket yakalama verisinin yerine geçmez.

MTR Raporlarını Aynı Koşullarda Karşılaştırma

Karşılaştırılabilir rapor için ölçüm koşulları komut kadar önemlidir. Aşağıdaki sıra, sorun anıyla normal dönemi ayırmayı ve raporun başka bir ekip tarafından yeniden değerlendirilmesini kolaylaştırır.

1. Yalnız yetkili hedefi ve ölçüm amacını belirleyin.
2. Kaynak makinenin ağ arayüzünü, bağlantı türünü ve ölçümün yapıldığı bağlantının genel IP adresini kaydedin.
3. IPv4 veya IPv6 seçimini, ICMP/TCP/UDP yöntemini ve gerekiyorsa hedef bağlantı noktasını sabitleyin.
4. Sınırlı bir döngü sayısı ve makul gönderim aralığı kullanın; çok kısa aralıklarla çok sayıda eşzamanlı ölçüm başlatmayın.
5. Aynı komutu normal çalışma döneminde ve sorun yaşanırken tekrarlayın.
6. Tarih, saat dilimi, MTR sürümü, tam komut ve ham raporu birlikte saklayın.
7. Ölçüm tamamlanınca işlemi durdurun; üçüncü taraf hedeflere sürekli izleme kurmayın.

Raporları karşılaştırırken önce son hedefe bakın; kayıp veya gecikme artışı hedefe kadar sürüyorsa bunun hangi atlamadan sonra başladığını kontrol edin. Aynı durum farklı zamanlarda tekrarlanıyorsa internet servis sağlayıcınızdan veya ilgili ağın yöneticisinden bu bölümü arayüz sayaçları ve günlüklerle incelemesini isteyin.

MTR Sonuçlarını Yanlış Yorumlamaya Yol Açan Durumlar

• Tek ara düğümü suçlamak: Sonraki atlamalar ve hedef etkilenmiyorsa ara satırdaki kayıp çoğu durumda yeterli kanıt değildir.
• Protokolleri karıştırmak: ICMP raporunu TCP 443 raporuyla doğrudan aynı seri gibi karşılaştırmak, farklı filtreleme politikalarını gözden kaçırabilir.
• DNS etkisini yol değişimi sanmak: Ana makine adı farklı adreslere çözümlenebilir; gerektiğinde hedef IP adresini ve --no-dns çıktısını kaydedin.
• Örnek sayısını bağlamdan koparmak: Çok az döngü kısa sıçramaları büyütebilir, çok uzun ve sık ölçüm ise gereksiz trafik oluşturabilir.
• RTT'yi tek yön gecikme saymak: MTR gidiş ve dönüş yolunun birleşik süresini gözler; asimetrik yollar sonucu etkiler.
• Yetki hatasını geniş izinle çözmek: Dağıtım paketinin güvenli yetki modelini kullanın; çalıştırılabilir dosyalara rastgele setuid yetkisi vermek veya tüm oturumu root kullanıcı olarak sürdürmek uygun bir varsayılan değildir.

Yerel MTR Komutu ile Web Tabanlı Rota Analizinin Farkı

Linux'taki MTR ölçümü, komutun çalıştığı kaynağın ağ açısından gördüğü yolu yansıtır. Web tabanlı rota analizleri farklı bir ölçüm noktasından sonuç üretebilir; bu nedenle iki sonuç doğrudan aynı yolun ölçümü sayılmamalıdır.