Føj privat IPv6 til et OpenVPN-laboratorium, ét kontrolpunkt ad gangen

Hold den ydre transport på IPv4 og udvid den indre plan. Fem kontrolpunkter: præfikser, hjælper, rutepush, videresendelse og en klienttest.

Du har allerede en klient, der forbinder over IPv4 og når en privat IPv4-arbejdsbelastning bag serveren. Målet er at nå en privat IPv6-arbejdsbelastning gennem samme tunnel uden at røre den ydre transport. Den rækkefølge betyder noget: den ydre vej bliver IPv4, og kun den indre adresseplan, klientens rute og returvejen fra server til LAN ændres. Fem kontrolpunkter, hvert med noget konkret at kigge på, før du går videre.

Kontrolpunkt et: forbindelsen der allerede virker

Forbind klienten og bekræft IPv4-vejen, før du tilføjer noget. En tunnel der virker giver dig en baseline, der skiller en ny IPv6-fejl fra et gammelt forbindelsesproblem. Den fortæller dig også, hvilken serverinstans du faktisk redigerer.

Notér poolen, topologien og de push'es ruter, du allerede regner med. IPv6-arbejdet udvider den konfiguration; det erstatter den ikke.

Kontrolpunkt to: vælg de indre præfikser

Vælg en ULA /48 til stedet, og skær to /64 ud af den: en til tunnelklienter, en til LAN-segmentet med IPv6-arbejdsbelastningen. Generér det 40-bit globale ID i stedet for at kopiere et eksempelpræfiks, og kontrollér begge undernet mod hvert netværk, stedet allerede router:

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 uafhængige /64 forhindrer, at klientpoolen skæres ud af LAN-segmentet, hvilket betyder noget senere, når du skriver returruten. Værdierne ovenfor er ét gennemregnet eksempel, ikke et præfiks til genbrug.

Kontrolpunkt tre: tilføj hjælperen og rutepushet

Læs serverens nuværende konfiguration, før du tilføjer noget. En anden kopi af en eksisterende direktiv smelter ikke sammen med den første, og den resulterende fejl nævner direktivet i stedet for IPv6. Med den eksisterende IPv4-hjælper på plads udvider to linjer den. Hver svarer på et forskelligt spørgsmål:

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

Den første er en bekvemmelighedshjælper, der konfigurerer interfacet og klientpoolen. Den anden nævner LAN-destinationen, klienten skal nå. At give en klient en IPv6-adresse fortæller den ikke, hvilke netværk der findes bag serveren, så begge linjer er nødvendige.

Hjælperen sameksisterer ikke med en statisk IPv6-pool eller med nopool. Hvis udrulningen bevidst tildeler adresser statisk, så behold den politik og design IPv6-ækvivalenten udtrykkeligt i stedet for at slette politikken for at passe til et eksempel.

Kontrolpunkt fire: videresendelse og svarvejen

Slå IPv6-videresendelse til på serveren gennem systemets egen konfigurationsejer, ikke med en engangsskrivning under kørsel, du vil glemme. Kørselsformen er nyttig til en hurtig test. Vedvarende konfiguration hører i en drop-in-fil, som distributionens netværksejer læser:

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

Videresendelse ændrer værtens IPv6-adfærd ud over at route pakker. En vært, der accepterede routerannoncer som klient, holder op med det på samme måde, når den videresender. En maskine, hvis IPv6-uplink afhænger af RA, har derfor brug for en udtrykkelig plan for den uplink.

Giv derefter LAN'et en rute tilbage til tunnelpoolen. Arbejdsbelastningens IPv6-gateway er LAN-routeren, ikke VPN-serveren, så ruten hører på den router og peger på serverens LAN-adresse:

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

Behold de ICMPv6-typer, linket har brug for, inklusive path-MTU-feedback. En IPv4-firewallregel betyder ikke en IPv6-regel, og en total IPv6-blokering ødelægger nabo-opdagelse på måder, der ligner en routingfejl.

Kontrolpunkt fem: læs klienten, test så

Forbind klienten igen, og læs de adresser, den faktisk fik, i stedet for at udlede dem af serverens hjælperadresse. Interface-oversigten viser begge familier på samme enhed:

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

En rute, der vælger tunnelen, beviser, at klienten ved, hvor pakken skal sendes hen. Den beviser ikke, at serveren videresender den, at LAN-routeren har returruten, eller at applikationen må svare.

Test selve applikationen over hver familie efter tur, og gentag efter en genopkobling og efter en vært-genstart. En rute eller sysctl, der kun holder til genstart, er en test, ikke et design.

Udgiv kun en AAAA-post, når IPv6-vejen svarer ende-til-ende. DNS, der spørges over IPv4, kan stadig returnere en IPv6-adresse, så et navn, der kan slås op, er ikke bevis for, at noget lytter. RFC 4193 ULA-vejledningen dækker generering af det globale ID, der gør disse præfikser til dine i stedet for en kopi.

Relaterede artikler