Чому штатний Windows IKEv2 взагалі не має поля PSK

Документація шлюзу каже, що заздалегідь спільний ключ вводиться в клієнті, але в профілі Windows для нього немає поля. Ця прогалина не помилка, яку обходять, вписуючи ключ у поле пароля. Це різниця між тим, що може протокол, і тим, що пропонує конкретна реалізація.

Можливість протоколу не означає підтримку клієнта

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

Люди зазвичай потрапляють на довідка PowerShell щодо додавання підключення VPN, де для схеми L2TP показано L2tpPsk. Цей параметр належить 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, чесні варіанти — схвалений клієнт, який його підтримує, або зміна дизайну автентифікації шлюзу. Ні те ні інше не є локальним обходом, а зворотне твердження створює з’єднання, яке може відтворити лише той, хто його налаштував.

Запишіть рішення та секрети

Запишіть вибраний метод, довірений якір, відповідне посвідчення та людину, яка затвердила зміну. Цей запис — те, що потрібно розбору інциденту, і він же заважає наступному інженеру знову пройти той самий глухий кут.

Тримайте секрети окремо у своїх нотатках: пароль облікового запису, парольна фраза закритого ключа й заздалегідь спільний ключ шлюзу — три різні речі, навіть коли екран налаштувань називає все це паролем. Їхнє плутання — це шлях, яким ключ потрапляє до заявки. Перевірте отриманий профіль свіжим підключенням і одним запитом застосунку до приватного ресурсу. Успішний тунель без доступної служби — частковий результат, і профіль не можна описувати як готовий, доки ресурс теж не працює.