Ping na partnerský koniec IPv6 tunela zlyháva? Skontrolujte adresu ::

Jeden koniec vášho IPv6 tunela pinguje druhý a odpovie vždy len jeden smer. Rozhranie je hore, trasa vyzerá správne a v logu to nič nevysvetľuje. Adresa, ktorú ste priradili, je adresa subnet-router anycast, ktorá vôbec nie je adresou hostiteľa, a na spoji s dvoma koncami má presne jeden cieľ doručenia: odosielateľa. Žiadna hodnota časového limitu to nenapraví, pretože adresa nerobí to, čo si myslíte, že robí.

Príznak, ktorý ukazuje na adresu

Každý hostiteľ na spoji odpovedá okrem toho, ktorého identifikátor rozhrania sú samé nuly. Paket adresovaný tomuto tvaru sa podľa definície doručí routeru v podsieti, takže na tuneli typu bod-bod sa vráti stroju, ktorý ho odoslal. Z opačného konca to vyzerá ako nedostupný partner; z blízkeho konca ako ticho. Vymeňte identifikátor za iný z toho istého prefixu a príznak zmizne bez akejkoľvek inej zmeny, čo je potvrdenie, ktoré treba získať pred tým, než sa dotknete trás.

Identifikátor so všetkými nulami je vyhradený ako anycast

RFC 4291 ponecháva identifikátor rozhrania so všetkými nulami ako adresu subnet-router anycast, takže /64 ako 2001:db8:4a::/64 neobsahuje žiadneho použiteľného hostiteľa na 2001:db8:4a::. Toto vyhradenie má svoj zmysel: router advertisements a neighbour discovery sa obracajú na tento tvar a router odpovedá za prefix, ktorý obsluhuje. Priradenie tejto hodnoty koncu tunela odovzdá úlohu routera listu, a preto sa nič nevráti. Akýkoľvek iný identifikátor v prefixe funguje ako hostiteľ, takže oprava je zvyčajne jedna číslica.

Berte toto vyhradenie ako rolu, ktorú z konca tunela nemáte právo zaujať, nie ako zvláštnosť, ktorú treba obísť trasou.

Priraďte adresy hostiteľov a smerujte prefix

Vyberte ::1 a ::2 pre oba konce, jeden pridajte pomocou ip -6 addr add 2001:db8:4a::2/64 dev tun0 a potom smerujte vzdialený prefix namiesto toho, aby ste sa ho snažili adresovať. Trasa pre 2001:db8:4a::/64 von z tunela sprístupní vzdialenú stranu; samotná adresa len nastaví lokálne rozhranie.

Pre úplný tunel existuje tretí krok, predvolená trasa pre globálny unicast cez zariadenie, čo je ekvivalent IPv6 toho, ako poslať všetko do tunela. Ak ho vynecháte, IPv6 naďalej používa fyzické rozhranie, zatiaľ čo IPv4 cestuje vnútri tunela, takže hostiteľ prepúšťa presne tú prevádzku, o ktorej ste si mysleli, že je pokrytá. Potvrďte pomocou ip -6 route get 2001:4860:4860::8888 a prečítajte si, ktoré zariadenie uvádza, namiesto toho, aby ste predpokladali odpoveď.

Multicast sa odmietne pred smerovaním

Android overuje adresy a trasy pre VpnService.Builder cez LinkAddress a tento konštruktor multicast rovno odmieta. Ak mu ako trasu podáte multicastový prefix, výsledkom je zlyhanie bad LinkAddress parameters, nie trasa, čo je odpoveď overenia a nie odpoveď siete. Odmietnutie zodpovedá médiu: tunelové zariadenie typu bod-bod nemá link-layer multicast, takže skupinová trasa na ňom nemá žiadny model doručenia, ktorý by sa dal nainštalovať. Skupinové adresy vytvára a spotrebúva samotný zásobník, nie sú konfigurované ručne.

IPv6 adresy all-nodes a solicited-node spadajú pod to isté pravidlo. Rozhranie ich nesie preto, lebo ich tam vložil zásobník, nie preto, že by ich zamýšľala nejaká politika.

Čo môže tunel prenášať namiesto toho

Presun multicastového objavovania cez tunel si vyžaduje vrstvu, ktorá rozumie členstvu v skupine: TAP most, ktorý predstavuje Ethernet segment, relay na úrovni aplikácie alebo smerovací protokol, ktorému sa výslovne povie, ku ktorým partnerom replikovať. Nič z toho v modeli VpnService neexistuje, kde aplikácia číta a zapisuje pakety a nemá volanie, ktoré by pripojilo skupinu pre tunel. Buď pridajte komponent, ktorý skupinám rozumie, alebo požiadavku z návrhu vypustite.

Unicast naopak nepotrebuje nič viac nad rámec adries a trás vyššie, a preto sa od tunelov zvyčajne očakáva, že ho prenesú, a potom sa obviňujú, keď zlyhá protokol objavovania.

Tri kontroly predtým, než niečo priradíte

Potvrďte, že adresa nie je anycast tvar, potvrďte, že nie je multicast, a potvrďte, že prefix je smerovaný a nie len priradený zariadeniu. Potom pošlite test na cieľ, ktorý je skutočným hostiteľom, pretože ping namierený na anycast adresu meria odosielateľa a o ceste vám nič nepovie. Tieto tri kontroly si zapíšte do záznamu o zmene, aby ich nasledujúce nasadenie nemuselo znovu objavovať.

Trasu, ktorú platforma nikdy nenainštalovala, nemožno odladiť dlhším čakaním a adresu, ktorá nikdy nebola hostiteľom, nemožno opraviť lepším pingom.