Tünelden geçmesi gereken bir akış farklı bir sonraki atlama seçer ve biri yakalamada bir ICMP yönlendirmesi bulur. Bu bir hipotezdir, teşhis değil. Yönlendirme, daha iyi bir sonraki atlama hakkında yönlendiricinin önerisidir ve ana makinenin buna göre hareket edip etmemesi platforma, arayüze ve adres ailesine göre değişen ayarlara bağlıdır.

Yönlendirme, yönlendiriciden gelen bir öneridir

IPv4 ICMP yönlendirmelerinin kendi mesaj türü ve dar bir koşullar kümesi vardır: yönlendirici paketi geldiği arayüzden dışarı iletir ve aynı bağlantı üzerinde hedefe daha yakın bir sonraki atlamayı bilir. Ardından gönderene o atlamayı doğrudan kullanmasını söyler. Mesaj yeni ağ geçidini adlandırır ve gönderenin bir akışla eşleştirebilmesi için özgün paketin bir bölümünü içerir. Bu, yerel topoloji hakkında bir nezaket mesajıdır ve gönderenin önerilen ağ geçidiyle aynı bağlantıyı paylaştığını varsayar.

Gönderen bunu yok saymakta özgürdür. Protokol, ana makinenin tablosunu değiştirmesini gerektirmez ve yakalanan bir yönlendirme yalnızca bir yönlendiricinin onu gönderdiğini kanıtlar.

Çoğu yönlendirme incelemesi tam da bu ayrımda yanılır.

IPv4 ile IPv6 bunu farklı biçimde iletir

IPv6'da benzer bir mekanizma ICMPv4'te değil, komşu keşfinin içinde bulunur; mesaj biçimleri ve doğrulama kuralları farklıdır. Kavramlar kafiyeli, paketler değil. ICMP tür 5 için yazılmış bir yakalama filtresi IPv6 ağında hiçbir şey göstermez ve bu bazen yönlendirme olmadığına dair kanıt olarak okunur.

Politika ayarları da ayrıdır, bu yüzden bir ana makine IPv4 yönlendirmelerini kabul edip IPv6'yı yok sayabilir ya da tersi.

Söz konusu akış ikisinden birini kullanabiliyorsa iki aileyi de denetleyin.

Kabul, ana makine politikasıdır, ağ gerçeği değil

Linux'ta yönlendirmelerin kabulü arayüz başına ve genel olarak denetlenir ve varsayılanlar ana makine ile yönlendirici rollerinde farklıdır. Yönlendirmeleri kabul eden bir tünel arayüzü tuhaf bir tasarımdır, çünkü noktadan noktaya bir tünelin içinde aynı bağlantıda anlamlı bir alternatif sonraki atlama yoktur. Bu yüzden bu ayarı varsaymak yerine okumak gerekir.

Güvenli yönlendirme ayarları hangi ağ geçitlerine güvenilebileceğini daha da kısıtlar.

Bir ana makineyi sıkılaştırıyorsanız gözden geçirilecek ayarlar bunlardır ve aynı ağdaki iki makinenin farklı davranmasının nedeni de bunlardır. Bunları hata ayıklama kestirmesi olarak değil, politika olarak değiştirin.

Yönlendirmenin açıklayamadığı şey

Belirli rotalar, politika yönlendirme kuralları ve yerel arayüzler beklenmeyen yolların çoğunu hiçbir yönlendirme olmadan açıklar. Daha belirli bir önek, kaynak adresle eşleşen bir kural veya başka bir tablodaki ikinci varsayılan bunların her biri beklediğiniz rotayı geçersiz kılar. Önce bunları denetleyin, çünkü belirlenimci ve görünürdürler.

Eski yakalama diğer tuzaktır, çünkü ağ değiştiren bir istemcinin yerel ağ geçidi farklıdır.

Önceki bağlantıdan kalan eski bir yönlendirme mevcut yol hakkında hiçbir şey açıklamaz, bu yüzden denetim trafiğini artık hangi arayüzün aldığını kaydedin.

Tüneli suçlamadan önce rotayı denetleyin

Çekirdeğe hedef için hangi rotayı kullanacağını sorun, sonra bunu amaçladığınız tabloyla karşılaştırın. Yanıt tabloyla eşleşiyorsa hiçbir yönlendirme bir şeyi değiştirmemiştir ve inceleme başka bir yere aittir. Eşleşmiyorsa tünelin suçlu olduğunu varsaymadan önce önbelleğe alınmış bir yönlendirme, bir politika kuralı veya ikinci bir tablo arayın. Rota sorgusu temel gerçektir, geri kalan her şey bunun nasıl böyle olduğuna dair bir hikâyedir.

Bir yönlendirme, korunan bir yolun sessizce korumasız hale gelmesinin nedeni olmamalıdır, bu yüzden kabul politikası tasarım incelemesine aittir. RFC 792 tanımı IPv4 mesajının ne söyleyebileceğine dair başvuru olmayı sürdürür.

Rota sorgusunu ve yakalamanın zaman damgasını birlikte yazın, böylece sonraki kişi sonucunuzu yeniden üretebilir.

İlgili makaleler