Prefix pobočky IPv6: iroute-ipv6, nebo route-ipv6 na serveru?

Dvě direktivy s téměř stejným názvem se objevují v každém funkčním příkladu a zkopírování jedné bez druhé vytvoří tunel, který vypadá správně a tiše zahodí prefix pobočky. Dělají různou práci na různých stranách stejné hranice: jedna učí jádro serveru, kde prefix žije, a druhá učí OpenVPN, který ověřený klient jej nese. Když jsou obě správně, prefix teče; když je správně jedna, pakety mají trasu, ale nemají vlastníka.

Dvě direktivy, dvě různé úlohy

route-ipv6 je běžná instalace trasy: server přidá trasu jádra, která ukazuje prefix na jeho tunelové rozhraní. iroute-ipv6 patří do kontextu specifického pro klienta a deklaruje vnitřní vlastnictví, takže démon ví, že provoz pro tento prefix má jít konkrétnímu klientovi, a ne tomu peerovi, kterého náhodou pojmenuje trasa jádra.

Jedna se týká předávací tabulky jádra, druhá vnitřního směrovacího modelu démona. Jejich oddržení vysvětluje, proč konfigurace, která vypadá úplně, může prefix přesto zahodit. Vysvětluje také, proč se stejná síť objevuje v každém funkčním příkladu dvakrát. Ani jeden z těch řádků není nadbytečný.

V tradičním userspace uspořádání jsou potřeba obě a vzájemně se doplňují. Samotná trasa jádra nechává démona neschopného vybrat peera. Samotný iroute nechává jádro bez cesty k tunelu. Odtud také pochází většina zmatení kolem souborů pro jednotlivé klienty: soubor není položka směrovací tabulky a položka trasy není prohlášení o vlastnictví.

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

Kam která patří

Trasa patří do spravované konfigurace serveru, kde platí pro tento proces serveru. iroute patří do souboru specifického pro klienta, pojmenovaného podle ověřené identity zařízení pobočky.

Název souboru, který neodpovídá skutečné identitě, se nikdy nečte, a příznak je stejný jako u chybějícího iroute. Zkontroluj identitu, kterou server ověřil, a potom zkontroluj název souboru znak po znaku.

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

Udržuj pool a prefix pobočky oddělené, protože jejich překrytí vytváří hádanku, kterou žádná direktiva nevyřeší.

Co potřebuje jiný klient

Druhý klient, který má dosáhnout této pobočky, potřebuje oznámení, ne vlastnictví. Pošli prefix klientům, které chceš, v klientském nebo skupinovém kontextu, který odpovídá tvé konfiguraci.

Neposílej ho samotné pobočce, protože to zařízení už má prefix jako připojenou síť.

Poslat ho všem je volba s následky: každý klient pak věří, že pobočka je dostupná přes tunel, včetně klientů, kterým jsi ten přístup nikdy dát nechtěl. Oznámení je v praxi rozhodnutím o přístupu, i když direktiva vypadá jako instalatérská práce. reference k volbám serveru dokumentuje iroute-ipv6 jako vlastnictví specifické pro klienta, a to je rozdíl, který stojí za to si ponechat.

Zpětná cesta na zařízení pobočky

Vlastnictví pomůže jen tehdy, když pobočka předává pakety a její LAN ví, jak odpovědět. Zapni předávání IPv6 na zařízení pobočky a ověř, že hostitelé v její LAN posílají provoz pro pool VPN zpět k pobočce, a ne k výchozí trase, která pool nezná.

Tato zpětná cesta je obdoba problému chybějící trasy pro IPv6, na kterou lidé narážejí u IPv4.

Ověř to z hostitele v LAN dotazem na adresu poolu VPN, ne z pobočky samotné. Dotaz provedený na routeru odpovídá na jinou otázku než tvoji uživatelé a oba se dost často rozcházejí, aby se ten příkaz navíc vyplatil.

Když dvojice stále nestačí

Některá nasazení tuto cestu vůbec nepoužívají. Datová cesta jádra a servery spravované produktem mají vlastní podporované zacházení s trasami a příklad pro userspace se nemusí přenést přímo.

Ověř, kterou datovou cestu tvůj build používá, než zkopíruješ direktivy z návodu psaného pro tu druhou.

Nakonec pamatuj na rozsah adres: jedinečný lokální prefix jako fd00:7a::/64 je soukromý ze zásady a nic neříká o veřejné dostupnosti IPv6. Ber ho jako interní přístup a odchod do internetu drž jako samostatnou otázku s vlastní politikou.