IKEv2 adres serwera a tożsamość: co faktycznie sprawdza klient
Adres wskazuje, gdzie zadzwonić; tożsamość mówi, którego partnera zaakceptować. Pomieszanie ich powoduje uszkodzenie przeniesionej bramy lub nowego certyfikatu IKEv2.
Brama, która zmienia adres, może nadal działać, podczas gdy ta sama brama za nowym certyfikatem przestaje działać i dzieje się również na odwrót. Adres informuje klienta, dokąd wysłać pakiety; uwierzytelniona tożsamość informuje klienta, czy partner odpowiadający jest tym, któremu powinien zaufać. IKEv2 zachowuje je jako dwa oddzielne pola, co jest przydatne, gdy przestaniesz traktować je jako jeden ciąg. Są one również skonfigurowane w różnych miejscach, więc jeden może mieć rację, a drugi się mylić.
Sprawdź je w tej kolejności i zatrzymaj się przy pierwszej niezgodności, ponieważ późniejsze kontrole zakładają, że wcześniejsze zostały zaliczone.
Po pierwsze, która wartość jest adresem
Adresem połączenia jest dowolny numer wybierany przez klienta: adres IP, nazwa DNS, która jest rozpoznawana jako jeden, lub interfejs z równoważeniem obciążenia. To jest informacja transportowa i nic więcej. Tożsamość znajduje się w ładunku identyfikacyjnym IKEv2 ID, a następnie jest porównywana z certyfikatem partnera. Nazwa DNS w polu adresowym nie staje się oczekiwaną tożsamością, a surowy adres IP nie staje się tożsamością tylko dlatego, że jest do niej podłączone gniazdo.
W terminologii strongSwan adres to right lub left, a oczekiwana tożsamość to rightid lub leftid i to właśnie opisuje dokumentacja konfiguracyjna IKEv2. Jeśli kiedykolwiek edytowałeś tylko adres, skonfigurowałeś połowę pary.
Po drugie, co może udowodnić certyfikat
Tożsamość ma typ, a certyfikat musi nosić pasującą nazwę. Tożsamość DNS jest potwierdzana przez wpis dNSName w rozszerzeniu alternatywnej nazwy podmiotu; tożsamość IP wymaga wpisu iPAddress. Certyfikat wydany dla vpn.example.com nie dowodzi niczego na temat adresu dosłownego 203.0.113.10, a certyfikat wystawiony na ten adres nie dowodzi niczego na temat nazwy. Ponowne wydanie na inną nazwę nie jest zatem wymianą natychmiastową, nawet w przypadku ponownego użycia tego samego klucza i CA.
Współcześni klienci ignorują nazwę zwyczajową, gdy istnieje alternatywna nazwa podmiotu, a wielu ignoruje ją całkowicie. Jeśli lista SAN nie zawiera wartości sprawdzanej przez klienta, uzgadnianie nie powiedzie się po tym, jak certyfikat został już zaakceptowany jako godny zaufania, dlatego dziennik odczytuje się jako błąd tożsamości, a nie błąd zaufania.
Po trzecie, sposób, w jaki każdy klient określa oczekiwania
Windows pobiera wpisaną nazwę serwera lub adres i wymaga pasującego certyfikatu, więc wpisanie adresu IP powoduje oczekiwanie na adres IP. Klient Android IKEv2 zachowuje się w ten sam sposób i oba odrzucają ważny, publicznie zaufany certyfikat, który zawiera nazwę innego hosta. Profil może zacząć zawodzić tylko dlatego, że podczas migracji ktoś zastąpił nazwę hosta jego adresem. Zanim sprawdzisz, co zawiera certyfikat, sprawdź, o co prosił klient.
W przypadku strongSwan oczekiwanie jest wyraźne: ustaw rightid na tożsamość faktycznie prezentowaną przez serwer, która może różnić się od prawej. Ustawienie go na %any akceptuje wszystko, co oferuje partner, i usuwa dokładnie czek, który próbujesz zachować.
Po czwarte, oddziel logowanie użytkownika od tożsamości równorzędnej
Uwierzytelnianie EAP i tożsamość serwera odpowiadają na różne pytania. Tożsamość EAP, taka jak [email protected] mówi, kim jest użytkownik, po tym jak klient zdecydował, że serwer jest właściwy. Zmiana tego hasła nie może naprawić niezgodności tożsamości równorzędnej, ponieważ połączenie nigdy nie osiąga etapu logowania użytkownika.
Oczyszczony raport powinien zawierać zarówno tożsamość, jakiej oczekiwał klient, tożsamość przedstawioną przez serwer, jak i wpisy SAN certyfikatu.
Po piąte, zmień to poprzez zweryfikowany kanał
Gdy brama zostanie prawidłowo przeniesiona, najpierw zaktualizuj adres i zostaw tożsamość w spokoju, ponieważ w takim przypadku IKEv2 radzi sobie dobrze. Gdy zmieni się sama tożsamość, potraktuj ją jako zdarzenie zaufania i uzyskaj nową wartość ze źródła, któremu już ufasz, a nie z punktu końcowego, który obecnie ulega awarii. Wiadomość dostarczona za pośrednictwem połączenia, które próbujesz sprawdzić, nie stanowi dowodu na istnienie tego połączenia.
Zapisz razem ostateczny adres, tożsamość i listę SAN w notatkach profilowych. Następna osoba, która dotknie certyfikatu, zobaczy, która z tej trójki może się poruszyć.