Dlaczego kopiowanie konfiguracji serwera OpenVPN do oddziału się nie udaje

Skopiowanie działającej konfiguracji serwera, zmiana kilku adresów i nazwanie tego profilem oddziału zwykle daje połączenie. To najgorszy wynik, bo oddział działa wtedy z niewłaściwą rolą, ujawnia materiał, który nie powinien opuścić koncentratora, i zostawia powiązanie trasy, którego nikt nie pamięta, że utworzył. Połączenie ukrywa trzy problemy naraz, a tunel wstaje, zanim ktokolwiek je sprawdzi.

Traktowanie oddziału jako peera z własną tożsamością i rolą sieciową jest tym, co czyni profil poprawnym. Poprawka nie polega na lepszej kopii, a reszta tej strony dotyczy tego, co klient powinien naprawdę trzymać.

Dwie role, które wyglądają jak jeden plik

W trybie TLS obie strony mają zadania uzupełniające się. Jedna strona nasłuchuje, trzyma certyfikat i klucz serwera i decyduje, które klienty mogą się łączyć. Druga strona inicjuje, weryfikuje nasłuchującego i przedstawia własną tożsamość.

Plik serwera zawiera dyrektywy, które na kliencie nie mają sensu: adres przypisania i port do nasłuchu, pula adresów do rozdzielenia i często lista wypychania ustawień, które klienty mają otrzymać. Skopiowanie ich do oddziału daje urządzenie, które próbuje być jednocześnie nasłuchującym i klientem.

Klucz prywatny to część, która liczy się najbardziej. Klient nigdy nie może nosić klucza prywatnego serwera i nie potrzebuje też klucza podpisywania CA. Certyfikat CA jest publicznym materiałem zaufania; klucz podpisywania należy do miejsca, w którym wydaje się certyfikaty.

Co musi zawierać profil oddziału

Profil oddziału potrzebuje zdalnego punktu końcowego i transportu, zaufanej tożsamości serwera, własnego certyfikatu i klucza oddziału oraz tras i ustawień DNS, których oddział naprawdę wymaga. Nic więcej nie jest obowiązkowe.

Trzymaj tożsamość oddziału osobno dla każdej lokalizacji. Dwa oddziały dzielące jeden certyfikat oznaczają, że unieważnienie jednego wyłącza drugi, a logi koncentratora nie potrafią ich rozróżnić. Tożsamość na lokalizację sprawia, że działa i ścieżka audytu, i historia unieważnienia.

Uważaj na przepływy pracy urządzeń. Pakiet Client Export pfSense tworzy profile dla kwalifikujących się kontekstów Remote Access, a jego lista serwerów obejmuje tylko serwery skonfigurowane w trybie Remote Access. Serwer lokacja-do-lokacji innego trybu nie pojawia się, a ta nieobecność jest informacją, nie zaproszeniem do kopiowania sekretów serwera.

Jeśli urządzenie nie eksportuje potrzebnego profilu, użyj jego udokumentowanego przepływu klienta lokacja-do-lokacji albo zbuduj profil z obsługiwanego przykładu zainstalowanego wydania. Eksportuj kopię zapasową serwera do oddziału tylko wtedy, gdy planem jest odtworzenie serwera, a tak nie jest. Kopia zapasowa niesie też prywatny materiał koncentratora, więc przenoszenie jej do oddziału to decyzja o obchodzeniu się z kluczami, nie transfer pliku. Trzymaj ją na koncentratorze i generuj tożsamość klienta tam, gdzie wydaje się certyfikaty.

Powiązanie peera z siecią jest osobne

Klient oddziału, który połączy się pomyślnie, nadal nie może przepuszczać ruchu dla swojej sieci LAN, dopóki koncentrator nie wie, że ten peer posiada ten prefiks. To powiązanie żyje na koncentratorze, związane z tożsamością klienta, i jest osobne od własnej trasy oddziału do sieci zdalnych. Bez niego hosty oddziału wyglądają na osiągalne w statystykach tunelu, a w praktyce nie są. Log koncentratora jest miejscem, w którym potwierdza się, czy powiązanie zostało zastosowane.

Dodanie trasy w systemie operacyjnym koncentratora to nie to samo, co powiedzenie OpenVPN, który klient posiada prefiks. Bez powiązania dla każdego klienta pakiet dociera do interfejsu tunelu i jest odrzucany, bo żaden peer nie rości sobie celu.

Po stronie oddziału odpowiednia potrzeba to trasa do sieci, do których ma dotrzeć, plus router LAN, który wie, jak zwrócić ruch do oddziału. Własność po stronie serwera i trasy docelowe po stronie klienta to różne obiekty, a działający tunel dowodzi tylko pierwszego skoku. Zapisz oba w notatkach przekazania oddziału, bo następny inżynier znajdzie tylko jedno z nich.

Udowodnienie, że oddział jest peerem, którego masz na myśli

Zweryfikuj tożsamość, zanim zweryfikujesz ruch. Log koncentratora powinien pokazywać nazwę pospolitą certyfikatu oddziału, a adres otrzymany przez klienta powinien zgadzać się z pulą lub stałym przydziałem, który miałeś na myśli. Jeśli log pokazuje inną nazwę, profil niesie tożsamość kogoś innego.

Następnie zweryfikuj powiązanie, wysyłając jedno żądanie z hosta w oddziale do zasobu po stronie koncentratora i potwierdzając, że kończy się sukcesem z oczekiwanym adresem źródłowym. Przetestuj cel, do którego oddział nie powinien dotrzeć, i potwierdź, że się nie udaje, bo trasa permisywna, która przypadkiem działa, to nie to samo co poprawna polityka.

Na koniec unieważnij tożsamość oddziału i potwierdź, że połączenie przestaje działać, podczas gdy własny certyfikat koncentratora i inne lokalizacje nadal działają. Jeśli unieważnienie psuje koncentrator, role i tożsamości były gdzieś współdzielone, i to jest wniosek wart zabrania z powrotem do projektu.

Ukończony oddział to taki z udokumentowaną tożsamością, profilem tylko dla klienta, powiązaniem peera z siecią na koncentratorze i przetestowaną drogą powrotną. Odwrócenie tekstu w pliku serwera nie daje ci żadnego z nich.