Ping til IPv6-göngunarjafningja mistekst? Athugaðu ::-vistfangið

Annar endi IPv6-gangnamannsins þíns pingar hinn, og aðeins ein stefna svarar nokkurn tíma. Tengifatið er uppi, leiðin lítur rétt út, og ekkert í annálnum skýrir það. Vistfangið sem þú úthlutaðir er anycast-vistfang undirnetsleiðsögumanns, sem er alls ekki hýsilvistfang, og á tengingu með tveimur endapunktum hefur það nákvæmlega einn afhendingarmarkmið: sendandann. Ekkert tímamörkagildi laga þetta, því vistfangið gerir ekki það sem þú heldur.

Einkennið sem bendir á vistfangið

Sérhver hýsill á tengingunni svarar nema sá sem hefur auðkenni tengifatar allt núll. Pakki sem er beint á það form er af hendi viðurkenningu afhentur leiðsögumanni í undirnetinu, svo á punkt-til-punkt göngum kemur hann aftur til vélarinnar sem sendi hann. Frá fjarlæga endanum er þetta lesið sem óaðgengilegur jafningi; frá nálæga endanum sem þögn. Skiptu út öðru auðkenni úr sama forskeyti og einkennið hverfur án nokkurrar annarrar breytingar, og það er staðfestingin sem þarf að fá áður en leiðunum er snert.

Auðkennið með öllum núllum er frátekið sem anycast

RFC 4291 heldur auðkenni tengifatar með öllum núllum sem anycast-vistfangi undirnetsleiðsögumanns, svo /64 eins og 2001:db8:4a::/64 inniheldur engan nothæfan hýsil á 2001:db8:4a::. Frátekið á skilið sinn stað: leiðsögumannatilkynningar og uppgötvun nágranna beina sér að því formi, og leiðsögumaður svarar fyrir forskeytið sem hann þjónar. Að úthluta því gildi til gangnaendapunkts gefur blaði leiðsögumannshlutverk, og þess vegna kemur ekkert til baka. Hvaða annað auðkenni sem er í forskeytinu virkar sem hýsill, svo lagfæringin er venjulega ein tala.

Líttu á frátekið sem hlutverk sem þú hefur ekki rétt til að gegna frá gangnaendapunkti, frekar en sem sérvisku sem á að komast hjá með leið.

Úthlutaðu hýsilvistföngum og beindu forskeytinu

Veldu ::1 og ::2 fyrir endana tvo, bættu við einu með ip -6 addr add 2001:db8:4a::2/64 dev tun0, og beindu síðan fjarlæga forskeytinu í stað þess að reyna að veita því vistfang. Leið fyrir 2001:db8:4a::/64 út um göngin gerir fjarlægu hliðina aðgengilega; vistfangið eitt og sér gerir aðeins staðbundna tengifatið stillt.

Fyrir full göng er þriðja skref, sjálfgefin leið fyrir alþjóðlegt unicast um tækið, sem er IPv6-ígildi þess að senda allt inn í göngin. Slepptu því og IPv6 heldur áfram að nota líkamlegu tenginguna meðan IPv4 ferðast inni í göngunum, svo hýsillinn lekur nákvæmlega þeim umferð sem þú hélt að væri þakin. Staðfestu með ip -6 route get 2001:4860:4860::8888 og lestu hvaða tæki það nefnir í stað þess að gera ráð fyrir svarinu.

Multicast er hafnað fyrir leiðsögn

Android staðfestir vistföng og leiðir fyrir VpnService.Builder gegnum LinkAddress, og sá smiður hafnar multicast algjörlega. Gefðu honum multicast-forskeyti sem leið og niðurstaðan er bilun í slæmum LinkAddress-færibreytum í stað leiðar, sem er svar staðfestingar en ekki netkerfis. Hafnanir passar við miðilinn: punkt-til-punkt tun-tæki hefur ekkert multicast á tengilagi, svo hópleið á því hefur ekkert afhendingarlíkan til að setja upp. Hópvistföng eru búin til og notuð af staflanum sjálfum í stað þess að vera stillt handvirkt.

IPv6 all-nodes og solicited-node vistföng falla undir sömu reglu. Tengifatið ber þau því staflinn setti þau þangað, ekki því stefna ætlaði þau.

Hvað göng geta borið í staðinn

multicast-uppgötvun yfir göng krefst lags sem skilur hópaðild: TAP-brú sem sýnir Ethernet-hluta, endurvarp á forritastigi eða leiðsögnarsamskiptareglur sem sagt er skýrt við hvaða jafningja eigi að endurtaka. Ekkert af þessu er til í VpnService-líkaninu, þar sem forritið les og skrifar pakka og hefur ekkert kall sem gengur í hóp fyrir göngin. Annaðhvort bætirðu við íhlutnum sem skilur hópa eða tekur kröfuna út úr hönnuninni.

Unicast, hins vegar, þarf ekkert umfram vistföngin og leiðirnar hér að ofan, og þess vegna er venjulega gert ráð fyrir að göng beri það og svo er þeim kennt um þegar uppgötvunarsamskiptareglur mistakast.

Þrjár athuganir áður en þú úthlutar einhverju

Staðfestu að vistfangið sé ekki anycast-formið, staðfestu að það sé ekki multicast og staðfestu að forskeytið sé beint og ekki bara úthlutað tækinu. Sendu síðan prófið þitt á áfangastað sem er raunverulegur hýsill, því ping beint á anycast-vistfangið mælir sendandann og segir ekkert um slóðina. Haltu þessum þremur athugunum í breytingaskránni svo næsta uppsetning uppgötvi þær ekki aftur.

Leið sem kerfið setti aldrei upp er ekki hægt að kemba með því að bíða lengur, og vistfang sem var aldrei hýsill er ekki hægt að laga með betra pingi.