Lisää yksityinen IPv6 OpenVPN-laboratorioon, yksi tarkistuspiste kerrallaan

Sinulla on jo asiakas, joka yhdistää IPv4:n kautta ja saavuttaa palvelimen takana olevan yksityisen IPv4-työkuorman. Tavoite on saavuttaa yksityinen IPv6-työkuorma saman tunnelin kautta koskematta ulompaan kuljetukseen. Tällä järjestyksellä on väliä: ulompi polku pysyy IPv4:nä ja vain sisäinen osoitesuunnitelma, asiakkaan reitti ja paluupolku palvelimelta lähiverkkoon muuttuvat. Viisi tarkistuspistettä, jokaisessa jotain konkreettista katsottavaa ennen jatkamista.

Tarkistuspiste yksi: yhteys, joka jo toimii

Yhdistä asiakas ja varmista IPv4-polku ennen kuin lisäät mitään. Toimiva tunneli antaa perustason, joka erottaa uuden IPv6-virheen vanhasta yhteyden ongelmasta. Se kertoo myös, mitä palvelininstanssia todella muokkaat.

Kirjaa pooli, topologia ja työnnetyt reitit, joihin jo luotat. IPv6-työ laajentaa tätä kokoonpanoa; se ei korvaa sitä.

Tarkistuspiste kaksi: valitse sisäiset etuliitteet

Valitse sivustolle ULA /48 ja leikkaa siitä kaksi /64: yksi tunnelin asiakkaille, yksi lähiverkon segmentille, jossa IPv6-työkuorma on. Luo 40-bittinen globaali ID sen sijaan, että kopioisit esimerkkietuliitteen, ja tarkista molemmat aliverkot jokaista verkkoa vastaan, jota sivusto jo reitittää:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

Kaksi riippumatonta /64 estää asiakaspoolin leikkaamisen irti lähiverkon segmentistä, millä on merkitystä myöhemmin paluureittiä kirjoitettaessa. Yllä olevat arvot ovat yksi läpikäyty esimerkki, ei uudelleenkäytettävä etuliite.

Tarkistuspiste kolme: lisää apuri ja reitin työntö

Lue palvelimen nykyinen kokoonpano ennen kuin lisäät mitään. Olemassa olevan direktiivin toinen kopio ei yhdisty ensimmäiseen, ja tuloksena oleva virhe nimeää direktiivin, ei IPv6:n. Kun IPv4-apuri on paikallaan, kaksi riviä laajentaa sitä. Kumpikin vastaa eri kysymykseen:

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

Ensimmäinen on mukavuusapuri, joka määrittää liitännän ja asiakaspoolin. Toinen nimeää lähiverkon kohteen, johon asiakkaan on päästävä. IPv6-osoitteen antaminen asiakkaalle ei kerro, mitä verkkoja palvelimen takana on, joten molemmat rivit tarvitaan.

Apuri ei esiinny yhdessä staattisen IPv6-poolin eikä nopool-koodin kanssa. Jos käyttöönotto jakaa osoitteita tarkoituksella staattisesti, pidä tästä käytännöstä ja suunnittele IPv6-vastine nimenomaisesti sen sijaan, että poistaisit käytännön esimerkkiin sopiakseni.

Tarkistuspiste neljä: edelleenlähetys ja vastausreitti

Kytke IPv6-edelleenlähetys palvelimessa päälle järjestelmän oman kokoonpanon omistajan kautta, ei kertaluontoisella ajonaikaisella kirjoituksella, jonka unohdat. Ajonaikainen muoto on hyödyllinen nopeaan testiin. Pysyvä kokoonpano kuuluu drop-in-tiedostoon, jota jakelun verkko-omistaja lukee:

sysctl -w net.ipv6.conf.all.forwarding=1

Edelleenlähetys muuttaa isännän IPv6-käyttäytymistä pakettien reititystä pidemmälle. Isäntä, joka hyväksyi reitittimen ilmoituksia asiakkaana, lakkaa tekemästä niin samalla tavalla alkaessaan välittää. Siksi kone, jonka IPv6-yhteys on RA:iden varassa, tarvitsee nimenomaisen suunnitelman sille yhteydelle.

Anna sitten lähiverkolle reitti takaisin tunnelipooliin. Työkuorman IPv6-yhdyskäytävä on lähiverkon reititin, ei VPN-palvelin, joten reitti kuuluu sille reitittimelle ja osoittaa palvelimen lähiverkko-osoitteeseen:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

Säilytä ICMPv6-tyypit, joita linkki tarvitsee, mukaan lukien polun MTU -palaute. IPv4-palomuurisääntö ei tarkoita IPv6-sääntöä, ja IPv6:n täysi estäminen rikkoo naapureiden löytämisen tavalla, joka näyttää reititysviirheeltä.

Tarkistuspiste viisi: lue asiakas ja testaa sitten

Yhdistä asiakas uudelleen ja lue osoitteet, jotka se todella sai, sen sijaan että päättelet ne palvelimen apuriosoitteesta. Liitännän luettelo näyttää molemmat perheet samassa laitteessa:

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

Tunnelin valitseva reitti todistaa, että asiakas tietää, minne paketti lähetetään. Se ei todista, että palvelin välittää sen, että lähiverkon reitittimellä on paluureitti tai että sovellus saa vastata.

Testaa itse sovellusta kunkin perheen yli vuorotellen ja toista uudelleenyhdistämisen ja isännän uudelleenkäynnistyksen jälkeen. Reitti tai sysctl, joka kestää vain uudelleenkäynnistykseen, on testi, ei suunnitelma.

Julkaise AAAA-tietue vasta, kun IPv6-polku vastaa päästä päähän. IPv4:n kautta kysytty DNS voi yhä palauttaa IPv6-osoitteen, joten ratkeava nimi ei ole todiste siitä, että jokin kuuntelee. RFC 4193 ULA -ohje kattaa globaalin ID:n luomisen, joka tekee näistä etuliitteistä sinun eikä kopion.