Jak uwierzytelnianie hybrydowe IKEv1 przekłada się na uwierzytelnianie użytkowników w IKEv2
Tryb hybrydowy oddzielał dowód bramy od dowodu użytkownika. Przejście na IKEv2 zachowuje ten podział, ale zmienia wymianę, metodę EAP i kontrole certyfikatu.
Każdy stary profil VPN, który najpierw prosi o certyfikat serwera, a potem o nazwę użytkownika, niesie dwa zdarzenia uwierzytelniania w jednej wymianie, i ten kształt przeżywa protokół, który go wprowadził. Tryb hybrydowy IKEv1 powstał dokładnie po to: brama dowodzi siebie kluczem publicznym, a użytkownik dowodzi siebie później przez XAuth. IKEv2 wyraża ten sam pomysł dwuetapowy inną mechaniką, i właśnie w tych różnicach migracje zawodzą. Żaden numer wersji nie zamienia jednego w drugie, a skopiowanie starych nazw opcji do nowego profilu daje klienta, który wynegocjuje i potem niczego nie uwierzytelni.
Co tryb hybrydowy robił wewnątrz IKEv1
W profilu hybrydowym odpowiadający podpisuje wymianę pierwszej fazy swoim certyfikatem, podczas gdy inicjator celowo nie przedstawia żadnego. Dowód tożsamości jest więc asymetryczny, i to pozwoliło bramie zachować istniejące PKI, a użytkownikom ich hasła katalogowe. Gdy pierwsza faza się kończy, XAuth działa jako żądanie i odpowiedź, które niosą atrybuty nazwy użytkownika i hasła w już zaszyfrowanym kanale ISAKMP.
Zwróć uwagę, gdzie ląduje zaufanie. Certyfikat odpowiada, do której bramy dotarł klient; XAuth odpowiada, który użytkownik chce dostępu. Żaden nie zastępuje drugiego, a klient skonfigurowany do akceptowania dowolnego certyfikatu serwera po cichu odrzucił pierwszą odpowiedź. Etykieta hybrydowy bywa też używana dla trybu agresywnego z kluczem współdzielonym plus XAuth, innego układu o tej samej jakości obsługi, więc czytaj profil, a nie nazwę. Oba warianty wywodzą się z projektów, które nigdy nie stały się standardami, i dlatego dwóch producentów może wdrożyć tryb hybrydowy i nie współdziałać z nikim.
Jak IKEv2 dochodzi do tych samych dwóch dowodów
IKEv2 dzieli pracę między IKE_SA_INIT i IKE_AUTH. Pierwsza wymiana uzgadnia propozycje i klucze całkowicie bez tożsamości; druga niesie IDi, IDr i ładunki AUTH. W EAP pierwszy ładunek AUTH inicjatora wychodzi pusty, odpowiadający uwierzytelnia się najpierw certyfikatem i podpisem, a potem rozmowa EAP toczy się w komunikatach IKE_AUTH.
Mechanizmem, który to zabezpiecza, jest materiał kluczowy. Udana metoda EAP eksportuje klucz sesji, a końcowy ładunek AUTH inicjatora jest z niego obliczany, więc dowód użytkownika i klucze tunelu są ze sobą związane. XAuth nie ma odpowiednika: jego atrybuty przychodzą po pierwszej fazie i nic nie wnoszą do kluczy. Właśnie tę lukę miał zamknąć szkielet IKEv2, i dlatego działające logowanie IKEv2 sprawdza certyfikat serwera, zanim o cokolwiek poprosi.
Ta kolejność jest też pożyteczną diagnostyką. Gdy klient narzeka na dane logowania, zanim pokazał ci certyfikat, wcale nie wykonuje wymiany EAP w IKEv2.
Utrzymuj trzy tożsamości osobno
Migracja idzie źle, gdy trzy tożsamości zapadają się w jedno pole. Jest tożsamość bramy, którą weryfikuje klient, zwykle nazwa DNS w subject lub SAN certyfikatu. Jest tożsamość użytkownika przedstawiana w EAP, być może login domenowy, adres albo jawny łańcuch tożsamości EAP. I jest źródło autoryzacji, które przypisuje tego użytkownika do sieci i tras.
Składnia swanctl w strongSwan pokazuje podział: połączenie ustawia remote { auth = pubkey } dla bramy i local { auth = eap-mschapv2 } dla użytkownika, a tożsamość EAP jest przenoszona osobno.
Gdy tożsamość użytkownika w nowym profilu różni się od starych atrybutów XAuth, na przykład UPN zamiast krótkiej nazwy, serwer uwierzytelniania widzi nieznanego użytkownika, a awaria wygląda jak błędne hasło. Sprawdź łańcuch tożsamości, zanim sprawdzisz dane logowania.
Zmapuj opcje, a potem spodziewaj się pułapek
Mapowanie jest krótkie, a każdy wiersz ma pułapkę, która ujawnia się dopiero przy uwierzytelnianiu.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
Żaden z tych wierszy nie jest zwykłym przemianowaniem. Ładunek konfiguracji dostarcza adresy i resolvery przez typowaną listę atrybutów, podczas gdy przestrzeń atrybutów XAuth była własnym wynalazkiem; traktowanie ich jako wymiennych prowadzi do tego, że profil prosi o ustawienie, którego brama nigdy nie wyśle.
Selektory ruchu zasługują na własne ostrzeżenie. IKEv1 wyrażał interesujący ruch przez identyfikatory proxy powiązane z wymianą quick mode, podczas gdy IKEv2 negocjuje selektory podczas IKE_AUTH i odpowiadający może je zawęzić. Niezgodność daje ustanowione IKE SA bez child SA, które niektórzy klienci ochoczo pokazują jako połączone.
Traktuj stare połączenie jako granicę
RFC 9395 uznaje IKEv1 za przestarzały, więc stare połączenie hybrydowe jest granicą zgodności z datą, a nie fundamentem. Uruchom oba profile równolegle podczas zmiany, bo test, który się liczy, to nie to, czy nowy profil wstaje, ale czy ten sam użytkownik na tym samym urządzeniu dociera do tych samych zasobów.
Utrzymuj ścisłą walidację certyfikatów przez cały czas. Gdy klient przestaje przedstawiać własny certyfikat, pokusa jest złagodzenie kontroli serwera, aż uścisk dłoni przejdzie, a to wymienia jedyny pozostały dowód na zieloną ikonę.
Zapisz cztery rzeczy, zanim wycofasz stary profil: metodę EAP, łańcuch tożsamości, źródło autoryzacji i datę zakończenia wsparcia.