Ping na nasprotni konec tunela IPv6 ne uspe? Preverite naslov ::

En konec vašega tunela IPv6 pošilja ping na drugega, odgovori pa vedno le ena smer. Vmesnik je aktiven, pot je videti pravilna in v dnevniku ni ničesar, kar bi to pojasnilo. Naslov, ki ste ga dodelili, je naslov subnet-router anycast, ki sploh ni naslov gostitelja, in ima na povezavi z dvema koncema natanko en cilj dostave: pošiljatelja. Nobena vrednost časovne omejitve tega ne popravi, ker naslov ne dela tega, kar mislite, da dela.

Znak, ki kaže na naslov

Vsak gostitelj na povezavi odgovori, razen tistega, katerega identifikator vmesnika so same ničle. Paket, naslovljen na to obliko, se po definiciji dostavi usmerjevalniku v podomrežju, zato se na tunelu od točke do točke vrne stroju, ki ga je poslal. Z oddaljenega konca je to videti kot nedosegljiv partner; z bližnjega kot molk. Zamenjajte identifikator z drugim iz iste predpone in znak izgine brez druge spremembe, kar je potrditev, ki jo je treba dobiti, preden se dotaknete poti.

Identifikator samih ničel je rezerviran za anycast

RFC 4291 ohranja identifikator vmesnika samih ničel kot naslov subnet-router anycast, zato /64, kot je 2001:db8:4a::/64, ne vsebuje nobenega uporabnega gostitelja na 2001:db8:4a::. Rezervacija ima svoj smisel: router advertisements in neighbour discovery naslavljata to obliko, usmerjevalnik pa odgovarja za predpono, ki jo streže. Če to vrednost dodelite koncu tunela, predate vlogo usmerjevalnika listu, zato se nič ne vrne. Kateri koli drug identifikator v predponi deluje kot gostitelj, zato je popravek običajno ena številka.

Rezervacijo obravnavajte kot vlogo, ki si je s konca tunela ne smete privoščiti, ne kot posebnost, ki bi jo obšli s potjo.

Dodelite naslove gostiteljev in usmerite predpono

Izberite ::1 in ::2 za oba konca, enega dodajte z ip -6 addr add 2001:db8:4a::2/64 dev tun0 in nato usmerite oddaljeno predpono, namesto da bi jo poskušali nasloviti. Pot za 2001:db8:4a::/64 iz tunela naredi oddaljeno stran dosegljivo; naslov sam le nastavi lokalni vmesnik.

Za polni tunel je potreben tretji korak, privzeta pot za globalni unicast skozi napravo, kar je ekvivalent IPv6 temu, da vse pošljete v tunel. Če ga izpustite, IPv6 še naprej uporablja fizično povezavo, medtem ko IPv4 potuje znotraj tunela, zato gostitelj pušča natanko tisti promet, za katerega ste mislili, da je pokrit. Potrdite z ip -6 route get 2001:4860:4860::8888 in preberite, katero napravo navaja, namesto da bi odgovor predpostavili.

Multicast se zavrne pred usmerjanjem

Android preverja naslove in poti za VpnService.Builder prek LinkAddress in ta konstruktor multicast kar zavrne. Če mu kot pot podate multicastno predpono, je rezultat napaka bad LinkAddress parameters in ne pot, kar je odgovor preverjanja in ne odgovor omrežja. Zavrnitev ustreza mediju: tunelska naprava od točke do točke nima link-layer multicasta, zato skupinska pot na njej nima nobenega modela dostave, ki bi ga bilo mogoče namestiti. Skupinske naslove ustvarja in porablja sam sklad, ne nastavljajo se ročno.

Naslova IPv6 all-nodes in solicited-node spadata pod isto pravilo. Vmesnik ju nosi zato, ker ju je tja vstavil sklad, ne zato, ker bi ju predvidela kakšna politika.

Kaj lahko tunel prenaša namesto tega

Premik multicastnega odkrivanja čez tunel potrebuje plast, ki razume članstvo v skupini: most TAP, ki predstavlja segment Ethernet, posredovalnik na ravni aplikacije ali usmerjevalni protokol, ki mu je izrecno povedano, katerim partnerjem naj replikira. Nič od tega ne obstaja v modelu VpnService, kjer aplikacija bere in piše pakete in nima klica, ki bi skupino pridružil tunelu. Bodisi dodajte komponento, ki skupine razume, bodisi zahtevo iz načrta opustite.

Unicast, nasprotno, ne potrebuje ničesar več onkraj zgornjih naslovov in poti, zato se od tunelov običajno pričakuje, da ga prenašajo, in se nato krivijo, ko odpove protokol odkrivanja.

Tri preverjanja, preden kar koli dodelite

Potrdite, da naslov ni oblika anycast, potrdite, da ni multicast, in potrdite, da je predpona usmerjena in ne le dodeljena napravi. Nato pošljite test na cilj, ki je resničen gostitelj, ker ping na anycast naslov meri pošiljatelja in o poti ne pove ničesar. Ta tri preverjanja zapišite v evidenco sprememb, da jih naslednja namestitev ne bo odkrivala znova.

Poti, ki je platforma ni nikoli namestila, ni mogoče odpraviti z daljšim čakanjem, in naslova, ki nikoli ni bil gostitelj, ni mogoče popraviti z boljšim pingom.