IPv6 gjennom ein IPv4 VPN-server treng framleis ein IPv6-utgang

Tunnelen kjem opp, klienten får ein IPv6-adresse frå poolen, og likevel går kvar IPv6-destinasjon ut på tid. Ingenting er øydelagt i tunnelen: IPv6 går heilt fint inne i IPv4-transporten, og det var aldri den vanskelege delen. Adressa du delte ut, er eit løfte serveren ikkje kan halda, fordi utgangen ikkje har nokon IPv6-upstream å senda henne inn i. Reparasjonen høyrer til ved utgangen, ikkje i klientprofilen.

Symptomet: ei adresse og ingen veg

Ein sjekk på klientsida viser ei IPv6-adresse som ser global ut på tunneleininga og ei rute som peikar inn i henne, og difor blir dette feiltolka som ein klientfeil. Trafikken går inn i tunnelen, serveren dekapsulerer han, og deretter landar pakken på ein vert der rutetabellen ikkje har noka standardrute for IPv6 til noko verkeleg stad. Avhengig av stakken får du momentan utilgjengelegheit eller eit stille dropp, og i båe tilfelle ser klienten ein timeout som ser lik ut som ein brannmur.

Les serveren sin eigen rutetabell før du rører klienten, for det er der den manglande halvdelen av vegen bur. Ein server med éi standardrute for IPv4 har allereie gjeve deg svaret.

Følg pakken etter dekapsuleringa

Inne i tunnelen er pakken vanleg IPv6, og adressa til klienten er kjelda. Serveren fjernar transportinnkapslinga og sit då med ein opphavleg IPv6-pakke som må videresendast til neste IPv6-hopp. Ei standardrute for IPv4 kan ikkje bera han, og å omsetja han til IPv4 er ein annan funksjon som ingen har rulle ut. Det er heile feilen, og han har ingenting å gjera med om VPN-lyttaren svara over IPv4.

Mekanikken for IPv6-over-IPv4-innkapsling er skildra i RFC 4213, og den viktige detaljen der er at endepunkta framleis treng ekte IPv6-tilkopling på den andre sida av tunnelen. Å pakka inn ein header tryllar ikkje fram ein upstream.

To tunnellag, to uavhengige sjekkar

Stadfest kvart lag for seg, fordi ein fungerande ytre tunnel skjuler ein øydelagd indre. Sjekk den ytre vegen med ein IPv4-ping frå klienten til serveren, og stadfest porten du brukar. Sjekk deretter den indre vegen på serveren, der ip -6 route må visa ei standardrute eller ei konkret rute lærd frå ein ekte upstream, og ip -6 addr må visa eit kjelde-prefiks som upstreamen godtek. Alt mindre er pynt på grensesnittet.

Ei unik-lokal adresse, eller eit prefiks som ser globalt ut og som ingenting ruter tilbake til, dukkar gjerne opp på eit grensesnitt og går ingen stad. Offentleg tilgjengelegheit blir gjeven av upstreamen, ikkje av forma til adressa.

Det same gjeld på klienten: ip -6 route get 2001:4860:4860::8888 bør nemna tunneleininga, og om ho nemner den fysiske, brukar klienten ikkje VPN for IPv6 i det heile.

Kjelde-prefiks, storleik og ICMPv6

Spør upstreamen kva kjelde-prefiks han godtek for vidaresending, og bruk eitt av dei til klientpoolen. Ein leverandør som gjev deg eit /64 for serveren sitt eige grensesnitt, rutar ikkje nødvendigvis eit andre /64 eller ein større blokk til deg, og skilnaden er ein ettermiddag med feilsøking som ein støtteticket avgjer med eitt spørsmål. Spør skriftleg og ta vare på svaret saman med konfigurasjonen.

Budsjetter for den ekstra innkapslinga stakken din faktisk brukar, og hald ICMPv6 i gang, inkludert Packet Too Big. Ein ekstra header krympar nyttelasta, så ein veg som svarar på små ping, kan framleis feila ved ei filoverføring, og ein brannmur som slepp alle ICMPv6, gjer eit reparerbart storleiksproblem om til eit svart hol. Test éi stor overføring før du annonserer tenesta.

Kva som er eit heilt anna problem

Å nå ein applikasjon som berre er IPv4 frå ein klient som berre er IPv6 er omsetjing, ikkje tunnellering, og treng noko som ei medvite utrulla NAT64-ordning. Destinasjonen vil ikkje forstå ein ekstra tunnelheader berre fordi du la til ein. Historiske overgangstenester fortener same omhug: RFC 7526 avvikla 6to4-anycast-relémodellen, så ei rettleiing skriven rundt han skildrar noko som ikkje lenger har eit vedlikehalde offentleg relé.

Om serveren ikkje har nokon brukbar IPv6-upstream, er vala ein støtta upstream, ein annan utgang eller ei dokumentert avgjerd om at IPv6 blir utanfor tunnelen. Det som ikkje er akseptabelt, er å fortelja klientar at ei IPv6-teneste finst, medan den vanlege IPv6-tilkoplinga deira stille går utanom VPN.