Prive-IPv6 tafoegje oan in OpenVPN-lab, ien kontrôlepunt tagelyk

Jo hawwe al in klant dy't oer IPv4 ferbynt en in privee IPv4-wurklêst efter de tsjinner berikt. It doel is om in privee IPv6-wurklêst troch deselde tunnel te berikken sûnder it bûtenste ferfier oan te reitsjen. Dy folchoarder is wichtich: it bûtenste paad bliuwt IPv4, en allinnich it binnenadresplan, de klantrûte en it werompaad fan tsjinner nei LAN feroarje. Fiif kontrôlepunten, elk mei wat konkreets om nei te sjen foardat jo fierder geane.

Kontrôlepunt ien: de ferbining dy't al wurket

Ferbyn de klant en befêstigje it IPv4-paad foardat jo wat tafoegje. In wurkjende tunnel jout jo in basisline dy't in nije IPv6-flater fan in âld ferbiningsprobleem skiedt. It fertelt jo ek hokker tsjinner-eksimplaar jo eins bewurkje.

Skriuw de pool, de topology en de stjoerde rûtes op dêr't jo al op fertrouwe. It IPv6-wurk wreidet dy konfiguraasje út; it ferfangt him net.

Kontrôlepunt twa: kies de binnenprefiksen

Kies in ULA /48 foar it plak en snij twa /64 derút: ien foar tunnelklanten, ien foar it LAN-segmint mei de IPv6-wurklêst. Generearje de 40-bits globale ID ynstee fan in foarbyldprefiks te kopiearjen, en kontrolearje beide subnetten tsjin elk netwurk dat it plak al rûtet:

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

Twa ûnôfhinklike /64 hâlde tsjin dat de klantpool út it LAN-segmint snien wurdt, wat letter wichtich is as jo it werompaad skriuwe. De wearden hjirboppe binne ien útwurke foarbyld, gjin prefiks om wer te brûken.

Kontrôlepunt trije: foegje de helper en de rûtstjitting ta

Lês de hjoeddeiske tsjinnerkonfiguraasje foardat jo wat taheakje. In twadde kopy fan in besteande rjochtline raant net gear mei de earste, en de flater dy't komt neamt de rjochtline, net IPv6. Mei de besteande IPv4-helper op syn plak wreidzje twa rigels him út. Elk beantwurdet in oare fraach:

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

De earste is in handige helper dy't de ynterface en de klantpool konfigurearret. De twadde neamt it LAN-bestimming dat de klant berikke moat. In klant in IPv6-adres jaan fertelt him net hokker netwurken efter de tsjinner binne, dus beide rigels binne nedich.

De helper bestiet net njonken in statyske IPv6-pool of njonken nopool. As de útrôljen bewust adressen statysk tawiist, hâld dy polityk oan en ûntwerp it IPv6-ekwivalint eksplisyt ynstee fan de polityk te skrasjen om by in foarbyld te passen.

Kontrôlepunt fjouwer: trochstjoering en it antwurdpaad

Skeakelje IPv6-trochstjoering op de tsjinner oan fia de eigen konfiguraasjebesitter fan it systeem, net mei in ienmalige runtime-skriuwerij dy't jo ferjitte. De runtime-foarm is nuttich foar in flugge test. Oanhâldende konfiguraasje heart yn in drop-in-bestân dat de netwurkbesitter fan de distribúsje lêst:

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

Trochstjoering feroaret it IPv6-gedrach fan de host fierder as it rûtsjen fan pakketten. In host dy't as klant router-oankundigings akseptearre, hâldt dêrmei op deselde wize sadree't er trochstjoert. In masine waans IPv6-uplink fan RA's ôfhinklik is, hat dêrom in eksplisyt plan foar dy uplink nedich.

Jou it LAN dan in rûte werom nei de tunnelpool. It IPv6-gateway fan de wurklêst is de LAN-rûter, net de VPN-tsjinner, dus de rûte heart op dy rûter en wiist nei it LAN-adres fan de tsjinner:

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

Behâld de ICMPv6-typen dy't de ferbining nedich hat, ynklusyf paad-MTU-weromkoppeling. In IPv4-firewallregel betsjut gjin IPv6-regel, en in folsleine IPv6-blokkade brekt buorrenundersyk op in wize dy't op in rûtflater liket.

Kontrôlepunt fiif: lês de klant, test dan

Ferbyn de klant opnij en lês de adressen dy't er echt krigen hat, ynstee fan se ôf te lieden fan it helperadres fan de tsjinner. De ynterfacelist lit beide famyljes op itselde apparaat sjen:

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

In rûte dy't de tunnel kiest, bewiist dat de klant wit wêr't it pakket hinne moat. It bewiist net dat de tsjinner it trochstjoert, dat de LAN-rûter it werompaad hat, of dat de applikaasje antwurdzje mei.

Test de applikaasje sels oer elke famylje om bar, en werhelje dat nei in nije ferbining en nei in hostwerstart. In rûte of sysctl dy't allinnich oant de werstart bliuwt, is in test, gjin ûntwerp.

Publisearje in AAAA-record pas as it IPv6-paad fan begjin oant ein antwurdet. DNS oer IPv4 kin noch hieltyd in IPv6-adres weromjaan, dus in oplosbere namme is gjin bewiis dat der wat harket. De RFC 4193 ULA-rjochtline behannelet it generearjen fan de globale ID dy't dizze prefiksen fan jo makket ynstee fan in kopy.