IPv6-grenprefix: iroute-ipv6 eller route-ipv6 på servern?

Två direktiv med nästan samma namn finns i varje fungerande exempel, och kopierar man det ena utan det andra får man en tunnel som ser korrekt ut och tyst tappar grenprefixet. De gör olika jobb på var sin sida av samma gräns: det ena lär serverns kärna var ett prefix bor, och det andra talar om för OpenVPN vilken autentiserad klient som bär det. Få båda rätt och prefixet flödar; få ett rätt och paketen har en rutt men ingen ägare.

Två direktiv, två olika jobb

route-ipv6 är en vanlig ruttinstallation: servern lägger till en kärnrutt som pekar prefixet mot sitt tunnelgränssnitt. iroute-ipv6 hör till en klientspecifik kontext och deklarerar internt ägarskap, så daemonen vet att trafik för det prefixet ska skickas till en viss klient i stället för till vilken peer en kärnrutt råkar peka ut.

Det ena handlar om kärnans vidarebefordringstabell, det andra om daemonens interna ruttmodell. Att hålla dem isär förklarar varför en konfiguration som ser komplett ut ändå kan tappa prefixet. Det förklarar också varför samma nätverk förekommer två gånger i varje fungerande exempel. Ingen av raderna är överflödig.

I den traditionella userspace-uppsättningen behövs båda och de kompletterar varandra. En kärnrutt ensam lämnar daemonen oförmögen att välja en peer. En iroute ensam lämnar kärnan utan en väg till tunneln. Det är också härifrån det mesta av förvirringen kring per-klientfiler kommer: filen är inte en ruttabellspost, och ruttposten är inte en ägandedeklaration.

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

Var och en hör hemma

Rutten går i serverns hanterade konfiguration, där den gäller för den serverprocessen. Irouten går i den klientspecifika filen som är namngiven efter grenenhetens autentiserade identitet.

Ett filnamn som inte matchar den effektiva identiteten läses aldrig, och symptomet är identiskt med en saknad iroute. Kontrollera identiteten som servern autentiserade och kontrollera sedan filnamnet tecken för tecken.

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

Håll poolen och grenprefixet åtskilda, eftersom överlapp dem emellan skapar ett pussel som inget direktiv kan lösa.

Vad en annan klient behöver

En andra klient som ska nå den grenen behöver en annonsering, inte ägarskap. Skicka prefixet till de klienter du avser, i det klient- eller gruppsammanhang som passar din konfiguration.

Skicka det inte till grenen själv, eftersom den enheten redan har prefixet som ett anslutet nätverk.

Att skicka det till alla är ett val med konsekvenser: varje klient tror då att grenen nås via tunneln, även klienter som du aldrig tänkt ge den åtkomsten. Annonsering är i praktiken ett åtkomstbeslut, även om direktivet ser ut som rörarbete. Den referens för serveralternativ dokumenterar iroute-ipv6 som klientspecifikt ägarskap, och det är den distinktion som är värd att behålla.

Returvägen på grenenheten

Ägarskap hjälper bara om grenen vidarebefordrar paket och dess LAN vet hur det ska svara. Aktivera IPv6-vidarebefordran på grenenheten och bekräfta att värdar på dess LAN skickar trafik för VPN-poolen tillbaka mot grenen i stället för mot en standardrutt som inte känner till poolen.

Den returvägen är IPv6-motsvarigheten till det saknade-rutt-problem som folk drabbas av med IPv4.

Kontrollera det från en LAN-värd med en uppslagning av VPN-poolens adress, inte från grenen själv. En uppslagning på routern besvarar en annan fråga än den dina användare ställer, och de två är oeniga tillräckligt ofta för att vara det extra kommandot värt.

När paret fortfarande inte räcker

Vissa installationer använder inte den här vägen alls. Kärnans dataväg och produktstyrda servrar har sin egen rutt hantering med stöd, och ett userspace-exempel översätts kanske inte direkt.

Bekräfta vilken dataväg din build använder innan du kopierar direktiv från en handledning som är skriven för den andra.

Kom till sist ihåg adressomfånget: ett unikt lokalt prefix som fd00:7a::/64 är privat av design och säger inget om offentlig IPv6-nåbarhet. Behandla det som intern åtkomst och håll internetutgång som en separat fråga med egen policy.