IPv6 komşu keşfi yönlendirilmiş bir VPN üzerinde neden başarısız olur

IPv6 komşu keşfi tek bir bağlantıya aittir ve yönlendirilmiş tünel iki bağlantı arasındaki sınırdır. O tek cümle, adresiyle yanıt veren ama başka hiçbir yolla bulunamayan uzak bir ana makineyle ilgili neredeyse her raporu açıklar. Tüneli kontrol etmeden önce test ettiğiniz adresin kapsamını kontrol edin. Bağlantıya özgü bir adres yalnızca kendi bağlantısında anlamlıdır ve istenen düğümün çoklu yayın grubu da aynı şekilde sınırlıdır. İkisi de bir yönlendiriciden geçmez, bu yüzden genel bir adrese ping başarılı olabilirken aynı ana makine için keşif başarısız olur.

Kapsam yapılandırmadan önce gelir

Komşu isteği ve duyurusu 255 atlama sınırı taşır ve tasarım gereği iletilmez. Tüneliniz ile uzak LAN arasındaki yönlendirici IPv6 paketlerini iletir ve komşu mesajlarını onun adına aktarmaz. Böylece tünel arayüzündeki komşu önbelleği eşi ve az başka şeyi içerir; bu doğru davranıştır, düzeltilecek bir kusur değildir.

fe80:: gibi bir girdi içeren bağlantıya özgü adres de bölge ile sınırlıdır ve aynı metin başka bir bağlantıda başka bir ana makineyi gösterebilir. Tünelin öteki tarafından birini test etmek adresin belirsiz olduğundan başka bir şey kanıtlamaz.

Tuzak, önekin bağlantıda olduğu varsayımıdır

Bir önekin bağlantıda olduğuna inanan ana makine, paketi yönlendiricisine vermek yerine komşu isteği gönderir ve buna uzak bir siteye yönlendirilen /64 de dahildir. Böyle bir önek bağlantıda olarak geldiğinde, ana makine yerel bağlantıya başka yerde yaşayan bir ana makineyi sorar ve hiçbir şey yanıt vermez. Uzak ana makineye daha küçük bir şey yönlendirin ya da öneki onun adına yanıt verecek yönlendiricide sonlandırın.

Tek bir hizmet için /128 en az şaşırtıcı düzenlemedir ve belirsizliği tamamen ortadan kaldırır. Komşu keşfi belirtimi, ileti kümesini ve buna karar veren bağlantıda-bayrağını açıklar.

Köprüleme kuralları bilerek değiştirir

Tünel Ethernet çerçeveleri taşıdığında, uzak ve yerel segmentler tek bir bağlantı olur, çoklu yayın iki tarafa da ulaşır ve komşu keşfi bir anahtarlayıcıdaki gibi davranır. Sonuçlar da beraberinde gelir: yayın ve çoklu yayın taşması, köprü boyunca yinelenen adres algılama ve görmemesi gereken bir segmente sızan yönlendirici duyuruları. Arıza alanı artık iki sahayı da kapsıyor. Bunların hiçbiri köprülemeye karşı bir argüman değildir ve her nokta köprüyü rastlantıyla değil bilerek kurmanın nedenidir.

Keşif görünsün diye profili TUN'dan TAP'a çevirmek yanlış işlem sırasıdır. Sunucu, istemci ve adresleme planı anlaşmak zorundadır ve mobil istemciler hiç TAP arayüzü sunmaz, bu yüzden böyle bir tasarım dizüstü bilgisayarda çalışır ve telefonda başarısız olur. Komşu vekilleri ve aktarıcıları kendi gereksinimleri olan ayrı mekanizmalardır ve bir uygulamanın ayarlarına değil, ağ yöneticisinin belgelenmiş düzenine aittir.

Uygulamanın kullandığı adresle test edin

Rotayı ip -6 route get ile doğrulayın, komşu girdisini ip -6 neigh ile inceleyin ve ardından hizmeti yönlendirilmiş yol üzerinde doğrulayın. DNS ve dönüş yolu ayrı kontrollerdir ve sağlıklı bir komşu girdisi ikisini de kanıtlamaz.

Uygulama bağlantıya özgü veya keşfe dayalı bir hedefte ısrar ediyorsa, bu bir ayar alıştırması değil tasarım konuşmasıdır, çünkü hiçbir istemci ayarı bağlantıyla sınırlı bir mekanizmayı bir yönlendirici üzerinden çalışır hale getirmez.

Hangi tasarıma sahip olduğunuzu yazın

Olaydan önce yönlendirilmiş mi köprülenmiş mi olduğunu kaydedin, çünkü iki dağıtım bu soruları farklı yanıtlar ve nöbetçi mühendis bunu bir profilden çıkarsamak zorunda kalmamalıdır.

İleti kümesini bir kez okumak, bağlantı kapsamı özelliğini VPN hatası olarak açıklama isteğini ortadan kaldırır ve bu, bu alandaki en pahalı yanlış teşhistir.