Корпоративный VPN Windows 11 сломался после обновления KB5124008: что делать бизнесу

Сентябрьское обновление Windows 11 KB5124008 нарушило работу корпоративного VPN с сертификатной аутентификацией у части компаний. Рассказываем, что известно о проблеме и как обезопасить удалённый доступ, пока Microsoft не выпустила официальное решение.

Как KB5124008 обрушило корпоративный VPN в Windows 11

Сентябрьское накопительное обновление KB5124008 привело к тому, что у части организаций корпоративный VPN на Windows 11 перестал устанавливать соединение. Наиболее болезненно это ударило по Always On VPN с сертификатной аутентификацией — именно такой сценарий удалённого доступа выбирают компании с повышенными требованиями к защите информации. ИТ- и ИБ-специалистам не стоит рассчитывать только на скорый патч от Microsoft: разумнее уже сейчас подготовить альтернативный способ защищённого удалённого доступа на случай, если основной канал откажет без предупреждения.

Обновление вышло в рамках сентябрьского Patch Tuesday и предназначалось главным образом для устранения уязвимостей. Тем не менее у ряда администраторов сразу после установки на клиентских машинах с Windows 11 массово прекратил подниматься VPN-туннель. Проблему описали на форуме поддержки Microsoft (Microsoft Q&A): до появления обновления канал функционировал без сбоев, а сразу после инсталляции патча подключение отказывало целиком.

Какая конфигурация инфраструктуры уязвима

С этой неполадкой сталкиваются не все пользователи Windows 11 — она возникает при конкретном сочетании компонентов инфраструктуры удалённого доступа:

  • на рабочих устройствах сотрудников установлена Windows 11 версии 24H2 либо 25H2;
  • серверная часть построена на Routing and Remote Access Service (RRAS) и Network Policy Server (NPS) под управлением Windows Server 2019;
  • распространение VPN-профиля организовано через Microsoft Intune;
  • аутентификация построена на сертификатах — стандартная схема для IKEv2/IPsec-подключений в формате Always On VPN.

На некоторых из проверенных машин деинсталляция патча вместе с перезагрузкой восстанавливала работу туннеля — это косвенно свидетельствует о том, что причина кроется в самом обновлении, а не в индивидуальных настройках устройства.

ПараметрЗначение
ОбновлениеKB5124008, сентябрьский Patch Tuesday
Затронутые ОСWindows 11 24H2, 25H2
Тип VPNAlways On VPN, сертификатная аутентификация (IKEv2/IPsec)
Серверная инфраструктураRRAS и NPS на Windows Server 2019, профиль через Intune
СимптомПосле установки обновления VPN-туннель перестаёт подниматься
Временное решениеДеинсталляция патча возвращает соединение к работе
Позиция MicrosoftНа момент подготовки материала официально не подтверждена

Чем IKEv2 отличается от SSTP, L2TP/IPsec и OpenVPN в корпоративном VPN

Неполадка, вызванная KB5124008, касается конкретно связки IKEv2/IPsec с сертификатной аутентификацией, однако корпоративный удалённый доступ в Windows 11 этим протоколом не ограничивается. Понимание различий между вариантами помогает не только осознанно выбрать основной протокол при развёртывании VPN, но и быстро найти временную замену, если один из них выйдет из строя из-за похожего обновления.

ПротоколАутентификацияПрохождение через файрволыПоддержка в Windows 11Особенности
IKEv2/IPsecСертификат, EAP, реже — предварительный ключСреднее: использует UDP-порты 500 и 4500, жёсткие файрволы могут его блокироватьВстроен нативноБыстро восстанавливает сессию при переключении сети, из-за чего его чаще всего применяют для Always On VPN на ноутбуках
SSTPЛогин/пароль или сертификатВысокое: работает поверх TCP 443, маскируясь под обычный HTTPS-трафикВстроен нативно (проприетарный протокол Microsoft)Без затруднений проходит через корпоративные и публичные файрволы
L2TP/IPsecПредварительный ключ или сертификатСреднее: задействует UDP 500/1701/4500, также подвержен блокировкамВстроен нативноУступает IKEv2 по скорости из-за двойной инкапсуляции
OpenVPNСертификаты, логин/пароль или их комбинацияВысокое: настраивается на TCP или UDP, легко выдаёт себя за HTTPS-трафикНе встроен, требует стороннего клиентаОткрытое решение, на базе которого нередко создаются сторонние корпоративные VPN-продукты

