IPv6 IPv4 VPN-palvelimen läpi tarvitsee silti IPv6-uloskäynnin

Tunneli nousee, asiakas saa IPv6-osoitteen poolista, ja silti jokainen IPv6-kohde aikakatkaistaan. Tunnelissa ei ole mitään rikki: IPv6 kulkee aivan hyvin IPv4-siirron sisällä, eikä se ollut koskaan se vaikea osa. Antamasi osoite on lupaus, jota palvelin ei voi pitää, koska uloskäynnillä ei ole IPv6-upstreamia, johon sen lähettäisi. Korjaus kuuluu uloskäynnille, ei asiakasprofiiliin.

Oire: osoite ja ei mitään polkua

Asiakaspuolen tarkistus näyttää tunnelilaitteella maailmanlaajuiselta näyttävän IPv6-osoitteen ja siihen osoittavan reitin, minkä vuoksi tämä tulkitaan väärin asiakkaan viaksi. Liikenne menee tunneliin, palvelin purkaa kapseloinnin, ja sitten paketti laskeutuu isäntään, jonka reititystaulussa ei ole IPv6-oletusreittiä mihinkään todelliseen paikkaan. Pinosta riippuen saat välittömän tavoittamattomuuden tai hiljaisen pudotuksen, ja kummassakin tapauksessa asiakas näkee aikakatkaisun, joka näyttää samalta kuin palomuuri.

Lue palvelimen oma reititystaulu ennen kuin kosket asiakkaaseen, sillä siellä polun puuttuva puolisko asuu. Palvelin, jolla on yksi IPv4-oletusreitti, on jo kertonut sinulle vastauksen.

Seuraa pakettia kapseloinnin purkamisen jälkeen

Tunnelin sisällä paketti on tavallinen IPv6, ja asiakkaan osoite on sen lähde. Palvelin riisuu siirtokapseloinnin ja pitää silloin natiivia IPv6-pakettia, joka on välitettävä seuraavalle IPv6-hypylle. IPv4-oletusreitti ei voi kantaa sitä, ja sen kääntäminen IPv4:ksi on toinen toiminto, jota kukaan ei ottanut käyttöön. Se on koko vika, eikä sillä ole mitään tekemistä sen kanssa, vastasiko VPN-kuuntelija IPv4:n yli.

IPv6:n kapselointi IPv4:n päälle on kuvattu RFC 4213:ssa, ja tärkeä yksityiskohta siellä on, että päätepisteet tarvitsevat silti todellisen IPv6-yhteyden tunnelin toisella puolella. Otsikon kääriminen ei loihti upstreamia tyhjästä.

Kaksi tunnelikerrosta, kaksi riippumatonta tarkistusta

Tarkista kukin kerros erikseen, sillä toimiva ulompi tunneli kätkee rikkinäisen sisemmän. Tarkista ulompi polku IPv4-pingillä asiakkaasta palvelimeen ja vahvista käyttämäsi portti. Tarkista sitten sisempi polku palvelimella, jossa ip -6 route on näytettävä oletusreitti tai tietty reitti, joka on opittu todelliselta upstreamilta, ja ip -6 addr on näytettävä lähdeprefiksi, jonka upstream hyväksyy. Kaikki vähemmän on koristelua rajapinnalla.

Ainutlaatuinen paikallinen osoite tai maailmanlaajuiselta näyttävä prefiksi, johon mikään ei reititä takaisin, ilmestyy iloisesti rajapinnalle eikä mene mihinkään. Julkisen tavoitettavuuden antaa upstream, ei osoitteen muoto.

Sama pätee asiakkaalla: ip -6 route get 2001:4860:4860::8888 pitäisi nimetä tunnelilaite, ja jos se nimeää fyysisen laitteen, asiakas ei käytä VPN:ää IPv6:lle lainkaan.

Lähdeprefiksi, koko ja ICMPv6

Kysy upstreamilta, mitkä lähdeprefiksit se hyväksyy välittämiseen, ja käytä yhtä niistä asiakaspoolille. Palveluntarjoaja, joka antaa sinulle /64:n palvelimen omaa rajapintaa varten, ei välttämättä reititä sinulle toista /64:ää tai suurempaa lohkoa, ja ero on yksi iltapäivä vianetsintää, jonka tukipyyntö ratkaisee yhdellä kysymyksellä. Kysy kirjallisesti ja pidä vastaus konfiguraation mukana.

Varaa budjettiin lisäkapselointi, jota pinoasi todella käyttää, ja pidä ICMPv6 toiminnassa, mukaan lukien Packet Too Big. Toinen otsikko kutistaa käyttökelpoista hyötykuormaa, joten polku, joka vastaa pieniin ping-paketteihin, voi silti epäonnistua tiedostonsiirrossa, ja palomuuri, joka pudottaa kaiken ICMPv6:n, muuttaa korjattavan kokoprobleeman mustaksi aukoksi. Testaa yksi suuri siirto ennen palvelun ilmoittamista.

Mikä on täysin toinen ongelma

Pääseminen vain IPv4 -sovellukseen vain IPv6 -asiakkaasta on kääntämistä, ei tunnelointia, ja vaatii jotain tarkoituksella käyttöön otetun NAT64-järjestelyn kaltaista. Kohde ei ymmärrä ylimääräistä tunnelin otsikkoa vain siksi, että lisäsit sellaisen. Historialliset siirtymäpalvelut ansaitsevat saman huolen: RFC 7526 poisti 6to4 anycast -välitysmallin, joten sen ympärille kirjoitettu ohje kuvaa jotain, jolla ei enää ole ylläpidettyä julkista välittäjää.

Jos palvelimella ei ole käyttökelpoista IPv6-upstreamia, vaihtoehdot ovat tuettu upstream, toinen uloskäynti tai dokumentoitu päätös siitä, että IPv6 pysyy tunnelin ulkopuolella. Ei ole hyväksyttävää kertoa asiakkaille, että IPv6-palvelu on olemassa, samalla kun heidän tavallinen IPv6-yhteytensä ohittaa VPN:n hiljaa.