Ping al via IPv6-tunela samtavolano malsukcesas? Kontrolu la adreson ::

Unu fino de via IPv6-tunelo pingas la alian, kaj nur unu direkto iam ajn respondas. La interfaco estas aktiva, la itinero ŝajnas ĝusta, kaj nenio en la protokolo klarigas tion. La adreso, kiun vi asignis, estas la subnet-router anycast-adreso, kiu tute ne estas hosta adreso, kaj sur ligilo kun du finpunktoj ĝi havas precize unu celon de livero: la sendinto. Neniu tempolima valoro riparas tion, ĉar la adreso ne faras tion, kion vi pensas.

La simptomo, kiu montras al la adreso

Ĉiu hosto sur la ligilo respondas krom tiu, kies interfaca identigilo estas ĉiuj nuloj. Paketo adresita al tiu formo estas liverita laŭdifine al enkursigilo en la subreto, do sur punkto-al-punkto-tunelo ĝi revenas al la maŝino, kiu sendis ĝin. De la malproksima fino tio legiĝas kiel neatingebla samtavolano; de la proksima fino kiel silento. Anstataŭigu per alia identigilo el la sama prefikso kaj la simptomo malaperas sen ia ajn alia ŝanĝo, kaj tio estas la konfirmo, kiun oni devas akiri antaŭ ol tuŝi itinerojn.

La identigilo el ĉiuj nuloj estas rezervita kiel anycast

RFC 4291 konservas la interfacan identigilon el ĉiuj nuloj kiel la subnet-router anycast-adreson, do /64 kiel 2001:db8:4a::/64 enhavas neniun uzeblan hoston ĉe 2001:db8:4a::. La rezervo meritas sian lokon: enkursigilaj anoncoj kaj najbara malkovro adresas tiun formon, kaj enkursigilo respondas por la prefikso, kiun ĝi servas. Asigni tiun valoron al tunela finpunkto donas enkursigilan rolon al folio, kaj tial nenio revenas. Ĉiu alia identigilo en la prefikso funkcias kiel hosto, do la riparo estas kutime unu cifero.

Traktu la rezervon kiel rolon, kiun vi ne rajtas okupi de tunela finpunkto, prefere ol kiel kapricon por ĉirkaŭiri per itinero.

Asignu hostajn adresojn kaj enkursigu la prefikson

Elektu ::1 kaj ::2 por la du finoj, aldonu unu per ip -6 addr add 2001:db8:4a::2/64 dev tun0, kaj poste enkursigu la foran prefikson anstataŭ provi adresi ĝin. Itinero por 2001:db8:4a::/64 el la tunelo faras la foran flankon atingebla; la adreso sola nur faras la lokan interfacon agordita.

Por plena tunelo estas tria paŝo, defaŭlta itinero por tutmonda unicast tra la aparato, kio estas la IPv6-ekvivalento de sendi ĉion en la tunelon. Se vi preterlasos ĝin, IPv6 daŭre uzos la fizikan ligilon dum IPv4 vojaĝas ene de la tunelo, do la hosto likas precize tiun trafikon, kiun vi kredis kovrita. Konfirmu per ip -6 route get 2001:4860:4860::8888 kaj legu, kiun aparaton ĝi nomas, anstataŭ supozi la respondon.

Multicast estas rifuzata antaŭ enkursigado

Android validigas adresojn kaj itinerojn por VpnService.Builder per LinkAddress, kaj tiu konstruilo rifuzas multicast tute rekte. Donu al ĝi multicast-prefikson kiel itineron kaj la rezulto estas malsukceso de malbonaj LinkAddress-parametroj anstataŭ itinero, kio estas respondo de validigo kaj ne de reto. La rifuzo kongruas kun la mediumo: punkto-al-punkto tun-aparato ne havas ligiltavolan multicast, do grupa itinero sur ĝi ne havas liveran modelon por instali. Grupaj adresoj estas kreataj kaj konsumataj de la stako mem anstataŭ agordataj mane.

IPv6 all-nodes kaj solicited-node adresoj falas sub la sama regulo. La interfaco portas ilin ĉar la stako metis ilin tie, ne ĉar politiko intencis ilin.

Kion tunelo povas porti anstataŭe

Movi multicast-malkovron tra tunelo bezonas tavolon, kiu komprenas grupan membrecon: TAP-ponto prezentanta Ethernet-segmenton, relajso ĉe aplikada nivelo aŭ enkursiga protokolo, al kiu estas eksplicite dirite, al kiuj samtavolanoj repliki. Nenio el tio ekzistas en la VpnService-modelo, kie la aplikaĵo legas kaj skribas paketojn kaj havas neniun alvokon, kiu aliĝas al grupo por la tunelo. Aŭ aldonu la komponenton, kiu komprenas grupojn, aŭ forĵetu la postulon el la dezajno.

Unicast, kontraste, bezonas nenion plian preter la adresoj kaj itineroj supre, tial oni kutime atendas, ke tuneloj portos ĝin, kaj poste oni kulpigas ilin, kiam malkovra protokolo malsukcesas.

Tri kontroloj antaŭ ol vi asignos ion ajn

Konfirmu, ke la adreso ne estas la anycast-formo, konfirmu, ke ĝi ne estas multicast, kaj konfirmu, ke la prefikso estas enkursigita kaj ne nur asignita al la aparato. Poste sendu vian teston al celloko, kiu estas reala hosto, ĉar ping direktita al la anycast-adreso mezuras la sendinton kaj diras nenion pri la vojo. Tenu tiujn tri kontrolojn en la ŝanĝprotokolo, por ke la sekva deplojo ne remalkovru ilin.

Itinero, kiun la platformo neniam instalis, ne povas esti sencimigita per pli longa atendo, kaj adreso, kiu neniam estis hosto, ne povas esti riparita per pli bona ping.