Зошто вградениот 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, искрените опции се одобрен клиент што го поддржува или промена во дизајнот на автентикација на порталот. Ниту едно не е локално заобиколување, а тврдењето спротивно создава врска што само лицето што ја конфигурирало може да ја репродуцира.

Запишете ја одлуката и тајните

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

Држете ги тајните одвоени во забелешките: лозинка на сметка, тајна фраза на приватен клуч и претходно споделен клуч на порталот се три различни работи, дури и кога екранот за поставки ги нарекува сите лозинка. Нивното мешање е начинот на кој клучот завршува во барањето. Тестирајте го добиениот профил со свежа врска и едно барање од апликација до приватен ресурс. Успешен тунел без достапна служба е делумен резултат, и профилот не треба да се опишува како завршен додека и ресурсот не работи.