IPv6-grenprefiks: iroute-ipv6 eller route-ipv6 på serveren?

To direktiver med nesten samme navn finnes i hvert fungerende eksempel, og kopierer man det ene uten det andre, får man en tunnel som ser riktig ut og stille mister grenprefikset. De gjør forskjellig arbeid på hver sin side av samme grense: det ene lærer serverens kjerne hvor et prefiks bor, og det andre forteller OpenVPN hvilken autentisert klient som bærer det. Få begge riktig, og prefikset flyter; få ett riktig, og pakkene har en rute men ingen eier.

To direktiver, to forskjellige oppgaver

route-ipv6 er en vanlig ruteinstallasjon: serveren legger til en kjernerute som peker prefikset mot tunnelgrensesnittet sitt. iroute-ipv6 hører til en klientspesifikk kontekst og erklærer internt eierskap, slik at daemonen vet at trafikk for det prefikset skal sendes til en bestemt klient i stedet for til den peeren en kjernerute tilfeldigvis nevner.

Det ene handler om kjernens videresendingstabell, det andre om daemonens interne rutemodell. Å holde dem fra hverandre forklarer hvorfor en konfigurasjon som ser komplett ut fortsatt kan miste prefikset. Det forklarer også hvorfor det samme nettverket dukker opp to ganger i hvert fungerende eksempel. Ingen av linjene er overflødige.

I det tradisjonelle userspace-oppsettet trengs begge, og de utfyller hverandre. En kjernerute alene gjør at daemonen ikke kan velge en peer. En iroute alene gjør at kjernen mangler en vei til tunnelen. Det er også her det meste av forvirringen rundt per-klientfiler kommer fra: filen er ikke en rutetabelloppføring, og ruteoppføringen er ikke en eierskapserklæring.

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

Hvor hver av dem hører hjemme

Ruten går i serverens administrerte konfigurasjon, der den gjelder for den serverprosessen. Irouten går i den klientspesifikke filen som er navngitt etter grenenhetens autentiserte identitet.

Et filnavn som ikke samsvarer med den effektive identiteten, blir aldri lest, og symptomet er identisk med en manglende iroute. Kontroller identiteten serveren autentiserte, og kontroller deretter filnavnet tegn for tegn.

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

Hold poolen og grenprefikset atskilt, fordi overlapping mellom dem skaper et puslespill ingen direktiv kan løse.

Hva en annen klient trenger

En annen klient som skal nå den grenen, trenger en annonsering, ikke eierskap. Skyv prefikset til klientene du har tenkt på, i den klient- eller gruppekonteksten som passer konfigurasjonen din.

Ikke send det til grenen selv, siden den enheten allerede har prefikset som et tilkoblet nettverk.

Å sende det til alle er et valg med konsekvenser: hver klient tror da at grenen er nåbar gjennom tunnelen, også klienter du aldri hadde tenkt å gi den tilgangen. Annonsering er i praksis en tilgangsbeslutning, selv om direktivet ser ut som rørleggerarbeid. Den referansen for serveralternativer dokumenterer iroute-ipv6 som klientspesifikt eierskap, og det er skillet som er verdt å beholde.

Returveien på grenenheten

Eierskap hjelper bare hvis grenen videresender pakker og LAN-et dens vet hvordan det skal svare. Aktiver IPv6-videresending på grenenheten, og bekreft at verter på LAN-et sender trafikk for VPN-poolen tilbake mot grenen i stedet for mot en standardrute som ikke kjenner poolen.

Den returveien er IPv6-ekvivalenten til manglende-rute-problemet folk møter med IPv4.

Kontroller det fra en LAN-vert med et oppslag for VPN-pooladressen, ikke fra grenen selv. Et oppslag på ruteren besvarer et annet spørsmål enn det brukerne dine stiller, og de to er uenige ofte nok til å være den ekstra kommandoen verdt.

Når paret fortsatt ikke er nok

Noen utplasseringer bruker ikke denne veien i det hele tatt. Kjernens datastiv og produktstyrte servere har sin egen støttede rutehåndtering, og et userspace-eksempel oversettes kanskje ikke direkte.

Bekreft hvilket datastiv bygget ditt bruker før du kopierer direktiver fra en veiledning skrevet for det andre.

Husk til slutt adresseomfanget: et unikt lokalt prefiks som fd00:7a::/64 er privat av design og sier ingenting om offentlig IPv6-nåbarhet. Behandle det som intern tilgang, og hold internett-utgang som et eget spørsmål med sin egen policy.