IPv6 deur ’n IPv4-VPN-bediener het steeds ’n IPv6-uitgang nodig

Die tonnel kom op, die kliënt kry ’n IPv6-adres uit die poel, en elke IPv6-bestemming verstryk nietemin. Niks is in die tonnel stukkend nie: IPv6 ry heeltemal goed binne die IPv4-vervoer, en dit was nooit die moeilike deel nie. Die adres wat jy uitgedeel het, is ’n belofte wat die bediener nie kan hou nie, want die uitgang het geen IPv6-opstroom om dit in te stuur nie. Die herstel hoort by die uitgang, nie in die kliëntprofiel nie.

Die simptoom: ’n adres en geen pad

’n Kliëntkant-toets wys ’n wêreldwyd-lykende IPv6-adres op die tonneltoestel en ’n roete wat daarheen wys, en daarom word dit verkeerd as ’n kliëntfout gelees. Verkeer gaan die tonnel in, die bediener dekapsuleer dit, en dan beland die pakkie op ’n gasheer wie se roetetabel geen IPv6-verstekroete na enige werklike plek het nie. Afhangend van die stapel kry jy ’n onmiddellike onbereikbaarheid of ’n stil wegval, en in beide gevalle sien die kliënt ’n tydsverloop wat identies aan ’n vuurmuur lyk.

Lees die bediener se eie roetetabel voordat jy aan die kliënt raak, want dit is waar die ontbrekende helfte van die pad woon. ’n Bediener met een IPv4-verstekroete het jou reeds die antwoord gegee.

Volg die pakkie ná dekapsulering

Binne die tonnel is die pakkie gewone IPv6 met die kliënt se adres as bron. Die bediener stroop die vervoer-enkapsulering af en hou dan ’n inheemse IPv6-pakkie vas wat na ’n volgende IPv6-sprong gestuur moet word. ’n IPv4-verstekroete kan dit nie dra nie, en om dit na IPv4 te vertaal is ’n ander funksie wat niemand ontplooi het nie. Dit is die hele faling, en dit het niks te doen met of die VPN-luisteraar oor IPv4 geantwoord het nie.

Die meganika van IPv6-oor-IPv4-enkapsulering word in RFC 4213 beskryf, en die belangrike detail daar is dat die eindpunte steeds werklike IPv6-konnektiwiteit aan die anderkant van die tonnel nodig het. Om ’n kop te omvou tower nie ’n opstroom op nie.

Twee tonnellae, twee onafhanklike toetse

Verifieer elke laag afsonderlik, want ’n werkende buitenste tonnel verberg ’n stukkende binneste. Toets die buitenste pad met ’n IPv4-ping van die kliënt na die bediener en bevestig die poort wat jy gebruik. Toets dan die binneste pad op die bediener, waar ip -6 route ’n verstek- of spesifieke roete moet wys wat van ’n werklike opstroom geleer is, en ip -6 addr ’n bronvoorvoegsel moet wys wat die opstroom aanvaar. Enigiets minder is versiering op die koppelvlak.

’n Unieke plaaslike adres, of ’n wêreldwyd-lykende voorvoegsel waarheen niks terugroeteer nie, sal heel gelukkig op ’n koppelvlak verskyn en nêrens heen gaan nie. Openbare bereikbaarheid word deur die opstroom verleen, nie deur die vorm van die adres nie.

Dieselfde geld by die kliënt: ip -6 route get 2001:4860:4860::8888 moet die tonneltoestel noem, en as dit die fisiese een noem, gebruik die kliënt glad nie die VPN vir IPv6 nie.

Bronvoorvoegsel, grootte en ICMPv6

Vra die opstroom watter bronvoorvoegsels hy vir aansturing sal aanvaar, en gebruik een daarvan vir die kliëntpoel. ’n Verskaffer wat jou ’n /64 vir die bediener se eie koppelvlak gee, stuur nie noodwendig ’n tweede /64 of ’n groter blok na jou nie, en die verskil is ’n middag se ontfouting wat ’n ondersteuningskaartjie in een vraag besleg. Vra dit skriftelik en hou die antwoord by die konfigurasie.

Begroot vir die ekstra enkapsulering wat jou stapel werklik gebruik, en hou ICMPv6 aan die werk, insluitend Packet Too Big. ’n Tweede kop verklein die bruikbare loonvrag, so ’n pad wat klein pings antwoord, kan steeds op ’n lêeroordrag faal, en ’n vuurmuur wat alle ICMPv6 laat val, maak ’n herstelbare grootteprobleem in ’n swart gat. Toets een groot oordrag voordat jy die diens aankondig.

Wat ’n heeltemal ander probleem is

Om ’n slegs-IPv4-toepassing van ’n slegs-IPv6-kliënt te bereik, is vertaling, nie tonneling nie, en benodig iets soos ’n doelbewus ontplooide NAT64-reëling. Die bestemming sal nie ’n ekstra tonnelkop verstaan net omdat jy een bygevoeg het nie. Historiese oorgangsdienste verdien dieselfde sorg: RFC 7526 het die 6to4-anycast-aflosmodel afgeskaf, so ’n hoe-om dit daarom geskryf is, beskryf iets wat nie meer ’n onderhoue openbare aflos het nie.

As die bediener geen bruikbare IPv6-opstroom het nie, is die keuses ’n ondersteunde opstroom, ’n ander uitgang, of ’n gedokumenteerde besluit dat IPv6 buite die tonnel bly. Wat nie aanvaarbaar is nie, is om vir kliënte te sê dat IPv6-diens bestaan terwyl hulle gewone IPv6-verbinding die VPN stilweg omseil.