Применительно к истории с KB5124008 вывод очевиден: при отказе сертификатного IKEv2 компания может временно перевести часть сотрудников на SSTP или, если инфраструктура это поддерживает, на стороннее OpenVPN-решение. Саму причину сбоя такой шаг не устранит, но позволит не останавливать удалённую работу на время расследования.

Техническая версия: из-за чего отказывает сертификатный VPN

Косвенные данные говорят о правках в сетевом стеке либо в логике обработки IPsec-сертификатов: сбой возникает конкретно на этапе согласования сертификата при построении туннеля, а не на других шагах подключения. Такую версию поддерживают независимые консультанты, обсуждавшие инцидент на форуме Microsoft, но точная причина до сих пор не установлена — компания не публиковала технических комментариев и не внесла проблему в перечень известных проблем обновления.

По описанию в теме на форуме Microsoft Q&A, сбой воспроизводится на нескольких устройствах: подключение работало до установки KB5124008, а сразу после инсталляции переставало подниматься.

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

Из чего складывается VPN-подключение в Windows 11 и что подготовить заранее

Перед тем как углубляться в разбор сбоя, полезно понять, из каких элементов состоит корпоративный VPN в Windows 11 и что нужно подготовить до его настройки:

  • адрес корпоративного VPN-сервера и выбранный тип подключения (IKEv2, SSTP либо L2TP/IPsec) — эту информацию нужно запросить в ИТ-отделе;
  • учётные данные для входа — доменные логин с паролем или клиентский сертификат из хранилища сертификатов устройства;
  • действующая сетевая политика на сервере (RRAS, NPS либо схожий компонент), которая разрешает подключение конкретного пользователя или устройства;
  • свежие версии Windows и сетевых драйверов — при этом, как показал пример с KB5124008, крупные накопительные обновления на устройствах с активным корпоративным VPN лучше сначала проверить на тестовой группе.

В большинстве компаний сотруднику не приходится создавать VPN-профиль вручную — он разворачивается централизованно через Intune, групповые политики либо сценарий, запускаемый при первом входе на корпоративный ноутбук. Логика настройки через штатный интерфейс Windows 11 при этом одна и та же — и для ИТ-специалиста, и в ситуациях, когда подключение всё же нужно создать самостоятельно:

  1. Перейти в «Параметры» → «Сеть и Интернет» → «VPN».
  2. Выбрать «Добавить VPN-подключение».
  3. В поле «Поставщик услуг VPN» указать «Windows (встроенный)».
  4. Указать имя подключения, адрес сервера и тип VPN: конкретный протокол (например, IKEv2) либо «Автоматически», если сервер способен согласовать протокол самостоятельно.
  5. Выбрать способ входа — сертификат или пару логин-пароль — и при необходимости сохранить учётные данные.
  6. Сохранить профиль, подключиться и проверить, что соединение устанавливается и корректно распознаёт внутренние сетевые ресурсы.

Для массового развёртывания этот же профиль целесообразнее упаковать в конфигурационный пакет Intune либо раздать через групповые политики — так исчезают ошибки ручного ввода, а параметры можно централизованно изменить сразу на множестве устройств, если этого потребует ситуация, подобная KB5124008.

Патч-менеджмент как дилемма: закрывать уязвимость или сохранять работу VPN

Ситуация осложняется тем, что накопительные обновления вроде KB5124008 обычно закрывают и другие уязвимости, не связанные с VPN-проблемой. Поэтому простой откат патча нельзя назвать безопасным шагом: устройства без обновления могут оставаться уязвимыми для иных атак, а значит, решение требует взвешенного подхода, а не огульного отказа от установки.

Для служб информационной безопасности это классическое противостояние доступности и защищённости. Правильный ответ — не выбор по принципу «ставить или не ставить», а сегментированный график обновления с разными сроками для разных групп устройств.

Что делать бизнесу: чек-лист для ИТ и ИБ-служб

  1. Временно остановить массовую раскатку KB5124008 через WSUS или Intune на устройствах с Always On VPN и сертификатной аутентификацией — до появления официального исправления.
  2. Продолжать обновлять остальные устройства без задержек: поскольку патч закрывает и другие уязвимости, устанавливать его везде, где нет зависимости от такого VPN, а проблемную группу выделить в отдельный график.
  3. Открыть обращение в поддержку Microsoft с логами RasClient и NPS — это ускоряет диагностику и позволяет связать заявку с похожими случаями.
  4. На небольшой пилотной группе устройств протестировать временный перевод VPN-профиля на EAP-TLS, помня, что полной стабильности это не гарантирует.
  5. Держать серверные роли RRAS и NPS обновлёнными, чтобы не добавлять диагностике лишних неизвестных переменных.

