Prefix ng sangay na IPv6: iroute-ipv6 o route-ipv6 sa server?

Dalawang direktiba na halos magkapareho ang pangalan ang lumilitaw sa bawat gumaganang halimbawa, at ang pagkopya ng isa nang wala ang isa ay gumagawa ng tunnel na mukhang tama at tahimik na ibinabagsak ang prefix ng sangay. Iba ang trabaho nila sa magkabilang panig ng iisang hangganan: itinuturo ng isa sa kernel ng server kung saan naroon ang isang prefix, at itinuturo ng isa pa sa OpenVPN kung aling authenticated na client ang nagdadala nito. Kung tama ang dalawa, dumadaloy ang prefix; kung isa lang ang tama, may ruta ang mga packet pero walang may-ari.

Dalawang direktiba, dalawang magkaibang trabaho

route-ipv6 ay ordinaryong pag-install ng ruta: nagdaragdag ang server ng kernel na ruta na itinuturo ang prefix sa interface ng tunnel nito. Ang iroute-ipv6 ay kabilang sa kontekstong partikular sa client at nagsasaad ng panloob na pagmamay-ari, kaya alam ng daemon na ang trapiko para sa prefix na iyon ay dapat ipadala sa isang partikular na client sa halip na sa sinumang peer na aksidenteng pinangalanan ng kernel na ruta.

Ang isa ay tungkol sa forwarding table ng kernel, ang isa pa sa panloob na modelo ng routing ng daemon. Ang paghihiwalay sa kanila ay nagpapaliwanag kung bakit ang isang configuration na mukhang kumpleto ay maaari pa ring magbagsak ng prefix. Ipinapaliwanag din nito kung bakit ang parehong network ay lumilitaw nang dalawang beses sa bawat gumaganang halimbawa. Walang linyang kalabisan.

Sa tradisyonal na setup ng userspace, kailangan ang dalawa at nagsasaklawan sila. Ang kernel na ruta lamang ay nag-iiwan sa daemon na hindi makapili ng peer. Ang iroute lamang ay nag-iiwan sa kernel na walang landas papunta sa tunnel. Dito rin nagmumula ang karamihan ng kalituhan tungkol sa mga file ng bawat client: ang file ay hindi entry ng routing table, at ang route entry ay hindi pahayag ng pagmamay-ari.

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

Kung saan dapat naroon ang bawat isa

Ang ruta ay pumupunta sa pinamamahalaang configuration ng server, kung saan nalalapat ito sa prosesong iyon ng server. Ang iroute ay pumupunta sa file na partikular sa client na pinangalanan ayon sa authenticated na pagkakakilanlan ng device ng sangay.

Ang filename na hindi tumutugma sa epektibong pagkakakilanlan ay hindi kailanman binabasa, at ang sintomas ay kapareho ng nawawalang iroute. Suriin ang pagkakakilanlang inautentika ng server, pagkatapos suriin ang filename nang karakter sa karakter.

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

Panatilihing hiwalay ang pool at ang prefix ng sangay, dahil ang pag-overlap nila ay lumilikha ng palaisipan na walang direktibang makakalutas.

Ano ang kailangan ng isa pang client

Ang pangalawang client na dapat makarating sa sangay na iyon ay nangangailangan ng advertisement, hindi pagmamay-ari. I-push ang prefix sa mga client na nilalayon mo, sa konteksto ng client o grupo na nababagay sa iyong configuration.

Huwag itong ipadala sa sangay mismo, dahil mayroon na ang device na iyon ng prefix bilang konektadong network.

Ang pagpapadala nito sa lahat ay isang pagpipilian na may mga kahihinatnan: pagkatapos ay naniniwala ang bawat client na maaabot ang sangay sa pamamagitan ng tunnel, kabilang ang mga client na hindi mo kailanman sinadyang bigyan ng access na iyon. Ang advertising sa pagsasagawa ay desisyon sa access, kahit ang direktiba ay mukhang gawaing plumbing. reference ng mga opsyon ng server ay nagdodokumento ng iroute-ipv6 bilang pagmamay-aring partikular sa client, at iyon ang pagkakaibang sulit panatilihin.

Ang return path sa device ng sangay

Nakakatulong lamang ang pagmamay-ari kung ang sangay ay nagpapasa ng mga packet at alam ng LAN nito kung paano sasagot. Paganahin ang IPv6 forwarding sa device ng sangay, at tiyakin na ang mga host sa LAN nito ay nagpapadala ng trapiko para sa pool ng VPN pabalik patungo sa sangay sa halip na patungo sa default na ruta na hindi alam ang pool.

Ang return path na iyon ay ang IPv6 na katumbas ng problemang nawawalang ruta na nararanasan ng mga tao sa IPv4.

Suriin ito mula sa isang host sa LAN gamit ang lookup para sa address ng pool ng VPN, hindi mula sa sangay mismo. Ang lookup na ginawa sa router ay sumasagot sa ibang tanong kaysa sa itinatanong ng iyong mga user, at ang dalawa ay sapat na madalas na hindi nagkakasundo para maging sulit ang dagdag na command.

Kapag hindi pa rin sapat ang pares

May mga deployment na hindi gumagamit ng landas na ito. Ang data path ng kernel at ang mga server na pinamamahalaan ng produkto ay may sariling suportadong paghawak ng ruta, at ang halimbawa ng userspace ay maaaring hindi direktang maisalin.

Tiyakin kung aling data path ang ginagamit ng iyong build bago kopyahin ang mga direktiba mula sa tutorial na isinulat para sa isa pa.

Sa huli, tandaan ang saklaw ng address: ang natatanging lokal na prefix tulad ng fd00:7a::/64 ay pribado ayon sa disenyo at walang sinasabi tungkol sa pampublikong pag-abot sa IPv6. Ituring itong panloob na access, at panatilihing hiwalay na tanong ang internet egress na may sariling patakaran.