Zaplanuj ustawienia IKEv2 pasujące do więcej niż jednego klienta

Działający profil na jednym pulpicie jest udanym testem jednego klienta. To nie jest wdrożenie międzyplatformowe, a traktowanie go jak takie tworzy znany wzorzec wsparcia: Windows się łączy, telefon zawodzi na sprawdzaniu tożsamości, a zarządzany laptop łączy się ponownie po każdym wybudzeniu. Różnice są realne i w większości przewidywalne, dlatego plan powinien być macierzą, a nie zrzutem ekranu.

Najpierw ustal umowę tożsamości

Przed rozmową o algorytmach udokumentuj tożsamość serwera, zaufanie do certyfikatu i metodę uwierzytelniania klienta. Te trzy decydują, czy klient w ogóle może się uwierzytelnić, i właśnie je platformy wyrażają różnie.

Sprawdź, jak każda platforma nazywa oczekiwany identyfikator i jak obsługuje alternatywne nazwy podmiotu. Profil, który akceptuje nazwę serwera na jednym kliencie, może odrzucić ten sam certyfikat na innym, ponieważ pole identyfikatora jest wypełniane inną wartością.

Następnie wybierz przekrój kryptograficzny

Porównaj propozycje, które może zaproponować każdy obsługiwany klient, i wybierz nowoczesny przekrój, który dopuszcza także brama. Nie włączaj ogromnej starej listy, aby połączyło się jedno stare urządzenie, bo ta lista staje się domyślnym ustawieniem bramy dla wszystkich następnych. Zapisz, dlaczego każda stara opcja wciąż tam jest. Jeśli nikt nie potrafi nazwać urządzenia, które jej potrzebuje, to nie jest wymaganie.

W planie trzymaj ustawienia IKE i CHILD osobno. Propozycja dopuszczalna dla wymiany IKE nie jest automatycznie dopuszczalna dla ruchu chronionego, a oba są negocjowane osobno. Brama, która akceptuje propozycję w jednej warstwie, może ją nadal odrzucić w drugiej, a dziennik pokaże błąd wyglądający tak, jakby pierwsza warstwa się powiodła.

Dostarczaj dane uwierzytelniające sprawdzonym procesem i trzymaj hasło użytkownika, wspólny sekret oraz prywatny klucz klienta w ich własnych polach. Próby i błędy na podobnie nazwanych skrzynkach to droga, którą działający test staje się niepowtarzalny.

Testuj cykl życia, nie stan stabilny

Dla każdego klienta przetestuj początkowe uwierzytelnienie, zamierzoną aplikację, rozwiązywanie DNS i pokrycie rodzin adresów. Następnie przećwicz części, które pojawiają się dopiero później: odnowienie, uśpienie i zwykłą zmianę sieci.

Obsługa MOBIKE i zachowanie przy ponownym uwierzytelnianiu mogą różnić się od właśnie zmierzonego stabilnego wyniku. Zapisz zdarzenie i stan asocjacji w tym momencie, a nie tylko to, czy interfejs w końcu wygląda na połączony.

Zdefiniuj, co może robić ruch bezpośredni, gdy VPN jest niedostępny. To decyzja polityki niezależna od tego, czy klient połączy się ponownie, i większość wdrożeń odpowiada na drugie pytanie, ignorując pierwsze. Zapisz odpowiedź w notatkach wdrożeniowych obok nazw profili. Ktoś będzie jej potrzebował podczas awarii i nie będzie miał czasu jej odtworzyć.

Używaj kontroli tożsamości serwera, gdy jedna platforma się nie zgadza

Gdy profil działa na jednej platformie, a inna odrzuca jego nazwę, porównaj identyfikator faktycznie wysłany przez klienta z identyfikatorami zawartymi w certyfikacie. To porównanie rozwiązuje większość takich przypadków szybciej niż zmiana list szyfrów.

Przechowuj przetestowaną macierz razem ze źródłem konfiguracji i procedurą aktualizacji. Gdy wsparcie dla starego klienta się kończy, celowo usuń jego wyjątek, zamiast zostawiać słabsze ustawienia zgodności ukryte w bramie do znalezienia przez następny audyt. Dokumentacja strongSwan dotycząca IKEv2 to przydatne źródło o tym, jak konfiguruje się wymiany.