Типичные ошибки подключения корпоративного VPN в Windows 11

Конкретный код ошибки, привязанный именно к KB5124008, Microsoft пока не озвучила. Ниже — общесправочная подборка типовых кодов ошибок корпоративного VPN в Windows 11, не привязанная напрямую к этому инциденту, но полезная для инструкции первой линии поддержки:

Код ошибкиТипичная причина
800Общая ошибка установки VPN-соединения, чаще всего вызвана протоколом или блокировкой портов файрволом
809Сетевое соединение между клиентом и сервером VPN не устанавливается — часто из-за блокировки UDP-портов 500/4500, необходимых IKEv2/L2TP
812Подключение отклонено политикой сервера RRAS/NPS
691Ошибка аутентификации: неверные учётные данные, истёкший сертификат или ограничение на учётной записи
628Соединение прервано со стороны сервера — причину нужно искать в журналах RRAS/NPS

Если сотрудники жалуются на подобные коды при сбоях VPN, их стоит прикладывать к обращению в поддержку Microsoft вместе с логами RasClient и NPS — это ускоряет диагностику и облегчает связку заявки с похожими случаями.

Как снизить риски удалённого доступа, пока VPN нестабилен

Инцидент с KB5124008 — хороший повод проверить, не опирается ли вся защита удалённого доступа компании на единственный канал. Даже если VPN временно недоступен или переведён на резервную схему аутентификации, доступ к критичным системам должен оставаться под контролем многофакторной аутентификации — причём не только при подключении к VPN, но и при входе в Windows, через RDG или ADFS. Решения по защите доступа наподобие Контур.Эгида закрывают MFA сразу в нескольких точках входа, поэтому отказ одного канала не оборачивается брешью во всём периметре.

Второй значимый момент связан с привилегированным доступом администраторов: в такой ситуации им требуются расширенные права для откатывания обновлений, ручной правки VPN-профилей в Intune или изменения настроек RRAS и NPS. Именно в моменты экстренных изменений риск ошибки или злоупотребления заметно выше обычного, поэтому контроль привилегированного доступа (PAM) и журналирование таких действий — не формальность, а реальный способ снизить ущерб от подобных инцидентов.

Двухфакторная аутентификация и сертификаты как критерий выбора корпоративного VPN

Сертификатная аутентификация, на которой строится Always On VPN, сама по себе надёжнее пароля: сертификат невозможно подобрать перебором, а похитить его сложнее, чем пару логин-пароль. Тем не менее случай с KB5124008 показывает и обратную сторону такой схемы: любой механизм проверки, от которого зависит весь доступ, подвержен собственным техническим сбоям, а не только попыткам взлома.

При выборе или пересмотре корпоративного VPN-решения многофакторную аутентификацию правильно закладывать не вместо сертификата, а как дополнительный рубеж защиты — при входе в VPN, при последующем входе в Windows, а также при доступе к RDG и через ADFS. Для устойчивости к фишингу лучше подходят методы MFA, не завязанные на СМС-коды: одноразовые пароли в приложении, push-подтверждение или аппаратные токены — последние особенно уместны для учётных записей администраторов, управляющих самой VPN-инфраструктурой.

На что обращать внимание при выборе или доработке корпоративного VPN-решения

  • поддержка всех платформ, которые реально задействуют сотрудники, — Windows, macOS, Linux, а также мобильных iOS и Android для выездных и гибридных сотрудников;
  • встроенная или легко подключаемая многофакторная аутентификация, а не только сертификат либо пароль;
  • возможность быстро переключить пользователей на резервный протокол или сервер при отказе основного канала — по примеру ситуации с KB5124008;
  • достаточный запас по количеству одновременных подключений и, при необходимости, поддержка статических IP-адресов для интеграции с внешними системами;
  • централизованное управление профилями подключения через MDM либо групповые политики вместо самостоятельной настройки каждым сотрудником;
  • журналирование подключений и действий администраторов, обслуживающих VPN-инфраструктуру, — это упрощает расследование инцидентов и подтверждение соответствия требованиям регуляторов;
  • понятный SLA поддержки от поставщика решения и прозрачный порядок эскалации при сбоях, подобных рассмотренному.

