IPv6-greinsprefiks: iroute-ipv6 eller route-ipv6 på tenaren?

To direktiv med nesten same namn dukkar opp i kvart fungerande døme, og å kopiere det eine utan det andre gjev ein tunnel som ser rett ut og stille droppar greinsprefikset. Dei gjer ulike jobbar på kvar si side av den same grensa: det eine lærer kjernen på tenaren kvar eit prefiks held til, og det andre lærer OpenVPN kva autentisert klient som ber det. Får du begge rett, flyt prefikset; får du berre éin rett, har pakkane ei rute men ingen eigar.

To direktiv, to ulike jobbar

route-ipv6 er ein vanleg ruteinstallasjon: tenaren legg til ei kjernerute som peikar prefikset mot tunnelgrensesnittet sitt. iroute-ipv6 høyrer til ein klientspesifikk kontekst og erklærer intern eigarskap, så daemonen veit at trafikk for det prefikset skal sendast til ein bestemt klient og ikkje til den peeren ei kjernerute tilfeldigvis namngir.

Det eine handlar om videresendingstabellen i kjernen, det andre om den interne rutemodellen til daemonen. Å halde dei frå kvarandre forklarar kvifor ein konfigurasjon som ser komplett ut likevel kan droppe prefikset. Det forklarar òg kvifor det same nettet dukkar opp to gonger i kvart fungerande døme. Ingen av linjene er overflødige.

I det tradisjonelle brukarrom-oppsettet trengst begge, og dei utfyller kvarandre. Berre ei kjernerute lèt daemonen utan moglegheit til å velje ein peer. Berre ein iroute lèt kjernen utan veg til tunnelen. Det er òg her det meste av forvirringa om per-klient-filer kjem frå: fila er ikkje ein rutetabelloppføring, og ruteoppføringa er ikkje ein eigarskapserklæring.

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

Kvar kvar av dei høyrer til

Ruta går i den styrte konfigurasjonen til tenaren, der ho gjeld for den tenarprosessen. iroute går i den klientspesifikke fila som er namngiven etter den autentiserte identiteten til greineininga.

Eit filnamn som ikkje passar med den effektive identiteten blir aldri lese, og symptomet er det same som ein manglande iroute. Sjekk identiteten tenaren autentiserte, og sjekk deretter filnamnet teikn for teikn.

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

Hald poolen og greinsprefikset frå kvarandre, fordi overlapping skapar eit puslespel som ingen direktiv kan løyse.

Kva ein annan klient treng

Ein andre klient som skal nå den greina treng ei annonsering, ikkje eigarskap. Skyv prefikset til dei klientane du vil, i den klient- eller gruppekonteksten som passar konfigurasjonen din.

Ikkje send det til greina sjølv, sidan den eininga allereie har prefikset som eit tilkopla nett.

Å sende det til alle er eit val med følgjer: kvar klient trur då at greina er nåbar gjennom tunnelen, også klientar du aldri meinte å gje den tilgangen. Annonsering er i praksis eit tilgangsval, sjølv om direktivet ser ut som røyrleggjarbeid. referansen for tenarval dokumenterer iroute-ipv6 som klientspesifikk eigarskap, og det er den skilnaden som er verdt å halde på.

Returvegen på greineininga

Eigarskap hjelper berre om greina vidaresender pakkar og LAN-et hennar veit korleis det skal svare. Slå på IPv6-vidaresending på greineininga, og stadfest at vertar på LAN-et hennar sender trafikk for VPN-poolen tilbake mot greina og ikkje mot ei standardrute som ikkje kjenner poolen.

Den returvegen er IPv6-motstykket til problemet med manglande rute som folk møter med IPv4.

Sjekk det frå ein LAN-vert med eit oppslag på VPN-pooladressa, ikkje frå greina sjølv. Eit oppslag på rutaren svarar på eit anna spørsmål enn det brukarane dine stiller, og dei to er samde sjeldan nok til at den ekstra kommandoen er verdt det.

Når paret framleis ikkje er nok

Nokre utrullingar brukar ikkje denne vegen i det heile. Datavvegen i kjernen og produktstyrte tenarar har si eiga støtta rutebehandling, og eit brukarrom-døme blir kanskje ikkje omsett direkte.

Stadfest kva datavveg bygget ditt brukar før du kopierer direktiv frå ein opplæring skriven for den andre.

Til slutt, hugs adresseomfanget: eit unikt lokalt prefiks som fd00:7a::/64 er privat av design og seier ingenting om offentleg IPv6-nåbarheit. Behandle det som intern tilgang, og hald internett-utgang som eit eige spørsmål med sin eigen politikk.