Jeden koncentrator OpenVPN, trzy sieci LAN: plan adresacji i pliki iroute

Trzy prywatne sieci LAN mogą spotkać się na jednym koncentratorze bez tego, by którakolwiek lokalizacja musiała znać wewnętrzną budowę pozostałych, a cały projekt opiera się na czterech krótkich decyzjach konfiguracyjnych. Działa to nie dzięki egzotycznej funkcji protokołu, lecz dzięki planowi adresacji, którego nikt nie musi zgadywać, oraz trasom dla poszczególnych klientów, które mówią koncentratorowi, który oddział posiada który prefiks. Jeśli jedno z nich jest błędne, tunel i tak się podnosi, i właśnie to czyni awarię mylącą.

Wykonaj kroki po kolei. Każdy zależy od planu z poprzedniego kroku, a żaden nie wymaga nowego urzędu certyfikacji.

Zacznij od planu, którego nikt nie musi zgadywać

Zapisz cztery rozłączne prefiksy, zanim dotkniesz pliku konfiguracyjnego: sieć LAN samego koncentratora, sieć LAN każdego oddziału oraz pulę przydzielaną klientom wędrującym. Rozłączność utrzymuje wszystko inne w prostocie, ponieważ nakładające się zakresy zamieniają trasowanie w łamigłówkę najdłuższego dopasowania, której nie naprawi żadna konfiguracja dla poszczególnych klientów. Następnie ustal, która maszyna jest bramą domyślną każdej sieci LAN, ponieważ router oddziału, który nie jest bramą własnej sieci, musi zainstalować trasy zdalne zupełnie gdzie indziej. Na koniec ustal uwierzytelnione nazwy identyfikujące każdy oddział, ponieważ te nazwy są kluczami, po których wyszukiwane są pliki dla poszczególnych klientów.

Przykładowy plan trzyma pulę z dala od trzech sieci LAN. Twój będzie inny, a jedyną twardą regułą jest to, że żadne dwa zakresy się nie nakładają.

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

Powiedz jądru koncentratora, gdzie są oddziały

Koncentrator potrzebuje dwóch informacji na oddział: trasy jądra, która wysyła prefiks do urządzenia tunelowego, oraz wpisu iroute, który mówi procesowi OpenVPN, który klient jest jego właścicielem. Sama trasa jądra dostarcza pakiety do tunelu i na tym się zatrzymuje, ponieważ demon wciąż musi zdecydować, który peer ma je odebrać. Sam wpis iroute pozostawia te pakiety w jądrze bez trasy do przejścia. Obie linie należą do konfiguracji, którą demon faktycznie ładuje, i warto to sprawdzić, zanim zaczniesz debugować cokolwiek innego.

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

Trzymaj client-to-client wyłączone, gdy jądro ma być punktem egzekwowania reguł. Ta opcja przekazuje ruch między peerami wewnątrz demona, co jest wygodne i jednocześnie oznacza, że twoje reguły przekazywania nigdy nie widzą tego przepływu. Wszystko poniżej zakłada, że jądro widzi każdy pakiet między oddziałami.

Daj każdemu oddziałowi potrzebne trasy

Każdy oddział potrzebuje tras do pozostałych oddziałów i do sieci LAN koncentratora, a nie potrzebuje trasy do własnej podłączonej sieci. Wypychaj prefiksy zdalne z koncentratora, zamiast wklejać je do każdego routera, dzięki czemu czwarta lokalizacja później oznacza jeden nowy plik dla klienta zamiast czterech zmian. Plik dla klienta zawiera też linię iroute, która trzyma własność i ogłoszenie w jednym miejscu. Uczyń katalog i jego pliki czytelnymi zgodnie z modelem uprawnień serwera, inaczej wyszukiwanie zawodzi bez komunikatu.

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

Czwarta lokalizacja stosuje ten sam wzorzec: odrębna uwierzytelniona nazwa, posiadany prefiks, trasa jądra na koncentratorze, wpis iroute oraz ogłoszenia tylko do lokalizacji, którym wolno ją osiągnąć.

Przetestuj w obu kierunkach, zanim uznasz to za skończone

Włącz przekazywanie IPv4 na wszystkich trzech routerach, a następnie potwierdź, że zapora przepuszcza zamierzone przepływy w obu kierunkach, ponieważ test jednokierunkowy przechodzi z zepsutą trasą powrotną częściej, niż ktokolwiek się spodziewa. Między lokalizacjami nie jest potrzebne tłumaczenie adresu źródłowego, a zachowanie oryginalnego źródła jest właśnie tym, co pozwala każdemu oddziałowi zastosować własną politykę do żądania.

Przetestuj z hosta w jednej sieci LAN oddziału do usługi w innej, potem odwróć kierunek, a potem przetestuj z oddziału do sieci LAN koncentratora. Te trzy wyniki są różnymi dowodami i żaden nie implikuje pozostałych. Jeśli router oddziału nie jest bramą domyślną jego sieci LAN, zainstaluj prefiksy zdalne na prawdziwej bramie i uwzględnij też pulę, gdy klienci tunelu muszą rozpocząć połączenia do tej sieci.

Zapisz plan, pliki dla klientów i reguły zapory jako jeden dokument, ponieważ następne dodanie lokalizacji będzie oceniane według nich.

Projekt trzyma się razem, ponieważ każda warstwa ma jedno zadanie: plan utrzymuje unikalność prefiksów, trasa jądra przenosi pakiety, iroute nazywa właściciela, a zapora decyduje, co jest dozwolone. Gdy coś się psuje, ta lista jest także kolejnością sprawdzania.