Linux EHOSTUNREACH ve OpenVPN: hangi sonraki hop başarısız oldu?

EHOSTUNREACH, uzak bir arıza olduğu kadar sıklıkla yerel bir karardır. Çekirdek bir paketi, bir rota hedefin unreachable olduğunu söylediği için, Ethernet sonraki hop hiç yanıt vermediği için veya yolun daha ilerisinden bir ICMP host-unreachable raporu geldiği için reddedebilir. Her kaynak farklı bir tabloda veya önbellekte yaşar ve her biri farklı bir yerde düzeltilir. Şifrelere dokunmadan veya tüneli yeniden kurmadan önce seçilen rotayı ve sonraki hop durumunu okuyun.

İstemcinin gerçekte kullandığı adresi ve namespace'i seçin

Hedefi ve hatayı üreten ağ namespace'ini sabitleyerek başlayın. Bir VPN istemcisi kendi namespace'inde çalışabilir ve varsayılan olandan yapılan bir arama, farklı politika kurallarına sahip başka bir yönlendirme tablosuna bakar.

Arama, başarısız olan uygulamayla aynı kaynağı, mark'ı ve tablo bağlamını kullanmalıdır, aksi halde kimsenin sormadığı bir soruyu yanıtlayabilir. Örnek bir IPv4 peer için salt okunur kontroller şunlardır:

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

Yönetici kabuğundan gelen bir sonuç yalnızca o kabuğun ne yapacağını kanıtlar. İstemci bir firewall mark ayarlıyorsa veya bir VRF'ye bağlanıyorsa, aramayı eşleşen mark ile veya VRF içinde tekrarlayın ve seçilen rotayı ve sonraki hopu karşılaştırın. Doğrulanacak ilk adres, profildeki peer adresidir; kullanıcının adlandırdığı küme veya hizmet değil.

Açık bir unreachable rotası paketi yerel olarak reddeder

unreachable türünde bir rota bilinçli bir yerel yanıttır. Çekirdeğe paketi atmasını ve gönderene EHOSTUNREACH döndürmesini söyler, bu yüzden hata anında ve makineden hiçbir trafik çıkmadan görünür. Birisi veya bir otomasyon o rotayı oraya bilerek koymuştur.

Rota türleri birbirinin yerine geçmez. blackhole paketi gönderene hata vermeden atar, prohibit EACCES döndürür ve unreachable EHOSTUNREACH döndürür. Yeniden bağlanma sırasında sink rotası kuran bir VPN yardımcısı, bu nedenle tünel açıldığında kaybolan host-unreachable hata patlaması üretebilir; blackhole rotası ise bunun yerine sessiz zaman aşımları üretirdi.

Uzak ucu suçlamadan önce türü tüm tablolarda arayın. Tabloyu seçen kural, içindeki rota kadar önemlidir ve ana tabloya eklenen bir rota, politika kuralı trafiğini başka yere gönderen bir istemciye yardımcı olmaz.

Ölü bir komşu Ethernet'te aynı hatayı üretir

Seçilen rota on-link bir ağ geçidi kullanıyorsa, teslimat çözülmüş bir bağlantı katmanı adresi gerektirir. Çekirdek bir ARP veya IPv6 komşu sorgusu gönderir ve yanıt gelmezse paket çerçevelenemez. Gönderim o zaman rotanın kendisi geçerli olsa da EHOSTUNREACH ile başarısız olur.

Komşu tablosu aşamayı adlandırır. INCOMPLETE bir çözümlemenin sürdüğünü, FAILED son denemenin yanıt almadığını, REACHABLE veya STALE ise çekirdeğin kullanılabilir bir adresi olduğunu gösterir. VPN ağ geçidi için FAILED kaydı yerel bir teslimat sorunudur, tünelin uzak tarafı hakkında kanıt değildir.

Kaydı gerçek sonraki hop için okuyun, uzak internet adresi için değil. Uzak bir adrese normalde bir yönlendirici üzerinden ulaşılır, bu yüzden kendi ARP kaydı olmaz; onu istemek, hiç var olmaması gereken eksik bir kaydı insanlara arattıran bir kategori hatasıdır.

Uzak raporlar ve eşzamansız UDP hataları

EHOSTUNREACH dışarıdan da gelebilir. Paketi iletemeyen bir yönlendirici ICMP host unreachable gönderebilir ve çekirdek bu raporu akışa sahip olan socket'e iletir. Bu durumda rota ve komşu iyidir ve arıza yerel ağın ötesindeki bir hopa aittir.

UDP, nedeni belirlemeyi zorlaştırır. Daha sonraki bir send veya receive çağrısının döndürdüğü hata önceki bir datagrama ait olabilir, bu yüzden başarısız çağrının adresi ve zamanı raporu tetikleyen paketle eşleşmeyebilir. Bağlı bir UDP socket hatayı bir kez alır ve bağlı olmayan bir socket bunu hiç görmeyebilir.

Bu yüzden zaman kanıtın parçasıdır. Hatanın ne zaman göründüğünü, socket'in hangi peer adresini kullandığını ve tünelin az önce yeniden bağlanıp bağlanmadığını not edin. Bir rota değişikliğinden hemen sonraki patlama yerel tabloya işaret eder; kararlı bir akışta dakikalar sonra gelen tek bir hata yol raporuna işaret eder.

Şifrelemeyi değiştirmeden önce katmanları ayırın

Hatayı üç soru sınıflandırır. Çekirdek hedefi reddeden bir rota mı seçti? Geçerli bir rota seçti ama sonraki hopu çözemedi mi? Yoksa yerel ağın ötesinden bir rapor mu geldi? Tünelin uzak ucunu yalnızca üçüncü durum ilgilendirebilir ve o zaman bile şifrelemeyi ilgilendirmez.

Kimlik doğrulama ve anlaşma sorunları, taşıma peer'a ulaştıktan sonra kendi hataları olarak ortaya çıkar. Bir şifreyi değiştirmek veya istemciyi yeniden kurmak yerel bir unreachable rotasını düzeltemez ve gerçek neden için ihtiyaç duyacağınız rota ve komşu kanıtını yok eder.

İlk değişiklikten önce hedefi, namespace'i, seçilen tabloyu, sonraki hopu, komşu durumunu ve hata zamanını kaydedin. Düzeltmeden sonra aynı aramayı yeniden çalıştırın; artık tünele işaret eden bir rota ve artık çözülen bir komşu kaydı, ilgisiz bir adrese başarılı bir ping'den daha güçlü kanıttır.