IKEv1 z XAuth i OTP: o co pyta każdy monit

IKEv1 z PSK, XAuth i OTP nie prosi o jedno skomplikowane hasło. Nakłada na siebie współdzielony klucz między peerami, wymianę użytkownika i drugi składnik, którego sposób żądania ustala backend. Każda warstwa ma swojego właściciela i własny komunikat o błędzie. Mylenie ich sprawia, że ludzie wpisują ponownie kod jednorazowy w pole, które przechowuje sekret grupy.

Dopasuj każdy monit do warstwy, która go żąda, zanim zainstalujesz innego klienta lub zresetujesz poświadczenie.

Trzy sekrety, trzej właściciele

Współdzielony klucz należy do relacji między peerami i jest konfigurowany raz przez osobę zarządzającą oboma końcami. Poświadczenie użytkownika należy do backendu uwierzytelniania i jest weryfikowane przy każdym logowaniu. Drugi składnik należy do systemu tokenów, którego odpowiedź zmienia się przy każdej próbie. Żaden nie zastępuje innego, a wdrożenie, które traktuje je jako jedno hasło, zawodzi na warstwie, której nikt nie udokumentował.

Zapisz trzy kolumny: właściciel, czas życia i komunikat o błędzie, który każdy z nich generuje. Diagnostyką jest ta tabela, a nie nazwy pól w kliencie.

PSK: peera, nie osoby

W tym starym układzie współdzielony klucz uwierzytelnia parę bram, więc logowanie użytkownika nigdy go nie zastępuje. Jest to też wartość najczęściej błędna w sposób, który daje ogólny błąd negocjacji zamiast monitu. Gdy tunel zawodzi, zanim pojawi się jakikolwiek monit użytkownika, podejrzanymi są klucz lub propozycje.

Poświadczenie użytkownika nie naprawi błędu pierwszej fazy. Rotacja marnuje jedyne poświadczenie, które możesz bezpiecznie rotować, i utrwala błędną teorię.

XAuth: stara wymiana użytkownika

XAuth dodaje wymianę uwierzytelniania użytkownika na wierzchu uwierzytelniania peera w IKEv1, a brama decyduje, który backend ją weryfikuje. W zależności od tego backendu wymiana może przyjąć hasło katalogowe, poświadczenie RADIUS lub odpowiedź tokenu. Słowo XAuth nazywa transport wymiany, a nie typ poświadczenia.

Sprawdź, na który backend wskazuje profil bramy. To mówi, o co zostanie poproszony użytkownik i co naprawdę zmienia reset hasła, a żadnej z tych rzeczy nie widać w profilu klienta.

OTP: cokolwiek zażąda backend

Niektóre wdrożenia proszą o osobny kod jednorazowy po haśle, a inne definiują połączony format wejściowy z udokumentowanym separatorem. Oba istnieją, a profil przed tobą decyduje który. Wymyślanie konkatenacji, bo zadziałała w innym miejscu, to najczęstszy sposób spalenia tokenu rejestracyjnego. Rozstrzyga to wyłącznie dokumentacja samej bramy.

Użyj udokumentowanego formatu z klientem, który potrafi dokończyć wymianę oferowaną przez bramę.

Gdzie gryzie granica klienta

Fortinet dokumentuje, że FortiClient 7.4.4 i późniejsze nie obsługują już IKEv1 dla sieci VPN IPsec, co jest granicą produktu i wersji, a nie powszechnym usunięciem, jak odnotowuje nota o zgodności FortiClient. Inne klienty też nie są wymienne: OpenConnect i openfortivpn mówią określonymi protokołami bram, a nie dowolnymi profilami IKEv1. Sprawdź osobno wersję IKE, tryb PSK, obsługę XAuth i model interakcji zainstalowanego klienta. Klient łączący się inną metodą nie dowiódł pierwotnego wymagania.

IKEv1 jest przestarzały, więc nowe wdrożenie zbudowane na nieobsługiwanym starym kliencie to krótkotrwałe rozwiązanie. Poproś właściciela bramy o obsługiwaną ścieżkę migracji, w tym o to, jak będzie tam obsługiwany drugi składnik.

Diagnozowanie bez wyłączania składnika

Rozdziel etapy w logu: negocjacja peerów, wymiana użytkownika, wynik drugiego składnika, potem przydział adresu i trasy. Zapisuj komponent i etap zamiast próbować kodu w każdym polu. Wyłączenie składnika, żeby test przeszedł, daje tunel, który nic nie dowodzi o wdrożeniu.

Trzymaj sekrety rejestracji i współdzielony klucz w chronionym magazynie zgodnie z procesem organizacji. Kod jednorazowy w trwałym pliku to składnik, który przestał być składnikiem.