Чаму ўбудаваны 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, сумленныя варыянты — зацверджаны кліент, які яго падтрымлівае, або змена дызайну аўтэнтыфікацыі шлюза. Ні тое ні іншае не з’яўляецца лакальным абыходам, і адваротнае ўражанне стварае злучэнне, якое здольны аднавіць толькі той, хто яго настроіў.

Запішыце рашэнне і сакрэты

Запішыце абраны метад, давераную аснову, ідэнтычнасць, якая з ім суадносіцца, і чалавека, які зацвердзіў змену. Гэты запіс — тое, што патрэбна разбору інцыдэнту, і ён жа не дазваляе наступнаму інжынеру зноў прайсці той самы тупік.

Трымайце сакрэты асобна ў нататках: пароль уліковага запісу, парольная фраза прыватнага ключа і папярэдне агульны ключ шлюза — гэта тры розныя рэчы, нават калі экран налад называе ўсё гэта паролем. Блытаніна паміж імі — гэта шлях, якім ключ трапляе ў заяўку. Праверце атрыманы профіль свежым злучэннем і адным запытам прыкладання да прыватнага рэсурсу. Паспяховы тунэль без дасяжнай службы — частковы вынік, і профіль нельга называць завершаным, пакуль рэсурс таксама не запрацуе.