IPv6-takprefix: iroute-ipv6 of route-ipv6 op de server?

Twee richtlijnen met bijna dezelfde naam staan in elk werkend voorbeeld, en het kopiëren van de ene zonder de andere levert een tunnel op die er correct uitziet en het takprefix stilzwijgend laat vallen. Ze doen verschillend werk aan verschillende kanten van dezelfde grens: de ene leert de kernel van de server waar een prefix woont, en de andere leert OpenVPN welke geauthenticeerde client hem draagt. Doe beide goed en het prefix stroomt; doe er één goed en de pakketten hebben een route maar geen eigenaar.

Twee richtlijnen, twee verschillende taken

route-ipv6 is een gewone route-installatie: de server voegt een kernelroute toe die het prefix naar zijn tunnelinterface wijst. iroute-ipv6 hoort bij een clientspecifieke context en verklaart intern eigenaarschap, zodat de daemon weet dat verkeer voor dat prefix naar een bepaalde client moet worden gestuurd in plaats van naar welke peer een kernelroute ook noemt.

De ene gaat over de doorstuurtabel van de kernel, de andere over het interne routemodel van de daemon. Ze gescheiden houden verklaart waarom een configuratie die compleet lijkt het prefix alsnog kan laten vallen. Het verklaart ook waarom hetzelfde netwerk twee keer in elk werkend voorbeeld voorkomt. Geen van beide regels is overbodig.

In de traditionele userspace-opstelling zijn beide nodig en ze vullen elkaar aan. Een kernelroute alleen laat de daemon geen peer kunnen kiezen. Een iroute alleen laat de kernel zonder pad naar de tunnel. Dit is ook waar de meeste verwarring over per-clientbestanden vandaan komt: het bestand is geen routetabelvermelding, en de routevermelding is geen eigenaarsverklaring.

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

Waar elk van beide hoort

De route gaat in de beheerde configuratie van de server, waar hij op dat serverproces van toepassing is. De iroute gaat in het clientspecifieke bestand dat is genoemd naar de geauthenticeerde identiteit van het takapparaat.

Een bestandsnaam die niet overeenkomt met de effectieve identiteit wordt nooit gelezen, en het symptoom is identiek aan een ontbrekende iroute. Controleer de identiteit die de server heeft geauthenticeerd en controleer daarna de bestandsnaam teken voor teken.

# /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

Houd de pool en het takprefix gescheiden, want overlappen levert een puzzel op die geen enkele richtlijn kan oplossen.

Wat een andere client nodig heeft

Een tweede client die die tak moet bereiken heeft een aankondiging nodig, geen eigenaarschap. Stuur het prefix naar de clients die je bedoelt, in de client- of groepscontext die bij je configuratie past.

Stuur het niet naar de tak zelf, want dat apparaat heeft het prefix al als een verbonden netwerk.

Het naar iedereen sturen is een keuze met gevolgen: elke client gelooft dan dat de tak via de tunnel bereikbaar is, ook clients aan wie je die toegang nooit wilde geven. Aankondigen is in de praktijk een toegangsbeslissing, ook al ziet de richtlijn eruit als loodgieterswerk. De referentie voor serveropties documenteert iroute-ipv6 als clientspecifiek eigenaarschap, en dat is het onderscheid dat de moeite waard is.

Het retourpad op het takapparaat

Eigenaarschap helpt alleen als de tak pakketten doorstuurt en zijn LAN weet hoe het moet antwoorden. Schakel IPv6-doorsturing in op het takapparaat en bevestig dat hosts op zijn LAN verkeer voor de VPN-pool terug naar de tak sturen in plaats van naar een standaardroute die de pool niet kent.

Dat retourpad is het IPv6-equivalent van het ontbrekende-routeprobleem dat mensen met IPv4 tegenkomen.

Controleer het vanaf een LAN-host met een opzoeking voor het VPN-pooladres, niet vanaf de tak zelf. Een opzoeking op de router beantwoordt een andere vraag dan die van je gebruikers, en de twee verschillen vaak genoeg om het extra commando de moeite waard te maken.

Wanneer het paar nog niet genoeg is

Sommige implementaties gebruiken dit pad helemaal niet. Het kernel-datapad en door het product beheerde servers hebben hun eigen ondersteunde routeafhandeling, en een userspace-voorbeeld vertaalt zich mogelijk niet rechtstreeks.

Bevestig welk datapad jouw build gebruikt voordat je richtlijnen overneemt uit een handleiding die voor het andere is geschreven.

Onthoud tot slot de adresomvang: een uniek lokaal prefix zoals fd00:7a::/64 is ontworpen als privé en zegt niets over openbare IPv6-bereikbaarheid. Behandel het als interne toegang, en houd internetuitgang een aparte vraag met zijn eigen beleid.