IPv6 fia in IPv4 VPN-tsjinner hat noch altyd in IPv6-útgong nedich

De tunnel komt omheech, de klant krijt in IPv6-adres út de pool, en dochs rint elke IPv6-bestimming ôf. Yn de tunnel is neat stikken: IPv6 riidt prima yn ’e IPv4-transport, en dat wie nea it drege part. It adres datsto útdield hast, is in belofte dy’t de tsjinner net hâlde kin, want de útgong hat gjin IPv6-upstream dêr’t er it hinne stjoere kin. De reparaasje heart by de útgong, net yn it klantprofyl.

It symptoom: in adres en gjin paad

In kontrôle oan ’e klantkant lit in wrâldwiid-lykjend IPv6-adres op it tunneloanrjochting sjen en in rûte dy’t dêrhinne wiist, en dêrom wurdt dit ferkeard lêzen as in klantflater. Ferkear giet de tunnel yn, de tsjinner dekapsulearret it, en dan lânet it pakket op in host waans rûtetabel gjin IPv6-standertrûte nei in echt plak hat. Ofhinklik fan ’e stack krije jo in dalik berikberensprobleem of in stil weilitten, en yn beide gefallen sjocht de klant in time-out dy’t der itselde útsjocht as in brânmuorre.

Lês de eigen rûtetabel fan ’e tsjinner foardatsto de klant oanrekkest, want dêr wennet de ûntbrekkende helte fan it paad. In tsjinner mei ien IPv4-standertrûte hat dy it antwurd al jûn.

Folgje it pakket nei de dekapsulaasje

Yn ’e tunnel is it pakket gewoan IPv6 en it adres fan ’e klant is de boarne. De tsjinner strûpt de transportkapseling ôf en hâldt dan in native IPv6-pakket fêst dat trochstjoerd wurde moat nei in folgjende IPv6-hop. In IPv4-standertrûte kin it net drage, en it oersetten nei IPv4 is in oare funksje dy’t nimmen útrôle hat. Dat is de hiele flater, en it hat neat te krijen mei de fraach oft de VPN-listener oer IPv4 antwurde hat.

De meganika fan IPv6-oer-IPv4-kapseling stiet beskreaun yn RFC 4213, en it wichtige detail dêr is dat de einpunten noch altyd echte IPv6-konnektiviteit nedich hawwe oan ’e oare kant fan ’e tunnel. In kop omwikselje tsjoenet gjin upstream.

Twa tunnellagen, twa ûnôfhinklike kontrôles

Kontrolearje elke laach apart, want in wurkjende bûtenste tunnel ferberget in stikken binnenste. Kontrolearje it bûtenste paad mei in IPv4-ping fan ’e klant nei de tsjinner en befêstigje de poarte dy’tsto brûkst. Kontrolearje dan it binnenste paad op ’e tsjinner, dêr’t ip -6 route in standertrûte of in konkrete rûte sjen moat dy’t fan in echte upstream leard is, en ip -6 addr in boarneprefiks sjen moat dat de upstream akseptearret. Alles minder is fersiering op ’e ynterface.

In unyk-lokaal adres, of in wrâldwiid-lykjend prefiks dêr’t neat nei weromrûtet, sil him lokkich op in ynterface sjen litte en nearne hinne gean. Iepenbiere berikberens wurdt jûn troch de upstream, net troch de foarm fan it adres.

Itselde jildt by de klant: ip -6 route get 2001:4860:4860::8888 moat it tunneloanrjochting neame, en as it it fysike neamt, brûkt de klant de VPN hielendal net foar IPv6.

Boarneprefiks, grutte en ICMPv6

Freegje de upstream hokker boarneprefiksen er foar trochstjoeren akseptearret, en brûk ien fan dy foar de klantpool. In oanbieder dy’t dy in /64 jout foar de eigen ynterface fan ’e tsjinner, rûtet net needsaaklikerwiis in twadde /64 of in grutter blok nei dy ta, en it ferskil is in middei debuggen dy’t in supportticket mei ien fraach besljochtet. Freegje it skriftlik en bewarje it antwurd by de konfiguraasje.

Begrootje foar de ekstra kapseling dy’t dyn stack echt brûkt, en hâld ICMPv6 oan ’e gong, Packet Too Big ynbegrepen. In twadde kop krimpt de brûkbere payload, dus in paad dat lytse pings beantwurdet, kin noch altyd mislearje by in bestânoerdracht, en in brânmuorre dy’t alle ICMPv6 fuortsmyt makket in reparearber grutteprobleem ta in swart gat. Test ien grutte oerdracht foardatsto de tsjinst oankundigest.

Wat in hiel oar probleem is

In applikaasje berikke dy’t allinne IPv4 is fan in klant dy’t allinne IPv6 is, is oersetting, gjin tunnelen, en hat wat nedich as in bewust útrôle NAT64-regeling. De bestimming sil in ekstra tunnelkop net begripe, allinnich om’tsto ien taheakke hast. Histoaryske oergongstsjinsten fertsjinje deselde soarch: RFC 7526 hat it 6to4-anycast-relaymodel ôfskaft, dus in hânlieding dy’t dêromhinne skreaun is, beskriuwt eat dat gjin ûnderhâlden iepenbier relay mear hat.

As de tsjinner gjin brûkbere IPv6-upstream hat, binne de karren in stipe upstream, in oare útgong, of in dokumintearre beslút dat IPv6 bûten de tunnel bliuwt. Wat net akseptabel is, is klanten fertelle dat der in IPv6-tsjinst bestiet, wylst har gewoane IPv6-ferbining de VPN stil foarbygiet.