Klienci podrzędni za nadrzędnym VPN: trasa czy NAT?
Nadrzędny VPN zna tylko adres klienta, więc przekazywanie innej podsieci wymaga uzgodnionej trasy lub celowego tłumaczenia źródła.
Jedna brama uruchamia WireGuard dla twoich własnych urządzeń i klienta OpenVPN do cudzej sieci. Przekazywanie między dwoma wewnętrznymi interfejsami działa i łatwo dojść do wniosku, że podsieć podrzędna jest już częścią usługi nadrzędnej. Nie jest. Trasa pobrana przez klienta mówi twojej bramie, gdzie wysyłać żądania; nie mówi nic o tym, jak zdalna sieć zwraca ruch urządzeniom, o których nigdy nie słyszała. Wybierz model powrotu, który usługa nadrzędna naprawdę obsługuje, zanim dodasz choć jedną regułę.
Zdecyduj o modelu powrotu, zanim dotkniesz routingu
W tym omówieniu klienci podrzędni używają 10.90.0.0/24, przypisany bramie adres tunelu nadrzędnego to 10.80.0.6, a zatwierdzony zasób zdalny to 172.20.0.30. Do tego kształtu pasują dwa modele: zachować źródło podrzędne i skłonić drugą stronę do routowania go albo przetłumaczyć źródło na własny adres tunelu bramy. Wszystko po tej decyzji jest mechaniczne, a sama decyzja wymaga właściciela usługi. Jeden wiersz powyżej to umowa o routingu ze zdalną stroną; drugi to lokalna zmiana polityki, którą możesz zrobić sam. Mylenie tych dwóch zamienia dziesięciominutową zmianę w negocjacje.
preserved: 10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6 -> 172.20.0.30Wybierz jeden wiersz i trzymaj się go. Wiersze są alternatywami, nie krokami, a ich mieszanie daje projekt, którego nikt nie potrafi wyjaśnić podczas przeglądu.
Zachowanie źródła przez routing
Zdalna strona otrzymuje żądanie z adresu podrzędnego, więc potrzebuje obsługiwanej trasy i własności peer dla tej podsieci, a także upoważnienia do jej przyjęcia. To ustawienia zdalne i żadna lokalna trasa Linux ich nie tworzy. Poproś o nie wprost i na piśmie, wraz z prefiksem i tym peerem tunelu, który będzie go przenosił, i spodziewaj się, że odpowiedź zależeć będzie od tego, czy usługa w ogóle obsługuje rozwiązania lokacja-lokacja.
Jeśli odpowiedź brzmi tak, lokalna konfiguracja jest niewielka: włączone przekazywanie, allowed-ips peera WireGuard obejmujące zakres podrzędny i polityka firewalla zezwalająca na przejście w obu kierunkach.
Celowe tłumaczenie źródła
Jeśli usługa zwraca ruch tylko na adres podłączonego klienta, przetłumacz źródło na ten adres na wyjściu i zachowaj stan conntrack, który odwraca je dla odpowiedzi. Ogranicz regułę do zamierzonych źródeł podrzędnych, zamierzonych celów zdalnych i interfejsu nadrzędnego. Reguła tłumacząca wszystko, co wychodzi z każdego interfejsu, to znacznie większa polityka niż to wymaganie i zaskoczy cię później.
IPv6 wymaga własnego projektu; kopiowanie wiersza masquerade dla IPv4 nie jest architekturą. Przetestuj przetłumaczoną ścieżkę nowym połączeniem, a nie zapisanym w pamięci podręcznej.
Lokalna ścieżka danych nadal musi działać
Tłumaczenie nie usuwa lokalnej pracy: brama nadal potrzebuje trasy do celów podrzędnych, właściwej własności źródła peera WireGuard, włączonego przekazywania i wąskiej polityki firewalla między interfejsami. Żądanie utworzone na samej bramie nie ćwiczy żadnego z tych uprawnień, dlatego lokalne testy na bramie przechodzą, a urządzenia podrzędne nadal zawodzą.
Testuj z rzeczywistego urządzenia podrzędnego, a nie z bramy. Adres źródłowy jest całą istotą tego ćwiczenia.
Jedno źródło oznacza jedną tożsamość sesji
Zdalna usługa widzi uwierzytelnioną sesję bramy i jej przetłumaczony adres, a nie niezależne uwierzytelnianie dla każdego urządzenia podrzędnego. Utrzymuj jawne uprawnienia na urządzenie i tożsamości aplikacji oraz potwierdź u właściciela usługi, że brama działająca w imieniu kilku urządzeń jest w ogóle dozwolona. Tłumaczenie nie jest sposobem obejścia wymogu rejestracji każdego urządzenia; jeśli usługa wymaga rejestracji każdego urządzenia, użyj tego modelu albo wynegocjuj rozwiązanie lokacja-lokacja.
Zapisz to potwierdzenie w runbooku obok reguły, bo następny recenzent zapyta, czy projekt został zatwierdzony, czy był tylko wygodny.
Zdefiniuj stan rozłączenia, a następnie przetestuj trzy żądania
Zdecyduj, co się dzieje, gdy tunel nadrzędny padnie. Autoryzowany ruch zdalny nie powinien po cichu podążać zwykłą trasą zapasową WAN tam, gdzie jest to zabronione, więc polityka firewalla zezwalająca na przejście powinna także zawodzić w stanie zamkniętym. Następnie przetestuj trzy przypadki z rzeczywistego urządzenia podrzędnego: dozwolone żądanie, które działa, niedozwolone żądanie, które zawodzi, oraz awarię nadrzędną, która zatrzymuje dozwolone.
Zapisz wycofanie w jednym wierszu na regułę, aby zmianę można było cofnąć bez odtwarzania intencji.