Legg til privat IPv6 i et OpenVPN-laboratorium, ett kontrollpunkt om gangen

Du har allerede en klient som kobler til over IPv4 og når en privat IPv4-arbeidsbelastning bak serveren. Målet er å nå en privat IPv6-arbeidsbelastning gjennom samme tunnel uten å røre den ytre transporten. Den rekkefølgen betyr noe: den ytre veien blir IPv4, og bare den indre adresseplanen, klientens rute og returveien fra server til LAN endres. Fem kontrollpunkter, hvert med noe konkret å se på før du går videre.

Kontrollpunkt én: forbindelsen som allerede virker

Koble til klienten og bekreft IPv4-veien før du legger til noe. En tunnel som virker gir deg en grunnlinje som skiller en ny IPv6-feil fra et gammelt tilkoblingsproblem. Den forteller deg også hvilken serverinstans du faktisk redigerer.

Noter bassenget, topologien og de pushede rutene du allerede er avhengig av. IPv6-arbeidet utvider den konfigurasjonen; det erstatter den ikke.

Kontrollpunkt to: velg de indre prefiksene

Velg en ULA /48 for nettstedet og skjær to /64 ut av den: én for tunnelklienter, én for LAN-segmentet som har IPv6-arbeidsbelastningen. Generer den 40-biters globale ID-en i stedet for å kopiere et eksempelprefiks, og kontroller begge subnettene mot hvert nettverk nettstedet allerede ruter:

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

To uavhengige /64 hindrer at klientbassenget skjæres ut av LAN-segmentet, noe som betyr noe senere når du skriver returruten. Verdiene over er ett gjennomarbeidet eksempel, ikke et prefiks for gjenbruk.

Kontrollpunkt tre: legg til hjelperen og rutepushet

Les serverens nåværende konfigurasjon før du legger til noe. En andre kopi av en eksisterende direktiv smelter ikke sammen med den første, og feilen som oppstår nevner direktivet, ikke IPv6. Med den eksisterende IPv4-hjelperen på plass utvider to linjer den. Hver svarer på et annet spørsmål:

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

Den første er en bekvemmelighetshjelper som setter opp grensesnittet og klientbassenget. Den andre navngir LAN-målet klienten skal nå. Å gi en klient en IPv6-adresse forteller den ikke hvilke nettverk som finnes bak serveren, så begge linjene trengs.

Hjelperen sameksisterer ikke med et statisk IPv6-basseng eller med nopool. Hvis utrullingen bevisst tildeler adresser statisk, behold den politikken og design IPv6-ekvivalenten eksplisitt i stedet for å slette politikken for å passe et eksempel.

Kontrollpunkt fire: videresending og svarveien

Slå på IPv6-videresending på serveren gjennom systemets egen konfigurasjonseier, ikke med en engangsskriving under kjøring du vil glemme. Kjøringsformen er nyttig for en rask test. Vedvarende konfigurasjon hører hjemme i en drop-in-fil som distribusjonens nettverkseier leser:

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

Videresending endrer vertens IPv6-atferd utover å rute pakker. En vert som godtok ruterannonser som klient, slutter å gjøre det på samme måte når den videresender. En maskin hvis IPv6-uplink avhenger av RA trenger derfor en uttrykkelig plan for den uplinken.

Gi deretter LAN-et en rute tilbake til tunnelbassenget. Arbeidsbelastningens IPv6-gateway er LAN-ruteren, ikke VPN-serveren, så ruten hører på den ruteren og peker på serverens LAN-adresse:

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

Behold ICMPv6-typene lenken trenger, inkludert tilbakemelding om sti-MTU. En IPv4-brannmurregel betyr ikke en IPv6-regel, og en total IPv6-blokkering ødelegger nabo-oppdagelse på måter som ser ut som en ruterfeil.

Kontrollpunkt fem: les klienten, test så

Koble til klienten igjen og les adressene den faktisk fikk i stedet for å utlede dem fra serverens hjelperadresse. Grensesnittlisten viser begge familiene på samme enhet:

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

En rute som velger tunnelen beviser at klienten vet hvor pakken skal sendes. Den beviser ikke at serveren videresender den, at LAN-ruteren har returruten, eller at applikasjonen har lov til å svare.

Test selve applikasjonen over hver familie etter tur, og gjenta etter en ny tilkobling og etter en vertsrestart. En rute eller sysctl som bare overlever til omstart er en test, ikke et design.

Publiser bare en AAAA-post når IPv6-veien svarer ende-til-ende. DNS som spørres over IPv4 kan fortsatt returnere en IPv6-adresse, så et navn som lar seg slå opp er ikke bevis for at noe lytter. RFC 4193 ULA-veiledningen dekker generering av den globale ID-en som gjør disse prefiksene dine i stedet for en kopi.