Magdagdag ng pribadong IPv6 sa isang OpenVPN lab, isang checkpoint sa isang pagkakataon

Mayroon ka nang kliyenteng kumokonekta sa IPv4 at umaabot sa pribadong IPv4 workload sa likod ng server. Ang layunin ay maabot ang pribadong IPv6 workload sa parehong tunnel nang hindi hinahawakan ang panlabas na transportasyon. Mahalaga ang pagkakasunod-sunod: mananatiling IPv4 ang panlabas na landas, at ang panloob na plano ng address, ruta ng kliyente at daan pabalik mula server patungong LAN lamang ang nagbabago. Limang checkpoint, bawat isa may konkretong dapat tingnan bago magpatuloy.

Unang checkpoint: ang koneksyong gumagana na

Ikonekta ang kliyente at kumpirmahin ang IPv4 na landas bago magdagdag ng anuman. Ang gumaganang tunnel ay nagbibigay ng baseline na naghihiwalay ng bagong IPv6 na pagkakamali mula sa lumang problema sa koneksyon. Sinasabi rin nito kung aling instance ng server ang talagang ine-edit mo.

Itala ang pool, topolohiya at mga naipush na ruta na inaasahan mo na. Pinapalawak ng gawaing IPv6 ang configuration na iyon; hindi ito pinapalitan.

Ikalawang checkpoint: pumili ng mga panloob na prefix

Pumili ng ULA /48 para sa site at gupitin ang dalawang /64 mula rito: isa para sa mga kliyente ng tunnel, isa para sa LAN segment na may IPv6 workload. Bumuo ng 40-bit na global ID sa halip na kopyahin ang halimbawang prefix, at suriin ang parehong subnet laban sa bawat network na niruruta na ng site:

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

Dalawang malayang /64 ang pumipigil sa pool ng kliyente na maputol mula sa LAN segment, na mahalaga mamaya kapag isinusulat mo ang pabalik na ruta. Ang mga halaga sa itaas ay isang ginawang halimbawa, hindi prefix na muling gagamitin.

Ikatlong checkpoint: idagdag ang katulong at ang pagtulak ng ruta

Basahin ang kasalukuyang configuration ng server bago magdagdag ng anuman. Ang ikalawang kopya ng umiiral na direktiba ay hindi nagsasama sa una, at ang error na lumalabas ay pinapangalanan ang direktiba, hindi IPv6. Kapag may umiiral na IPv4 na katulong, dalawang linya ang nagpapalawak dito. Bawat isa ay sumasagot sa magkaibang tanong:

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

Ang una ay maginhawang katulong na nagtatakda ng interface at pool ng kliyente. Ang pangalawa ay pinapangalanan ang destinasyon sa LAN na dapat abutin ng kliyente. Ang pagbibigay ng IPv6 address sa kliyente ay hindi nagsasabi kung anong mga network ang nasa likod ng server, kaya kailangan ang dalawang linya.

Ang katulong ay hindi kasama ng static na IPv6 pool o ng nopool. Kung sadyang static ang paglalaan ng address sa deployment, panatilihin ang patakarang iyon at tahasang idisenyo ang katumbas na IPv6 sa halip na burahin ang patakaran upang umangkop sa isang halimbawa.

Ikaapat na checkpoint: pagpapasa at ang ruta ng tugon

I-on ang IPv6 forwarding sa server sa pamamagitan ng sariling may-ari ng configuration ng system, hindi sa isang beses na runtime write na makakalimutan mo. Kapaki-pakinabang ang runtime form para sa mabilis na pagsubok. Ang permanenteng configuration ay nasa drop-in file na binabasa ng may-ari ng network ng distribution:

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

Binabago ng forwarding ang IPv6 na pag-uugali ng host higit sa pagruruta ng packet. Ang host na tumanggap ng router advertisements bilang kliyente ay tumitigil gawin iyon sa parehong paraan kapag nagpapasa na. Kaya ang makinang nakadepende ang IPv6 uplink sa RA ay nangangailangan ng tahasang plano para sa uplink na iyon.

Pagkatapos, bigyan ang LAN ng rutang pabalik sa pool ng tunnel. Ang IPv6 gateway ng workload ay ang LAN router, hindi ang VPN server, kaya ang ruta ay nasa router na iyon at nakaturo sa LAN address ng server:

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

Panatilihin ang mga uri ng ICMPv6 na kailangan ng link, kasama ang path-MTU feedback. Ang tuntunin ng firewall na IPv4 ay hindi nangangahulugang tuntunin ng IPv6, at ang buong pagharang sa IPv6 ay sumisira sa pagtuklas ng kapitbahay sa paraang mukhang sira sa pagruruta.

Ikalimang checkpoint: basahin ang kliyente, pagkatapos subukan

Kumonekta muli ang kliyente at basahin ang mga address na aktwal na natanggap nito sa halip na hulaan mula sa katulong na address ng server. Ipinapakita ng listahan ng interface ang parehong pamilya sa iisang device:

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

Ang rutang pumipili sa tunnel ay nagpapatunay na alam ng kliyente kung saan ipapadala ang packet. Hindi nito pinatutunayan na ipinapasa ito ng server, na may pabalik na ruta ang LAN router, o na pinapayagang sumagot ang aplikasyon.

Subukan ang aplikasyon mismo sa bawat pamilya nang halinhinan, pagkatapos ulitin pagkatapos ng muling pagkonekta at pagkatapos ng pag-restart ng host. Ang ruta o sysctl na tumatagal lamang hanggang reboot ay pagsubok, hindi disenyo.

Ilathala ang AAAA record lamang kapag sumasagot ang IPv6 na landas mula simula hanggang dulo. Ang DNS na tinanong sa IPv4 ay maaari pa ring magbalik ng IPv6 address, kaya ang pangalang malulutas ay hindi patunay na may nakikinig. Ang gabay ng RFC 4193 para sa ULA ay sumasaklaw sa pagbuo ng global ID na gumagawa sa mga prefix na ito na sa iyo at hindi kopya.