Dlaczego natywny Windows IKEv2 w ogóle nie ma pola PSK

Dokumentacja bramy mówi, że wstępnie współdzielony klucz wpisuje się w kliencie, ale profil Windows nie ma na to pola. Ta luka nie jest błędem, który omija się, wpisując klucz w pole hasła. To różnica między tym, co potrafi protokół, a tym, co oferuje konkretna implementacja.

Możliwość protokołu to nie wsparcie klienta

Specyfikacja IKEv2 obejmuje uwierzytelnianie kluczem współdzielonym, więc bramę można zgodnie z prawem tak skonfigurować. Natywny profil dostępu zdalnego Windows dokumentuje natomiast rozwiązania z certyfikatami i EAP, a możliwość protokołu nie tworzy pola, parametru ani wartości rejestru, którego klient nigdy nie miał.

Ludzie zwykle trafiają na odwołanie PowerShell do dodawania połączenia VPN, gdzie pokazano L2tpPsk dla rozwiązania L2TP. Ten parametr należy do L2TP i nie jest ogólnym sekretem IKEv2. Ustawienia wyboru algorytmów wybierają parametry ochrony, co jest trzecią, niezwiązaną sprawą. Rola routingu w Windows Server też nie jest tym samym obiektem. Interfejs serwera może mieć kontrolki konfiguracji, których profil klienta stacjonarnego nie ma, a skopiowanie ustawienia serwera do profilu stacji roboczej nie odtwarza tej możliwości.

Wybierz certyfikat, EAP albo L2TP

Jeśli operator bramy zaakceptuje uwierzytelnianie certyfikatem, to zwykle najczystszy cel: klient przedstawia certyfikat, brama weryfikuje go u zaufanego wystawcy i w profilu nie zostaje współdzielony sekret, który ktoś mógłby skopiować. Wymaga to rejestracji, zaufanego łańcucha i konfiguracji bramy, która wiąże certyfikat z decyzją autoryzacyjną.

EAP z poświadczeniem użytkownika to druga obsługiwana droga w tym kliencie i przenosi decyzję do dostawcy tożsamości. Wnosi też własne zależności, bo metoda EAP, certyfikat serwera i zaufanie klienta do tego certyfikatu muszą się zgadzać. Przejście na L2TP/IPsec tylko po to, by dostać znane pole, zmienia stos protokołów. To jest do przyjęcia, gdy jest obsługiwanym wyborem z udokumentowanym powodem, a złym wynikiem, gdy dzieje się, bo ktoś szukał pola do wpisania klucza.

Sprawdź, co przyjmie brama

Zapytaj operatora, jakie metody uwierzytelniania usługa dostępu zdalnego oferuje dzisiaj, a nie jakie produkt obsługuje ogólnie. Usługa skonfigurowana do IKEv2 tylko z PSK nie przyjmie certyfikatu dlatego, że klient go woli.

Get-VpnConnection -Name "Corp IKEv2" | Format-List AuthenticationMethod, TunnelType, EncryptionLevel, ServerValidation
Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, NotAfter

Czytaj metodę uwierzytelniania profilu i magazyn certyfikatów razem. Profil ustawiony na EAP bez użytecznego certyfikatu za nim zawodzi w sposób, który wygląda jak problem serwera.

Jeśli odpowiedź brzmi, że dostępny jest tylko PSK, uczciwe opcje to zatwierdzony klient, który go obsługuje, albo zmiana projektu uwierzytelniania bramy. Żadna nie jest lokalnym obejściem, a udawanie czegoś przeciwnego daje połączenie, które odtworzyć może tylko ten, kto je skonfigurował.

Zapisz decyzję i sekrety

Zapisz wybraną metodę, kotwicę zaufania, pasującą do niej tożsamość i osobę, która zatwierdziła zmianę. Ten zapis jest tym, czego potrzebuje przegląd incydentu, i to on powstrzymuje następnego inżyniera przed ponownym odkryciem tego samego ślepego zaułka.

Trzymaj sekrety osobno w notatkach: hasło konta, fraza hasłowa klucza prywatnego i wstępnie współdzielony klucz bramy to trzy różne rzeczy, nawet gdy ekran ustawień nazywa je wszystkie hasłem. Mylenie ich to sposób, w jaki klucz trafia do zgłoszenia. Przetestuj wynikowy profil nowym połączeniem i jednym żądaniem aplikacji do prywatnego zasobu. Udany tunel bez osiągalnej usługi to wynik częściowy, a profilu nie należy opisywać jako gotowego, dopóki zasób też nie działa.