Ping na protějšek IPv6 tunelu selhává? Zkontrolujte adresu ::

Jeden konec vašeho IPv6 tunelu pinguje druhý a odpovídá vždy jen jeden směr. Rozhraní je aktivní, trasa vypadá správně a nic v logu to nevysvětluje. Adresa, kterou jste přiřadili, je anycast adresa směrovače podsítě, což není adresa hostitele, a na spoji se dvěma koncovými body má přesně jeden cíl doručení: odesílatele. Žádná hodnota časového limitu to nespraví, protože adresa nedělá to, co si myslíte.

Příznak, který ukazuje na adresu

Každý hostitel na spoji odpovídá kromě toho, jehož identifikátor rozhraní je samé nuly. Paket adresovaný na tento tvar se podle definice doručí směrovači v podsíti, takže na tunelu bod-bod se vrací ke stroji, který ho odeslal. Z vzdáleného konce se to čte jako nedostupný protějšek; z blízkého konce jako ticho. Vyměňte identifikátor za jiný ze stejného prefixu a příznak zmizí bez jakékoli další změny, a to je potvrzení, které je třeba získat, než se dotknete tras.

Identifikátor ze samých nul je rezervován jako anycast

RFC 4291 zachovává identifikátor rozhraní ze samých nul jako anycast adresu směrovače podsítě, takže /64 jako 2001:db8:4a::/64 neobsahuje žádného použitelného hostitele na adrese 2001:db8:4a::. Rezervace má své opodstatnění: oznámení směrovače a objevování sousedů adresují tento tvar a směrovač odpovídá za prefix, který obsluhuje. Přiřazení této hodnoty koncovému bodu tunelu dává listu roli směrovače, a proto se nic nevrací. Jakýkoli jiný identifikátor v prefixu funguje jako hostitel, takže oprava je obvykle jedna číslice.

Berte rezervaci jako roli, kterou z koncového bodu tunelu nemáte právo zastávat, ne jako zvláštnost, kterou obejdete trasou.

Přiřaďte adresy hostitelů a směrujte prefix

Vyberte ::1 a ::2 pro oba konce, jeden přidejte pomocí ip -6 addr add 2001:db8:4a::2/64 dev tun0, a pak směrujte vzdálený prefix, místo abyste se ho snažili adresovat. Trasa pro 2001:db8:4a::/64 tunelem zpřístupní vzdálenou stranu; samotná adresa jen nakonfiguruje místní rozhraní.

U plného tunelu je tu třetí krok, výchozí trasa pro globální unicast přes zařízení, což je IPv6 ekvivalent poslání všeho do tunelu. Vynechejte ho a IPv6 dál používá fyzické spojení, zatímco IPv4 putuje uvnitř tunelu, takže hostitel uniká právě ten provoz, o kterém jste mysleli, že je pokrytý. Potvrďte pomocí ip -6 route get 2001:4860:4860::8888 a přečtěte, které zařízení uvádí, místo abyste odpověď předpokládali.

Multicast se odmítá před směrováním

Android validuje adresy a trasy pro VpnService.Builder přes LinkAddress, a tento konstruktor multicast rovnou odmítá. Dejte mu multicast prefix jako trasu a výsledkem je selhání špatných parametrů LinkAddress místo trasy, což je odpověď validace, ne sítě. Odmítnutí odpovídá médiu: zařízení tun bod-bod nemá multicast na linkové vrstvě, takže skupinová trasa na něm nemá model doručení, který by šel nainstalovat. Skupinové adresy vytváří a spotřebovává sám stack, nekonfigurují se ručně.

Adresy IPv6 all-nodes a solicited-node spadají pod stejné pravidlo. Rozhraní je nese proto, že je tam stack dal, ne proto, že je zamýšlela politika.

Co může tunel nést místo toho

Přesun multicastového objevování tunelem vyžaduje vrstvu, která rozumí členství ve skupinách: TAP most představující Ethernet segment, přenos na aplikační úrovni nebo směrovací protokol, kterému je výslovně řečeno, kterým protějškům replikovat. Nic z toho v modelu VpnService neexistuje, kde aplikace čte a píše pakety a nemá volání, které by se pro tunel připojilo ke skupině. Buď přidejte komponentu, která skupinám rozumí, nebo požadavek z návrhu vypusťte.

Unicast naopak nepotřebuje nic navíc kromě adres a tras výše, a proto se od tunelů obvykle očekává, že ho ponesou, a pak jsou obviňovány, když protokol objevování selže.

Tři kontroly, než cokoli přiřadíte

Potvrďte, že adresa není anycast tvar, potvrďte, že není multicast, a potvrďte, že prefix je směrován, ne jen přiřazen zařízení. Pak pošlete test na cíl, který je skutečný hostitel, protože ping namířený na anycast adresu měří odesílatele a o cestě neříká nic. Uchovejte tyto tři kontroly v záznamu změn, aby je příští nasazení znovu neobjevilo.

Trasu, kterou platforma nikdy nenainstalovala, nelze ladit delším čekáním, a adresu, která nikdy nebyla hostitelem, nelze opravit lepším pingem.