IPv6 tunelio partnerio ping nepavyksta? Patikrinkite :: adresą

Vienas IPv6 tunelio galas pingina kitą, ir visada atsako tik viena kryptis. Sąsaja įjungta, maršrutas atrodo teisingai, ir niekas žurnale to nepaaiškina. Adresas, kurį priskyrėte, yra potinklio maršrutizatoriaus anycast adresas, kuris visiškai nėra hosto adresas, o dviejų galų jungtyje jis turi lygiai vieną pristatymo tikslą: siuntėją. Jokia laukimo reikšmė to nesutaiso, nes adresas nedaro to, ką manote.

Simptomas, kuris nurodo adresą

Kiekvienas jungties hostas atsako, išskyrus tą, kurio sąsajos identifikatorius yra vien nuliai. Į tą formą adresuotas paketas pagal apibrėžimą pristatomas potinklio maršrutizatoriui, todėl taškas-taškas tunelyje jis grįžta į mašiną, kuri jį išsiuntė. Iš tolimojo galo tai skaitoma kaip nepasiekiamas partneris; iš artimojo galo kaip tyla. Pakeiskite kitą to paties prefikso identifikatorių ir simptomas išnyksta be jokių kitų pakeitimų, ir tai yra patvirtinimas, kurį reikia gauti prieš liečiant maršrutus.

Visų nulių identifikatorius rezervuotas kaip anycast

RFC 4291 išlaiko visų nulių sąsajos identifikatorių kaip potinklio maršrutizatoriaus anycast adresą, todėl /64, pavyzdžiui, 2001:db8:4a::/64 neturi jokio naudojamo hosto adresu 2001:db8:4a::. Rezervacija užsitarnauja savo vietą: maršrutizatoriaus skelbimai ir kaimynų aptikimas adresuoja tą formą, o maršrutizatorius atsako už prefiksą, kuriam tarnauja. To vertės priskyrimas tunelio galui suteikia lapui maršrutizatoriaus vaidmenį, ir todėl niekas negrįžta. Bet kuris kitas prefikso identifikatorius veikia kaip hostas, todėl pataisymas paprastai yra vienas skaitmuo.

Rezervaciją laikykite vaidmeniu, kurio neturite teisės užimti iš tunelio galo, o ne keistybe, kurią galima apeiti maršrutu.

Priskirkite hostų adresus ir maršrutizuokite prefiksą

Pasirinkite ::1 ir ::2 dviem galams, pridėkite vieną su ip -6 addr add 2001:db8:4a::2/64 dev tun0, o tada maršrutizuokite tolimą prefiksą, o ne bandykite jam suteikti adresą. Maršrutas į 2001:db8:4a::/64 per tunelį padaro tolimą pusę pasiekiamą; vien adresas tik sukonfigūruoja vietinę sąsają.

Pilnam tuneliui yra trečias žingsnis, numatytasis maršrutas pasauliniam unicast per įrenginį, kuris yra IPv6 atitikmuo siuntimo visko į tunelį. Jei jo nepraleisite, IPv6 toliau naudos fizinę jungtį, kol IPv4 keliaus tunelio viduje, todėl hostas nutekins būtent tą srautą, kurį manėte esant uždengtą. Patvirtinkite su ip -6 route get 2001:4860:4860::8888 ir perskaitykite, kurį įrenginį jis nurodo, o ne manykite atsakymą.

Multicast atmetamas prieš maršrutizavimą

Android tikrina VpnService.Builder adresus ir maršrutus LinkAddress pagalba, ir tas konstruktorius multicast atmeta tiesiogiai. Duokite jam multicast prefiksą kaip maršrutą ir rezultatas bus blogų LinkAddress parametrų klaida, o ne maršrutas, tai yra validacijos atsakymas, o ne tinklo. Atmetimas atitinka terpę: taškas-taškas tun įrenginys neturi jungties lygio multicast, todėl grupės maršrutas jame neturi pristatymo modelio, kurį būtų galima įdiegti. Grupės adresus kuria ir vartoja pati krūva, o ne konfigūruojami rankomis.

IPv6 all-nodes ir solicited-node adresai patenka į tą pačią taisyklę. Sąsaja juos neša todėl, kad krūva juos ten įdėjo, o ne todėl, kad politika jų numatė.

Ką tunelis gali nešti vietoj to

multicast aptikimo perkėlimas per tunelį reikalauja sluoksnio, kuris supranta grupės narystę: TAP tiltas, pateikiantis Ethernet segmentą, programos lygmens rele, arba maršrutizavimo protokolas, kuriam aiškiai pasakyta, kuriems partneriams dubliuoti. Niekas iš to neegzistuoja VpnService modelyje, kur programa skaito ir rašo paketus ir neturi kvietimo, kuris prisijungtų prie grupės tuneliui. Arba pridėkite komponentą, kuris supranta grupes, arba pašalinkite reikalavimą iš dizaino.

Unicast, priešingai, nereikalauja nieko papildomo be aukščiau nurodytų adresų ir maršrutų, todėl paprastai tikimasi, kad tuneliai jį neš, ir tada jie kaltinami, kai aptikimo protokolas sugenda.

Trys patikros prieš ką nors priskiriant

Patvirtinkite, kad adresas nėra anycast forma, kad jis nėra multicast, ir kad prefiksas maršrutizuotas, o ne tik priskirtas įrenginiui. Tada siųskite savo testą į paskirties vietą, kuri yra tikras hostas, nes ping į anycast adresą matuoja siuntėją ir nieko nesako apie kelią. Laikykite tas tris patikras pakeitimų įraše, kad kitas diegimas jų neaptiktų iš naujo.

Maršruto, kurio platforma niekada neįdiegė, negalima derinti ilgiau laukiant, o adreso, kuris niekada nebuvo hostas, negalima sutaisyti geresniu ping.