Prefiks oddziału IPv6: iroute-ipv6 czy route-ipv6 na serwerze?

Dwie dyrektywy o niemal tej samej nazwie pojawiają się w każdym działającym przykładzie, a skopiowanie jednej bez drugiej daje tunel, który wygląda poprawnie i po cichu porzuca prefiks oddziału. Robią różne rzeczy po różnych stronach tej samej granicy: jedna uczy jądro serwera, gdzie mieszka prefiks, a druga uczy OpenVPN, który uwierzytelniony klient go przenosi. Jeśli obie są poprawne, prefiks płynie; jeśli jedna, pakiety mają trasę, ale nie mają właściciela.

Dwie dyrektywy, dwa różne zadania

route-ipv6 to zwykła instalacja trasy: serwer dodaje trasę jądra wskazującą prefiks na swój interfejs tunelu. iroute-ipv6 należy do kontekstu właściwego klientowi i deklaruje wewnętrzną własność, dzięki czemu demon wie, że ruch dla tego prefiksu ma trafiać do konkretnego klienta, a nie do tego peera, którego przypadkiem wymienia trasa jądra.

Jedna dotyczy tablicy przekazywania jądra, druga wewnętrznego modelu trasowania demona. Trzymanie ich osobno wyjaśnia, dlaczego konfiguracja, która wygląda na kompletną, wciąż może porzucić prefiks. Wyjaśnia też, dlaczego ta sama sieć pojawia się dwa razy w każdym działającym przykładzie. Żadna z tych linii nie jest zbędna.

W tradycyjnej konfiguracji userspace obie są potrzebne i uzupełniają się. Sama trasa jądra pozostawia demona bez możliwości wyboru peera. Sam iroute pozostawia jądro bez drogi do tunelu. Stąd bierze się też większość zamieszania wokół plików dla poszczególnych klientów: plik nie jest wpisem tablicy tras, a wpis trasy nie jest deklaracją własności.

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

Gdzie należy każda z nich

Trasa trafia do zarządzanej konfiguracji serwera, gdzie obowiązuje dla tego procesu serwera. iroute trafia do pliku właściwego klientowi, nazwanego według uwierzytelnionej tożsamości urządzenia oddziału.

Nazwa pliku, która nie odpowiada rzeczywistej tożsamości, nigdy nie jest czytana, a objaw jest identyczny z brakującym iroute. Sprawdź tożsamość, którą uwierzytelnił serwer, a potem sprawdź nazwę pliku 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

Trzymaj pulę i prefiks oddziału osobno, bo ich nakładanie się tworzy zagadkę, której nie rozwiąże żadna dyrektywa.

Czego potrzebuje inny klient

Drugi klient, który ma dotrzeć do tego oddziału, potrzebuje ogłoszenia, a nie własności. Wypchnij prefiks do klientów, których chcesz, w kontekście klienta lub grupy pasującym do twojej konfiguracji.

Nie wysyłaj go do samego oddziału, bo to urządzenie ma już prefiks jako sieć podłączoną.

Wysłanie go do wszystkich to wybór z konsekwencjami: każdy klient wierzy wtedy, że oddział jest osiągalny przez tunel, łącznie z klientami, którym nigdy nie chciałeś dać tego dostępu. Ogłaszanie jest w praktyce decyzją o dostępie, choć dyrektywa wygląda jak robota hydrauliczna. odnośnik do opcji serwera dokumentuje iroute-ipv6 jako własność właściwą klientowi, i to jest rozróżnienie, które warto zachować.

Droga powrotna na urządzeniu oddziału

Własność pomaga tylko wtedy, gdy oddział przekazuje pakiety, a jego sieć LAN wie, jak odpowiedzieć. Włącz przekazywanie IPv6 na urządzeniu oddziału i potwierdź, że hosty w jego sieci LAN wysyłają ruch dla puli VPN z powrotem do oddziału, a nie do trasy domyślnej, która tej puli nie zna.

Ta droga powrotna to odpowiednik IPv6 problemu brakującej trasy, na który ludzie trafiają przy IPv4.

Sprawdź to z hosta w sieci LAN zapytaniem o adres puli VPN, a nie z samego oddziału. Zapytanie wykonane na routerze odpowiada na inne pytanie niż twoi użytkownicy, a te dwa odpowiedzi wystarczająco często się różnią, by dodatkowe polecenie miało sens.

Kiedy ta para wciąż nie wystarcza

Niektóre wdrożenia w ogóle nie używają tej drogi. Ścieżka danych jądra i serwery zarządzane przez produkt mają własną obsługę tras, a przykład dla userspace może nie przekładać się bezpośrednio.

Potwierdź, której ścieżki danych używa twoja kompilacja, zanim skopiujesz dyrektywy z poradnika pisanego dla tej drugiej.

Na koniec pamiętaj o zakresie adresów: unikalny prefiks lokalny taki jak fd00:7a::/64 jest prywatny z założenia i nic nie mówi o publicznej osiągalności IPv6. Traktuj go jako dostęp wewnętrzny, a wyjście do internetu trzymaj jako osobną kwestię z własną polityką.