Procedura: osobne wdrożenie dwóch klientów OpenVPN

Dwóch klientów na jednym hoście brzmi jak jeszcze jeden blok serwera i drugi port. Staje się innym projektem, gdy wymienisz wszystko, co klient naprawdę posiada: nasłuch, pulę tuneli, tożsamość, pliki zaufania, trasy i harmonogram unieważnień. Pomiń jeden z tych elementów, a drugi klient po cichu odziedziczy część pierwszego. Zbuduj kartę dla każdego klienta i wypełnij ją, zanim pierwszy klient się połączy.

Przydziel każdemu klientowi pełną kartę zasobów

Zarezerwuj cały zestaw razem: port publiczny, podsieć tunelu, ścieżkę konfiguracji, miejsce docelowe logów, nazwę instancji usługi i urządzenie. Nazwanie ich grupą jest tym, co zapobiega klasycznej kopii działającego pliku, która nadal zawiera pulę lub interfejs pierwszego klienta. Wartości są przykładami, a nie zarezerwowanymi portami, więc sprawdź, czego host już używa. Usługa, która startuje, to nie to samo co kompletny klient.

Trzymaj kartę obok konfiguracji i aktualizuj ją za każdym razem, gdy zmieni się wartość. Dokumentacja, która odbiega od rzeczywistości, jest gorsza niż jej brak.

Trzymaj materiał zaufania wewnątrz każdego klienta

Osobny organ wydający dla każdego klienta ułatwia rozumowanie o granicy i trzyma klucz podpisujący z dala od hosta wystawionego na internet. Wspólny korzeń też może działać, ale wspólna kotwica nie czyni dwóch usług jedną domeną członkostwa. Zdecyduj, jakie łańcuchy akceptuje każdy nasłuch i jakie tożsamości klientów autoryzuje, a następnie zapisz oba. Nie usuwaj certyfikatów z łańcucha metodą prób i błędów, dopóki coś się nie połączy.

Własny klucz prywatny serwera należy do chronionego pliku dla każdego klienta, a nie do katalogu szablonów replikowanego razem z konfiguracją.

Oddziel sieci tak samo jak procesy

Dwa procesy na dwóch portach nadal dzielą host i tablicę routingu, jeśli ich nie rozdzielisz. Potwierdź, co nasłuchuje, zanim zaufasz projektowi.

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

Sprawdzenie nasłuchu pokazuje, który proces posiada każdy port publiczny, a weryfikacja pokazuje, czy certyfikat klienta łączy się z zamierzoną kotwicą. Żadne z tych wyjść nie dowodzi, że klient A nie może dotrzeć do podsieci B, więc zdefiniuj politykę źródła i celu, trasy powrotne oraz każdą celowo współdzieloną usługę. Przestrzenie nazw sieci lub kontenery oddzielają konteksty routingu i zmniejszają przypadkowe mieszanie, ale nie są pełną granicą dzierżawcy same w sobie. Wybierz silniejszy mechanizm izolacji, gdy wymaga tego model zagrożeń.

Dostarcz unieważnienie przed przekazaniem

Wdrożenie certyfikatu nie jest kompletne, dopóki unieważnienie nie ma ścieżki dostarczania. Sprawdź wystawcę i okno ważności CRL jako część wdrożenia.

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

Kontrola CRL raportuje, kiedy lista została wydana i kiedy wygasa, a status usługi potwierdza, że instancja, która ją czyta, działa. Odświeżaj listę zgodnie z harmonogramem polityki wydawania, nawet gdy nic nowego nie unieważniono, ponieważ wygasły CRL może odrzucić każdego klienta. Publikuj kompletny plik, zamiast pozwalać czytelnikom napotkać częściowy zapis, i zweryfikuj podpis przed wdrożeniem. Zapisz, kto odpowiada za wydawanie, eksploatację punktu końcowego i wycofanie, aby wyłączenie klienta A nie zakłóciło B.

Następnie uruchom parę akceptacyjną: dozwolony klient dociera do własnej usługi, a poświadczenie A jest odrzucane przez nasłuch B. To jest granica wyrażona jako test.