Чек-лист для ИТ-отдела перед раскаткой корпоративного VPN на сотрудников

  1. Определить протокол и метод аутентификации с учётом типа устройств и мобильности сотрудников — сертификат, EAP или логин/пароль.
  2. Выпускать и распространять сертификаты через корпоративный удостоверяющий центр или систему управления устройствами (Intune, SCCM), не рассчитывая на ручную установку силами сотрудников.
  3. Активировать многофакторную аутентификацию и при входе в VPN, и при последующем доступе к критичным системам.
  4. Заложить резервный сценарий подключения (запасной протокол либо сервер) на случай отказа основного канала — с учётом истории KB5124008.
  5. Проверять новый или изменённый VPN-профиль на пилотной группе устройств перед массовым развёртыванием, а также перед установкой крупных накопительных обновлений на устройства с активным VPN.
  6. Внести в документацию типовые коды ошибок и алгоритм действий для первой линии поддержки.
  7. Сузить и журналировать круг администраторов с правом менять конфигурацию RRAS, NPS и профили Intune, — это снижает риск ошибок и злоупотреблений в моменты экстренных изменений.

Частые вопросы

Что такое KB5124008 и почему оно ломает VPN?

Это накопительное обновление для Windows 11, вышедшее в рамках сентябрьского Patch Tuesday. На части устройств оно ломает работу Always On VPN с сертификатной аутентификацией — предположительно из-за изменений в обработке IPsec-сертификатов при построении туннеля.

У каких компаний есть риск столкнуться с проблемой?

Риску подвержены организации, где клиентские устройства работают на Windows 11 24H2 или 25H2, применяется Always On VPN с сертификатной аутентификацией, серверная часть развёрнута на RRAS и NPS под Windows Server 2019, а VPN-профиль распространяется через Microsoft Intune.

Стоит ли просто не устанавливать обновление KB5124008?

Полностью отказываться от установки рискованно: накопительные обновления обычно закрывают и другие уязвимости, не только VPN-проблему. Разумнее приостановить обновление лишь на затронутой группе устройств с VPN, а остальные обновить в обычном режиме.

Как быстро восстановить VPN, если обновление уже установлено?

На некоторых устройствах помогало удаление KB5124008 с последующей перезагрузкой — после этого соединение восстанавливалось. Как временную меру можно попробовать перевод профиля на EAP-TLS, хотя стабильную работу это не гарантирует.

Когда Microsoft выпустит официальное исправление?

На момент написания статьи Microsoft не подтвердила проблему официально и не называла сроков её устранения. Компаниям лучше рассчитывать на собственные компенсирующие меры, а не ждать быстрого выхода патча.

Какой протокол VPN лучше выбрать для корпоративного доступа?

Однозначного ответа не существует: IKEv2/IPsec чаще выбирают для мобильных сотрудников из-за быстрого восстановления сессии при смене сети, SSTP — когда важно гарантированно проходить строгие файрволы, а OpenVPN — если требуется гибкость настройки и уже используется сторонний клиент. Многие компании держат основной и резервный протокол одновременно, что и позволило некоторым из них быстро переключиться после сбоя, вызванного KB5124008.

Нужна ли двухфакторная аутентификация, если VPN уже защищён сертификатом?

Да. Сертификат защищает от подбора и кражи пароля, но не спасает от сбоя самого механизма проверки сертификатов или от компрометации устройства в дальнейшем. MFA при входе в VPN и в ключевые системы создаёт независимый рубеж защиты и уменьшает ущерб от ситуаций, подобных рассмотренной.

Можно ли настроить корпоративный VPN вручную через штатные средства Windows 11?

Технически да — через «Параметры» → «Сеть и Интернет» → «VPN» → «Добавить VPN-подключение». Но если в компании работает больше нескольких человек, самостоятельная настройка каждым сотрудником повышает риск ошибок и усложняет массовые изменения — надёжнее централизованно раздать профиль через Intune или групповые политики.

Итог: что важно запомнить бизнесу

История с KB5124008 наглядно демонстрирует: даже штатное обновление безопасности способно временно оставить компанию без основного канала удалённого доступа — и одновременно сохранить открытую уязвимость, если отложить патч без разбора. Правильный ответ — сегментированное обновление, обращение в поддержку с конкретными логами и запасные варианты подключения на переходный период.

Подобные случаи лишний раз напоминают: защита удалённого доступа не должна держаться на одном-единственном компоненте инфраструктуры. Многофакторная аутентификация при входе в VPN, Windows, RDG и ADFS в сочетании с контролем привилегированных действий администраторов снижает ущерб именно в момент, когда один из технических каналов временно отказывает.

Оставьте заявку на подключение

Менеджер свяжется с вами и поможет с выбором сервисов и услуг