Aldoni privatan IPv6 al OpenVPN-laboratorio, unu kontrolpunkto samtempe

Vi jam havas klienton, kiu konektiĝas per IPv4 kaj atingas privatan IPv4-laborŝarĝon malantaŭ la servilo. La celo estas atingi privatan IPv6-laborŝarĝon tra la sama tunelo sen tuŝi la eksteran transporton. Tiu ordo gravas: la ekstera vojo restas IPv4, kaj nur la interna adresplano, la klienta itinero kaj larevena vojo de la servilo al la LAN ŝanĝiĝas. Kvin kontrolpunktoj, ĉiu kun io konkreta rigardenda antaŭ ol pluiri.

Kontrolpunkto unu: la konekto, kiu jam funkcias

Konektu la klienton kaj konfirmu la IPv4-vojon antaŭ ol aldoni ion ajn. Funkcianta tunelo donas al vi bazlinion, kiu apartigas novan IPv6-eraron de malnova konekteca problemo. Ĝi ankaŭ diras al vi, kiun servilan ekzempleron vi efektive redaktas.

Notu la naĝujon, la topologion kaj la puŝitajn itinerojn, kiujn vi jam fidas. La IPv6-laboro etendas tiun agordon; ĝi ne anstataŭigas ĝin.

Kontrolpunkto du: elektu la internajn prefiksojn

Elektu ULA /48 por la ejo kaj eltranĉu du /64 el ĝi: unu por tunelaj klientoj, unu por la LAN-segmento, kiu gastigas la IPv6-laborŝarĝon. Generu la 40-bitan tutmondan ID anstataŭ kopii ekzemplan prefikson, kaj kontrolu ambaŭ subretojn kontraŭ ĉiu reto, kiun la ejo jam enkursigas:

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

Du sendependaj /64 malhelpas, ke la klienta naĝujo estas eltranĉita el la LAN-segmento, kio gravas poste, kiam vi skribas la revenan itinero. La valoroj supre estas unu prilaborita ekzemplo, ne prefikso por reuzi.

Kontrolpunkto tri: aldonu la helpanton kaj la itinpuŝon

Legu la nunan servilan agordon antaŭ ol aldoni ion ajn. Dua kopio de ekzistanta direktivo ne kunfandiĝas kun la unua, kaj la rezulta eraro nomas la direktivon anstataŭ IPv6. Kun la ekzistanta IPv4-helpanto, du linioj etendas ĝin. Ĉiu respondas al malsama demando:

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

La unua estas oportuna helpanto, kiu agordas la interfacon kaj la klientan naĝujon. La dua nomas la LAN-celon, kiun la kliento devas atingi. Doni al kliento IPv6-adreson ne diras al ĝi, kiuj retoj ekzistas malantaŭ la servilo, do necesas ambaŭ linioj.

La helpanto ne kunekzistas kun statika IPv6-naĝujo nek kun nopool. Se la deplojo intence asignas adresojn statike, konservu tiun politikon kaj prilaboru la IPv6-ekvivalenton eksplicite anstataŭ forigi la politikon por konformi al ekzemplo.

Kontrolpunkto kvar: plusendo kaj la responda itinero

Ŝaltu IPv6-plusendon sur la servilo per la propra agorda posedanto de la sistemo, ne per unufoja ruliga skribo, kiun vi forgesos. La ruliga formo utilas por rapida provo. Daŭra agordo apartenas al drop-in-dosiero, kiun legas la reta posedanto de la distribuo:

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

Plusendo ŝanĝas la IPv6-konduton de la gastiganto preter enkursigado de pakoj. Gastiganto, kiu akceptis Router Advertisements kiel kliento, ĉesas fari tion same, kiam ĝi plusendas. Maŝino, kies IPv6-uplink dependas de RA, do bezonas eksplicitan planon por tiu uplink.

Poste donu al la LAN itinerojn reen al la tunela naĝujo. La IPv6-pordego de la laborŝarĝo estas la LAN-enkursigilo, ne la VPN-servilo, do la itinero apartenas al tiu enkursigilo kaj montras al la LAN-adreso de la servilo:

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

Konservu la ICMPv6-tipojn, kiujn la ligilo bezonas, inkluzive de vojo-MTU-retrokuplo. IPv4-fajroŝirma regulo ne implicas IPv6-regulon, kaj ĝenerala IPv6-blokado rompas najbaran malkovron tiel, ke ĝi aspektas kiel enkursiga fuŝo.

Kontrolpunkto kvin: legu la klienton, poste testu

Rekonektu la klienton kaj legu la adresojn, kiujn ĝi efektive ricevis, anstataŭ dedukti ilin el la helpanta adreso de la servilo. La interfaca listo montras ambaŭ familiojn sur la sama aparato:

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

Itinero, kiu elektas la tunelon, pruvas, ke la kliento scias, kien sendi la pakon. Ĝi ne pruvas, ke la servilo plusendas ĝin, ke la LAN-enkursigilo havas la revenan itineron, nek ke la aplikaĵo rajtas respondi.

Testu la aplikaĵon mem tra ĉiu familio laŭvice, poste ripetu post rekonekto kaj post gastiganta restartigo. Itinero aŭ sysctl, kiu postvivas nur ĝis restartigo, estas provo, ne dezajno.

Publikigu AAAA-rikordon nur kiam la IPv6-vojo respondas de fino al fino. DNS demandita per IPv4 ankoraŭ povas redoni IPv6-adreson, do solvebla nomo ne estas pruvo, ke io aŭskultas. La gvidilo RFC 4193 pri ULA kovras la generadon de la tutmonda ID, kiu igas ĉi tiujn prefiksojn viaj anstataŭ kopio.