IPv6-grenepræfiks: iroute-ipv6 eller route-ipv6 på serveren?

To direktiver med næsten samme navn optræder i hvert fungerende eksempel, og kopierer man det ene uden det andet, får man en tunnel, der ser korrekt ud og i stilhed taber grenepræfikset. De gør forskelligt arbejde på hver sin side af samme grænse: det ene lærer serverens kerne, hvor et præfiks bor, og det andet fortæller OpenVPN hvilken autentificeret klient der bærer det. Få begge rigtige, og præfikset flyder; få det ene rigtigt, og pakkerne har en rute men ingen ejer.

To direktiver, to forskellige opgaver

route-ipv6 er en almindelig ruteinstallation: serveren tilføjer en kernerute, der peger præfikset mod sin tunnelgrænseflade. iroute-ipv6 hører til en klientspecifik kontekst og erklærer internt ejerskab, så daemonen ved, at trafik for det præfiks skal sendes til en bestemt klient i stedet for til den peer, en kernerute tilfældigvis nævner.

Det ene handler om kernens videresendelsestabel, det andet om daemonens interne rutemodel. At holde dem adskilt forklarer, hvorfor en konfiguration, der ser komplet ud, stadig kan tabe præfikset. Det forklarer også, hvorfor det samme netværk optræder to gange i hvert fungerende eksempel. Ingen af linjerne er overflødige.

I det traditionelle userspace-setup er begge nødvendige, og de supplerer hinanden. En kernerute alene efterlader daemonen ude af stand til at vælge en peer. En iroute alene efterlader kernen uden en vej til tunnelen. Det er også her, det meste af forvirringen om per-klient-filer kommer fra: filen er ikke en rutetabelpost, og ruteposten er ikke en ejerskabserklæring.

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

Hvor hver af dem hører til

Ruten hører i serverens administrerede konfiguration, hvor den gælder for den serverproces. Irouten hører i den klientspecifikke fil, der er navngivet efter grenenhedens autentificerede identitet.

Et filnavn, der ikke svarer til den effektive identitet, læses aldrig, og symptomet er identisk med en manglende iroute. Kontroller den identitet, serveren autentificerede, og kontroller derefter 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 puljen og grenepræfikset adskilt, for overlap mellem dem skaber et puslespil, som intet direktiv kan løse.

Hvad en anden klient har brug for

En anden klient, der skal nå den gren, har brug for en annoncering, ikke ejerskab. Skub præfikset til de klienter, du vil, i den klient- eller gruppekontekst, der passer til din konfiguration.

Send det ikke til grenen selv, da den enhed allerede har præfikset som et tilsluttet netværk.

At sende det til alle er et valg med konsekvenser: hver klient tror derefter, at grenen kan nås gennem tunnelen, også klienter, du aldrig havde tænkt dig at give den adgang. Annoncering er i praksis en adgangsbeslutning, selv om direktivet ligner rørføring. Den reference for serverindstillinger dokumenterer iroute-ipv6 som klientspecifikt ejerskab, og det er den sondring, der er værd at beholde.

Returvejen på grenenheden

Ejerskab hjælper kun, hvis grenen videresender pakker, og dens LAN ved, hvordan det skal svare. Aktiver IPv6-videresendelse på grenenheden, og bekræft, at værter på dens LAN sender trafik for VPN-puljen tilbage mod grenen i stedet for mod en standardrute, der ikke kender puljen.

Den returvej er IPv6-ækvivalenten til det manglende-rute-problem, folk rammer med IPv4.

Kontroller det fra en LAN-vært med et opslag på VPN-puljens adresse, ikke fra grenen selv. Et opslag på routeren besvarer et andet spørgsmål end det, dine brugere stiller, og de to er uenige ofte nok til at være den ekstra kommando værd.

Når parret stadig ikke er nok

Nogle installationer bruger slet ikke denne vej. Kernens datastiv og produktstyrede servere har deres egen understøttede rutehåndtering, og et userspace-eksempel oversætter måske ikke direkte.

Bekræft, hvilket datastiv dit build bruger, før du kopierer direktiver fra en vejledning skrevet til det andet.

Husk til sidst adresseomfanget: et unikt lokalt præfiks som fd00:7a::/64 er privat af design og siger intet om offentlig IPv6-rækkevidde. Behandl det som intern adgang, og hold internetudgang som et særskilt spørgsmål med sin egen politik.