IPv6-branĉa prefikso: iroute-ipv6 aŭ route-ipv6 sur la servilo?

Du direktivoj kun preskaŭ sama nomo aperas en ĉiu funkcianta ekzemplo, kaj kopii unu sen la alia produktas tunelon, kiu aspektas ĝusta kaj silente forlasas la branĉan prefikson. Ili faras malsamajn taskojn sur malsamaj flankoj de la sama limo: unu instruas al la kerno de la servilo, kie loĝas prefikso, kaj la alia instruas al OpenVPN kiu aŭtentikigita kliento portas ĝin. Se ambaŭ ĝustas, la prefikso fluas; se unu ĝustas, la pakaĵoj havas itineron sed ne posedanton.

Du direktivoj, du malsamaj taskoj

route-ipv6 estas ordinara itinera instalado: la servilo aldonas kernan itineron, kiu direktas la prefikson al sia tunela interfaco. iroute-ipv6 apartenas al klient-specifa kunteksto kaj deklaras internan posedon, tiel ke la demono scias, ke trafiko por tiu prefikso sendiĝu al difinita kliento anstataŭ al la peer, kiun kernita itinero hazarde nomas.

Unu temas pri la plusenda tabelo de la kerno, la alia pri la interna itinmodelo de la demono. Teni ilin aparte klarigas, kial agordo, kiu aspektas kompleta, tamen povas forlasi la prefikson. Ĝi ankaŭ klarigas, kial la sama reto aperas dufoje en ĉiu funkcianta ekzemplo. Neniu el la du linioj estas superflua.

En la tradicia userspace-agordo ambaŭ necesas kaj ili kompletigas unu la alian. Kerna itinero sola lasas la demonon nekapabla elekti peer. iroute sola lasas la kernon sen vojo al la tunelo. De ĉi tie ankaŭ venas la plej granda parto de la konfuzo pri dosieroj por kliento: la dosiero ne estas ero de itinera tabelo, kaj la itinero ne estas deklaro de posedo.

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

Kie ĉiu apartenas

La itinero iras en la administritan agordon de la servilo, kie ĝi validas por tiu servila procezo. La iroute iras en la klient-specifan dosieron, nomitan laŭ la aŭtentikigita identeco de la branĉa aparato.

Dosiernomo, kiu ne kongruas kun la efektiva identeco, neniam estas legata, kaj la simptomo estas identa al mankanta iroute. Kontrolu la identecon, kiun la servilo aŭtentikigis, poste kontrolu la dosiernomon signon post signo.

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

Tenu la pool kaj la branĉan prefikson apartaj, ĉar ilia interkovro kreas enigmon, kiun neniu direktivo povas solvi.

Kion bezonas alia kliento

Dua kliento, kiu devus atingi tiun branĉon, bezonas anoncon, ne posedon. Puŝu la prefikson al la klientoj, kiujn vi celas, en la klienta aŭ grupa kunteksto, kiu taŭgas por via agordo.

Ne sendu ĝin al la branĉo mem, ĉar tiu aparato jam havas la prefikson kiel konektitan reton.

Sendi ĝin al ĉiuj estas elekto kun sekvoj: ĉiu kliento tiam kredas, ke la branĉo estas atingebla tra la tunelo, inkluzive de klientoj, al kiuj vi neniam intencis doni tiun aliron. Anonco estas praktike alira decido, kvankam la direktivo aspektas kiel tubinstalado. La referenco pri servilaj opcioj dokumentas iroute-ipv6 kiel klient-specifan posedon, kaj tio estas la distingo, kiun indas konservi.

La revena vojo sur la branĉa aparato

Posedo helpas nur se la branĉo plusendas pakaĵojn kaj ĝia LAN scias kiel respondi. Ŝaltu IPv6-plusendadon sur la branĉa aparato, kaj konfirmu, ke gastigantoj en ĝia LAN sendas trafikon por la VPN-pool reen al la branĉo anstataŭ al defaŭlta itinero, kiu ne konas la pool.

Tiu revena vojo estas la IPv6-ekvivalento de la problemo pri mankanta itinero, kiun homoj renkontas kun IPv4.

Kontrolu ĝin de LAN-gastiganto per serĉo de la adreso de la VPN-pool, ne de la branĉo mem. Serĉo farita sur la enkursigilo respondas alian demandon ol tiu, kiun viaj uzantoj faras, kaj la du malkongruas sufiĉe ofte por indi la plian komandon.

Kiam la paro ankoraŭ ne sufiĉas

Iuj deplojoj tute ne uzas ĉi tiun vojon. La kerna datenvojo kaj produkt-administritaj serviloj havas sian propran subtenatan itineran traktadon, kaj userspace-ekzemplo eble ne tradukiĝas rekte.

Konfirmu, kiun datenvojon via konstruo uzas, antaŭ ol kopii direktivojn el lernilo skribita por la alia.

Fine, memoru la adresan amplekson: unika loka prefikso kiel fd00:7a::/64 estas privateca laŭdezajne kaj diras nenion pri publika IPv6-atingeblo. Traktu ĝin kiel internan aliron, kaj tenu la interretan eliron aparta demando kun sia propra politiko.