Защо вграденият Windows IKEv2 няма поле за PSK

Документацията на шлюза казва, че предварително споделеният ключ се въвежда в клиента, а профилът в Windows няма поле за него. Тази липса не е дефект, който да се заобикаля, като се напише ключът в полето за парола. Това е разликата между това, което протоколът може, и това, което предлага конкретна реализация.

Възможността на протокола не е поддръжка от клиента

Спецификацията на IKEv2 включва удостоверяване със споделен ключ, така че шлюзът може законно да бъде конфигуриран за него. Вграденият профил за отдалечен достъп в Windows документира вместо това схеми със сертификати и EAP, а възможността на протокола не създава поле, параметър или стойност в регистъра, които клиентът никога не е имал.

Обикновено хората стигат до Справка на PowerShell за добавяне на VPN връзка, където е показан L2tpPsk за схемата L2TP. Този параметър принадлежи на L2TP и не е общ секрет на IKEv2. Настройките за избор на алгоритъм избират параметри за защита, което е трето, несвързано нещо. Ролята за маршрутизация на Windows Server също не е същият обект. Сървърният интерфейс може да има контроли, каквито профилът на настолен клиент няма, и копирането на сървърна настройка в профил на работна станция не възпроизвежда възможността.

Избор между сертификат, EAP или L2TP

Ако операторът на шлюза приеме удостоверяване със сертификат, това обикновено е най-чистата цел: клиентът представя сертификат, шлюзът го проверява срещу доверен издател и в профила не остава споделена тайна, която някой да копира. Това изисква регистрация, доверена верига и конфигурация на шлюза, която свързва сертификата с решение за разрешение.

EAP с потребителско удостоверение е другият поддържан път в този клиент и премества решението към доставчик на идентичност. Той също въвежда свои зависимости, защото методът EAP, сертификатът на сървъра и доверието на клиента в този сертификат трябва да съвпадат. Преминаването към L2TP/IPsec само за да се получи познато поле променя стека от протоколи. Това е приемливо, когато е поддържан избор с документирана причина, и е лош резултат, когато се случва, защото някой е търсил поле, в което да въведе ключ.

Проверете какво ще приеме шлюзът

Попитайте оператора кои методи за удостоверяване предлага услугата за отдалечен достъп днес, а не кои продуктът поддържа по принцип. Услуга, конфигурирана за IKEv2 само с PSK, няма да приеме сертификат, защото клиентът предпочита такъв.

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

Прочетете метода за удостоверяване на профила и хранилището за сертификати заедно. Профил, настроен на EAP без използваем сертификат зад него, се проваля по начин, който изглежда като проблем на сървъра.

Ако отговорът е, че е наличен само PSK, честните варианти са одобрен клиент, който го поддържа, или промяна в дизайна на удостоверяването на шлюза. Нито едно от двете не е местно заобикаляне и претендирането за обратното създава връзка, която само човекът, който я е настроил, може да възпроизведе.

Запишете решението и тайните

Запишете избрания метод, доверената котва, идентичността, свързана с него, и човека, одобрил промяната. Този запис е това, което е нужно на прегледа на инцидент, и той също спира следващия инженер да преоткрие същата задънена улица.

Дръжте тайните отделно в бележките си: парола за акаунт, парола за частен ключ и предварително споделен ключ на шлюз са три различни неща, дори когато екран за настройки обозначава всички като парола. Объркването им е начинът, по който ключ попада в тикет. Тествайте получения профил със свежа връзка и една заявка от приложение към частен ресурс. Успешен тунел без достъпна услуга е частичен резултат и профилът не бива да се описва като завършен, докато ресурсът също не работи.