IPv6 tra IPv4 VPN-servilo ankoraŭ bezonas IPv6-eliron
Transporti IPv6 ene de IPv4-tunelo estas la facila duono. La eliro ankoraŭ bezonas veran IPv6-upstream, uzeblan fontprefikson kaj revenan itineron por la baseno.
La tunelo ekfunkcias, la kliento ricevas IPv6-adreson el la baseno, kaj tamen ĉiu IPv6-celo finiĝas per tempolimo. Nenio estas difektita en la tunelo: IPv6 veturas tute bone ene de la IPv4-transporto, kaj tio neniam estis la malfacila parto. La adreso, kiun vi donis, estas promeso, kiun la servilo ne povas plenumi, ĉar la eliro havas neniun IPv6-upstream, en kiun ĝi povus ĝin sendi. La riparo apartenas al la eliro, ne al la klienta profilo.
La simptomo: adreso sen vojo
Kontrolo ĉe la klienta flanko montras tutmonde aspektan IPv6-adreson sur la tunela aparato kaj itineron direktitan en ĝin, kaj pro tio ĉi tio estas mislegata kiel klienta fuŝo. Trafiko eniras la tunelon, la servilo malenkapsuligas ĝin, kaj poste la pako surteriĝas ĉe gastiganto, kies enkursiga tabelo havas neniun defaŭltan IPv6-itineron al iu ajn reala loko. Depende de la stako vi ricevas tujan neatingeblecon aŭ silentan forĵeton, kaj en ambaŭ kazoj la kliento vidas tempolimon, kiu aspektas idente al fajroŝirmilo.
Legi la propran enkursigan tabelon de la servilo antaŭ ol tuŝi la klienton, ĉar ĝuste tie loĝas la mankanta duono de la vojo. Servilo kun unu defaŭlta IPv4-itinero jam diris al vi la respondon.
Sekvu la pakon post malenkapsuligo
Ene de la tunelo la pako estas ordinara IPv6, kaj la adreso de la kliento estas ĝia fonto. La servilo forprenas la transportan enkapsuligon kaj tiam tenas denaskan IPv6-pakon, kiun oni devas plusendi al sekva IPv6-salto. Defaŭlta IPv4-itinero ne povas porti ĝin, kaj traduki ĝin al IPv4 estas alia funkcio, kiun neniu efektivigis. Tio estas la tuta fiasko, kaj ĝi havas nenion komunan kun tio, ĉu la VPN-aŭskultanto respondis super IPv4.
La mekaniko de IPv6-super-IPv4-enkapsuligo estas priskribita en RFC 4213, kaj la grava detalo tie estas, ke la finpunktoj ankoraŭ bezonas veran IPv6-konektecon ĉe la alia flanko de la tunelo. Ĉirkaŭvolvi kaplinion ne sorĉe kreas upstream.
Du tunelaj tavoloj, du sendependaj kontroloj
Kontrolu ĉiun tavolon aparte, ĉar funkcianta ekstera tunelo kaŝas difektitan internan. Kontrolu la eksteran vojon per IPv4-ping de la kliento al la servilo kaj konfirmu la pordon, kiun vi uzas. Poste kontrolu la internan vojon ĉe la servilo, kie ip -6 route devas montri defaŭltan aŭ konkretan itineron lernitan de reala upstream, kaj ip -6 addr devas montri fontprefikson, kiun la upstream akceptas. Io ajn malpli ol tio estas ornamo sur la interfaco.
Unika-loka adreso, aŭ tutmonde aspekta prefikso, al kiu nenio enkursigas reen, ĝoje aperos sur interfaco kaj iros nenie. Publikan atingeblon donas la upstream, ne la formo de la adreso.
La samo validas ĉe la kliento: ip -6 route get 2001:4860:4860::8888 devus nomi la tunelan aparaton, kaj se ĝi nomas la fizikan, la kliento tute ne uzas la VPN por IPv6.
Fontprefikso, grandeco kaj ICMPv6
Demandu la upstream, kiujn fontprefiksojn ĝi akceptos por plusendado, kaj uzu unu el ili por la klienta baseno. Provizanto, kiu donas al vi /64 por la propra interfaco de la servilo, ne nepre enkursigas duan /64 aŭ pli grandan blokon al vi, kaj la diferenco estas posttagmezo da sencimigado, kiun subtena bileto solvas per unu demando. Demandu skribe kaj konservu la respondon kun la agordo.
Buĝetu por la plia enkapsuligo, kiun via stako efektive uzas, kaj tenu ICMPv6 funkcianta, inkluzive de Packet Too Big. Dua kaplinio malgrandigas la uzeblan ŝarĝon, do vojo, kiu respondas al malgrandaj pingoj, povas tamen fiaski ĉe dosier-transigo, kaj fajroŝirmilo, kiu forĵetas ĉiun ICMPv6, transformas ripareblan grandec-problemon en nigran truon. Testu unu grandan transigon antaŭ ol anonci la servon.
Kio estas tute alia problemo
Atingi IPv4-nuran aplikaĵon de IPv6-nura kliento estas tradukado, ne tunelado, kaj bezonas ion kiel intence elvolvitan NAT64-aranĝon. La celo ne komprenos plian tunelan kaplinion nur ĉar vi aldonis unu. Historiaj transiraj servoj meritas la saman zorgon: RFC 7526 nuligis la 6to4-anycast-relaj-modelon, do lernilo skribita ĉirkaŭ ĝi priskribas ion, kio jam ne havas prizorgatan publikan relajon.
Se la servilo havas neniun uzeblan IPv6-upstream, la elektoj estas subtenata upstream, alia eliro aŭ dokumentita decido, ke IPv6 restas ekster la tunelo. Ne akcepteble estas diri al klientoj, ke IPv6-servo ekzistas, dum ilia ordinara IPv6-konekto silente preterpasas la VPN.