IPv6 tünelinizin karşı ucuna ping başarısız mı? :: adresini kontrol edin

IPv6 tünelinizin bir ucu diğerine ping atar ve her zaman yalnızca tek yön yanıt verir. Arayüz açık, rota doğru görünüyor ve günlükte bunu açıklayan hiçbir şey yok. Atadığınız adres subnet-router anycast adresidir, ki bu hiç de bir ana bilgisayar adresi değildir ve iki uçlu bir bağlantıda tam olarak tek bir teslim hedefi vardır: gönderen. Hiçbir zaman aşımı değeri bunu onarmaz, çünkü adres sizin düşündüğünüz şeyi yapmıyor.

Adrese işaret eden belirti

Bağlantıdaki her ana bilgisayar yanıt verir, yalnızca arayüz tanımlayıcısı tamamen sıfır olan hariç. Bu biçime adreslenen bir paket tanım gereği alt ağdaki bir yönlendiriciye teslim edilir, bu yüzden noktadan noktaya bir tünelde onu gönderen makineye geri döner. Uzak uçtan bu, erişilemeyen bir eş olarak okunur; yakın uçtan ise sessizlik olarak okunur. Aynı önekten farklı bir tanımlayıcı koyun ve belirti başka hiçbir değişiklik olmadan kaybolur; bu, rotalara dokunmadan önce alınması gereken doğrulamadır.

Tümü sıfır tanımlayıcı anycast olarak ayrılmıştır

RFC 4291, tümü sıfır arayüz tanımlayıcısını subnet-router anycast adresi olarak korur, bu yüzden 2001:db8:4a::/64 gibi bir /64, 2001:db8:4a:: adresinde kullanılabilir hiçbir ana bilgisayar içermez. Bu ayırmanın bir yeri vardır: router advertisements ve neighbour discovery bu biçime hitap eder ve bir yönlendirici hizmet ettiği önek için yanıt verir. Bu değeri bir tünel ucuna atamak, yönlendirici rolünü bir yaprağa verir ve hiçbir şeyin geri dönmemesinin nedeni budur. Önekteki başka herhangi bir tanımlayıcı ana bilgisayar olarak çalışır, bu yüzden onarım genellikle tek bir basamaktır.

Ayrımı, tünel ucundan üstlenmeye hakkınız olmayan bir rol olarak görün, rotayla etrafından dolaşılacak bir tuhaflık olarak değil.

Ana bilgisayar adresleri atayın ve öneki yönlendirin

İki uç için ::1 ve ::2 seçin, birini ip -6 addr add 2001:db8:4a::2/64 dev tun0 ile ekleyin ve ardından uzak öneki adreslemeye çalışmak yerine yönlendirin. Tünelden dışarı 2001:db8:4a::/64 için bir rota uzak tarafı erişilebilir kılar; adresin kendisi yalnızca yerel arayüzü yapılandırır.

Tam bir tünel için üçüncü bir adım vardır: cihaz üzerinden küresel unicast için varsayılan rota, ki bu her şeyi tünele göndermenin IPv6 karşılığıdır. Bunu atlarsanız IPv4 tünelin içinde yol alırken IPv6 fiziksel bağlantıyı kullanmaya devam eder, böylece ana bilgisayar kapsandığını sandığınız trafiği tam olarak sızdırır. ip -6 route get 2001:4860:4860::8888 ile doğrulayın ve yanıtı varsaymak yerine hangi cihazı adlandırdığını okuyun.

Multicast yönlendirmeden önce reddedilir

Android, VpnService.Builder için adresleri ve rotaları LinkAddress üzerinden doğrular ve bu kurucu multicast'i tamamen reddeder. Ona rota olarak bir multicast öneki verin, sonuç rota yerine bad LinkAddress parameters hatasıdır; bu bir doğrulama yanıtıdır, ağ yanıtı değil. Ret, ortama uygundur: noktadan noktaya bir tun aygıtının bağlantı katmanı multicast'i yoktur, bu yüzden üzerindeki bir grup rotasının kuracak bir teslim modeli yoktur. Grup adresleri elle yapılandırılmak yerine yığının kendisi tarafından oluşturulur ve tüketilir.

IPv6 all-nodes ve solicited-node adresleri aynı kurala girer. Arayüz onları taşır çünkü yığın onları oraya koymuştur, bir politika onları amaçladığı için değil.

Bir tünelin bunun yerine taşıyabileceği şey

multicast keşfini bir tünel üzerinden taşımak, grup üyeliğini anlayan bir katman gerektirir: bir Ethernet segmenti sunan TAP köprüsü, uygulama düzeyinde bir relay veya hangi eşlere çoğaltılacağı açıkça söylenen bir yönlendirme protokolü. VpnService modelinde bunların hiçbiri yoktur; orada uygulama paketleri okuyup yazar ve tünel için bir gruba katılan bir çağrısı yoktur. Ya grupları anlayan bileşeni ekleyin ya da gereksinimi tasarımdan çıkarın.

Unicast ise yukarıdaki adresler ve rotalar dışında hiçbir şey gerektirmez, bu yüzden tünellerin genellikle onu taşıması beklenir ve sonra bir keşif protokolü başarısız olduğunda suçlanır.

Bir şey atamadan önce üç kontrol

Adresin anycast biçimi olmadığını doğrulayın, multicast olmadığını doğrulayın ve önekin yalnızca cihaza atanmakla kalmayıp yönlendirildiğini doğrulayın. Ardından testinizi gerçek bir ana bilgisayar olan bir hedefe gönderin, çünkü anycast adresine yöneltilmiş bir ping göndereni ölçer ve yol hakkında hiçbir şey söylemez. Bu üç kontrolü değişiklik kaydına yazın ki bir sonraki dağıtım onları yeniden keşfetmesin.

Platformun hiç kurmadığı bir rota daha uzun beklemekle ayıklanamaz ve hiç ana bilgisayar olmamış bir adres daha iyi bir ping ile onarılamaz.