Ping kwa upande mwingine wa handaki yako ya IPv6 inashindikana? Angalia anwani ::

Upande mmoja wa handaki yako ya IPv6 hupiga ping upande mwingine, na ni mwelekeo mmoja tu unaojibu kila wakati. Kiolesura kiko juu, njia inaonekana sawa, na hakuna kitu kwenye kumbukumbu kinachoeleza hilo. Anwani uliyoweka ni anwani ya subnet-router anycast, ambayo si anwani ya mwenyeji hata kidogo, na kwenye kiungo cha ncha mbili ina lengo moja tu la uwasilishaji: mtumaji. Hakuna thamani ya muda wa kusubiri inayotengeneza hilo, kwa sababu anwani haifanyi kile unachofikiri inafanya.

Dalili inayoelekeza kwenye anwani

Kila mwenyeji kwenye kiungo hujibu isipokuwa yule ambaye kitambulisho chake cha kiolesura ni sufuri tupu. Kifurushi kinachoelekezwa kwenye umbo hilo huwasilishwa kwa kipanga njia kwenye subnet kwa ufafanuzi, kwa hiyo kwenye handaki ya ncha mbili hurudi kwenye mashine iliyokituma. Kutoka upande wa mbali hii husomeka kama mwenza asiyefikiwa; kutoka upande wa karibu husomeka kama ukimya. Badilisha kitambulisho kingine kutoka kiambishi awali kimoja na dalili hutoweka bila mabadiliko mengine yoyote, na hiyo ndiyo uthibitisho unaopaswa kupatikana kabla ya kugusa njia.

Kitambulisho cha sufuri zote kimehifadhiwa kama anycast

RFC 4291 huhifadhi kitambulisho cha kiolesura cha sufuri zote kama anwani ya subnet-router anycast, kwa hiyo /64 kama 2001:db8:4a::/64 haina mwenyeji anayeweza kutumika kwenye 2001:db8:4a::. Uhifadhi huo una nafasi yake: router advertisements na neighbour discovery huelenga umbo hilo, na kipanga njia hujibu kwa kiambishi awali kinachohudumiwa. Kuweka thamani hiyo kwenye ncha ya handaki humpa jani jukumu la kipanga njia, na ndiyo sababu hakuna kinachorudi. Kitambulisho kingine chochote kwenye kiambishi awali hufanya kazi kama mwenyeji, kwa hiyo matengenezo kwa kawaida ni tarakimu moja.

Chukulia uhifadhi huo kama jukumu usilostahili kulichukua kutoka ncha ya handaki, si kama hali ya kipekee ya kuepuka kwa njia.

Weka anwani za wenyeji na uelekeze kiambishi awali

Chagua ::1 na ::2 kwa ncha mbili, ongeza moja kwa ip -6 addr add 2001:db8:4a::2/64 dev tun0, kisha uelekeze kiambishi awali cha mbali badala ya kujaribu kukipa anwani. Njia ya 2001:db8:4a::/64 kutoka kwenye handaki huifanya upande wa mbali ufikike; anwani peke yake huweka kiolesura cha ndani tu.

Kwa handaki kamili kuna hatua ya tatu, njia chaguo-msingi ya unicast ya kimataifa kupitia kifaa, ambayo ni sawa na IPv6 ya kutuma kila kitu ndani ya handaki. Ukiruka hiyo, IPv6 huendelea kutumia kiungo halisi wakati IPv4 inasafiri ndani ya handaki, kwa hiyo mwenyeji huvujisha hasa trafiki uliyodhani imefunikwa. Thibitisha kwa ip -6 route get 2001:4860:4860::8888 na usome kifaa kinachotajwa badala ya kudhani jibu.

Multicast inakataliwa kabla ya uelekezaji

Android huthibitisha anwani na njia za VpnService.Builder kupitia LinkAddress, na kijenzi hicho hukataa multicast moja kwa moja. Ikipewa kiambishi awali cha multicast kama njia, matokeo ni hitilafu ya bad LinkAddress parameters badala ya njia, jibu la uthibitishaji na si la mtandao. Kukataa kunalingana na kiungo: kifaa cha tun cha ncha mbili hakina multicast ya tabaka la kiungo, kwa hiyo njia ya kikundi juu yake haina mfumo wa uwasilishaji wa kusakinisha. Anwani za vikundi huundwa na kutumiwa na stack yenyewe badala ya kusanidiwa kwa mkono.

Anwani za IPv6 all-nodes na solicited-node ziko chini ya sheria hiyo hiyo. Kiolesura huzibeba kwa sababu stack iliweka hapo, si kwa sababu sera fulani ilikusudia.

Kile handaki inaweza kubeba badala yake

Kuhamisha ugunduzi wa multicast kupitia handaki kunahitaji tabaka linaloelewa uanachama wa kikundi: daraja la TAP linalowasilisha sehemu ya Ethernet, relay ya kiwango cha programu, au itifaki ya uelekezaji inayoambiwa wazi ni wenzi gani wa kuiga. Hakuna hivyo kwenye mfumo wa VpnService, ambapo programu husoma na kuandika vifurushi na haina mwito unaojiunga na kikundi kwa handaki. Ama ongeza kijenzi kinachoelewa vikundi au uondoe hitaji hilo kwenye muundo.

Unicast, kinyume chake, haihitaji chochote zaidi ya anwani na njia zilizo juu, ndiyo sababu handaki kwa kawaida hutarajiwa kuibeba na kisha hulaumiwa itifaki ya ugunduzi inaposhindikana.

Ukaguzi watatu kabla ya kuweka chochote

Thibitisha kuwa anwani si umbo la anycast, thibitisha kuwa si multicast, na thibitisha kuwa kiambishi awali kimeelekezwa na si kupewa kifaa tu. Kisha tuma jaribio lako kwenye lengo ambalo ni mwenyeji halisi, kwa sababu ping inayolenga anwani ya anycast hupima mtumaji na haisemi chochote kuhusu njia. Andika ukaguzi hao watatu kwenye kumbukumbu ya mabadiliko ili usambazaji unaofuata usiugundue tena.

Njia ambayo jukwaa halikuwahi kusakinisha haiwezi kutatuliwa kwa kusubiri zaidi, na anwani ambayo haikuwa mwenyeji kamwe haiwezi kutengenezwa kwa ping bora zaidi.