Ping-ul către partenerul tunelului IPv6 eșuează? Verificați adresa ::

Un capăt al tunelului IPv6 face ping către celălalt, iar răspunde mereu doar o singură direcție. Interfața este activă, ruta pare corectă și nimic din jurnal nu explică asta. Adresa pe care ați atribuit-o este adresa anycast a routerului de subrețea, care nu este deloc o adresă de host, iar pe o legătură cu două capete are exact o singură țintă de livrare: expeditorul. Nicio valoare de timeout nu repară asta, pentru că adresa nu face ceea ce credeți.

Simptomul care indică adresa

Fiecare host de pe legătură răspunde, cu excepția celui al cărui identificator de interfață este tot zero. Un pachet adresat acelei forme este livrat prin definiție unui router din subrețea, așa că pe un tunel punct-la-punct se întoarce la mașina care l-a trimis. De la capătul îndepărtat se citește ca un partener inaccesibil; de la capătul apropiat ca tăcere. Înlocuiți cu alt identificator din același prefix și simptomul dispare fără nicio altă modificare, iar aceasta este confirmarea care trebuie obținută înainte de a atinge rutele.

Identificatorul tot zero este rezervat ca anycast

RFC 4291 păstrează identificatorul de interfață tot zero ca adresă anycast a routerului de subrețea, așa că un /64 precum 2001:db8:4a::/64 nu conține niciun host utilizabil la 2001:db8:4a::. Rezervarea își merită locul: anunțurile de router și descoperirea vecinilor adresează acea formă, iar un router răspunde pentru prefixul pe care îl servește. Atribuirea acelei valori unui capăt de tunel dă un rol de router unei frunze, și de aceea nu se întoarce nimic. Orice alt identificator din prefix funcționează ca host, așa că reparația este de obicei o cifră.

Tratați rezervarea ca pe un rol pe care nu aveți dreptul să îl ocupați de la un capăt de tunel, nu ca pe o ciudățenie de ocolit printr-o rută.

Atribuiți adrese de host și rutați prefixul

Alegeți ::1 și ::2 pentru cele două capete, adăugați unul cu ip -6 addr add 2001:db8:4a::2/64 dev tun0, apoi rutați prefixul îndepărtat în loc să încercați să îl adresați. O rută pentru 2001:db8:4a::/64 prin tunel face partea îndepărtată accesibilă; adresa singură doar configurează interfața locală.

Pentru un tunel complet există un al treilea pas, o rută implicită pentru unicast global prin dispozitiv, care este echivalentul IPv6 al trimiterii tuturor în tunel. Dacă îl omiteți, IPv6 continuă să folosească legătura fizică în timp ce IPv4 călătorește în tunel, așa că hostul scapă exact traficul pe care credeați că este acoperit. Confirmați cu ip -6 route get 2001:4860:4860::8888 și citiți ce dispozitiv numește în loc să presupuneți răspunsul.

Multicast este refuzat înainte de rutare

Android validează adrese și rute pentru VpnService.Builder prin LinkAddress, iar acel constructor refuză multicast dintr-o dată. Dați-i un prefix multicast ca rută și rezultatul este o eroare de parametri LinkAddress proști în loc de o rută, ceea ce este un răspuns de validare și nu de rețea. Refuzul corespunde mediului: un dispozitiv tun punct-la-punct nu are multicast la nivel de legătură, așa că o rută de grup pe el nu are model de livrare de instalat. Adresele de grup sunt create și consumate de stiva însăși în loc să fie configurate manual.

Adresele IPv6 all-nodes și solicited-node intră sub aceeași regulă. Interfața le poartă pentru că stiva le-a pus acolo, nu pentru că o politică le-ar fi intenționat.

Ce poate transporta un tunel în schimb

mutarea descoperirii multicast prin tunel necesită un strat care înțelege apartenența la grup: un pod TAP care prezintă un segment Ethernet, un releu la nivel de aplicație sau un protocol de rutare căruia i se spune explicit către ce parteneri să replice. Nimic din toate acestea nu există în modelul VpnService, unde aplicația citește și scrie pachete și nu are niciun apel care să se alăture unui grup pentru tunel. Fie adăugați componenta care înțelege grupurile, fie scoateți cerința din proiect.

Unicast, dimpotrivă, nu necesită nimic în plus față de adresele și rutele de mai sus, de aceea de obicei se așteaptă ca tunelele să îl transporte și apoi sunt învinuite când un protocol de descoperire eșuează.

Trei verificări înainte de a atribui ceva

Confirmați că adresa nu este forma anycast, că nu este multicast și că prefixul este rutat, nu doar atribuit dispozitivului. Apoi trimiteți testul către o destinație care este un host real, pentru că un ping îndreptat spre adresa anycast măsoară expeditorul și nu spune nimic despre cale. Păstrați cele trei verificări în registrul de modificări, ca următoarea implementare să nu le redescopere.

O rută pe care platforma nu a instalat-o niciodată nu poate fi depanată așteptând mai mult, iar o adresă care nu a fost niciodată host nu poate fi reparată cu un ping mai bun.