К обсуждениям

Windows ICS включён после перезагрузки, но Wintun не передаёт трафик: четыре состояния

Редакция VOne Технологии

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

Флажок интерфейса не равен рабочему пути

После перезагрузки сначала зафиксируйте четыре независимых состояния: существует ли нужный Wintun-адаптер, назначены ли прежние public и private роли ICS, активна ли служба общего доступа и получил ли клиент ожидаемые адрес, шлюз и DNS. Не переключайте флажок до снимка — именно расхождение между интерфейсом и фактическим трафиком является полезным доказательством. Если устройство управляется организацией, не меняйте общий доступ самостоятельно. Не публикуйте имена адаптеров, адреса и таблицы маршрутов целиком.

Сверьте идентичность Wintun-адаптера

Wintun является layer-3 TUN-драйвером, а официальный проект указывает, что приложения создают адаптеры и могут задавать GUID для устойчивого распознавания Windows. Поэтому одинаковое отображаемое имя после перезапуска не гарантирует ту же идентичность. Сравните описание, индекс и другие безопасные признаки до и после перезагрузки. Если приложение создало новую запись, сохранённая привязка ICS могла относиться к прежней. Это гипотеза для проверки по состояниям, а не основание вручную править GUID или переустанавливать драйвер.

Проверьте обе стороны общего доступа

Старая официальная документация ICS описывает одну public connection и как минимум одну private connection, через которую клиенты получают общий доступ с NAT и маршрутизацией. Сопоставьте фактический входящий интерфейс с публичной ролью, а интерфейс клиента — с частной. Затем на одном тестовом клиенте отдельно проверьте получение адреса, доступ к шлюзу и только потом внешний запрос. Если не работает уже первый шаг, внешняя сеть не является первичной областью. Не меняйте одновременно роли ICS, адреса клиента и Wintun-профиль.

Почему старый registry workaround опасен

Microsoft публикует рекомендацию EnableRebootPersistConnection для конкретной проблемы Windows 10 версии 1709 после определённого обновления и прямо предупреждает о рисках неправильного изменения реестра. Эта область не делает ключ универсальным исправлением современных Windows. Сначала сопоставьте версию и симптомы с официальной статьёй. Если они не совпадают, не создавайте значение реестра по аналогии. Даже при совпадении сделайте резервную копию и следуйте процедуре владельца устройства; в нашем безопасном тесте реестр не меняется.

Обратимый эксперимент и эскалация

После снимка можно один раз выключить и включить общий доступ через штатный интерфейс и повторить те же четыре проверки. Если путь восстановился, зафиксируйте только изменение состояния, не объявляя найденную причину. Для эскалации подготовьте версию Windows, версию приложения с Wintun, признаки идентичности адаптера, public/private роли до и после перезагрузки, состояние клиента и результат штатного переключения. Остановитесь до реестра, удаления адаптеров или сброса сетевого стека: эти действия стирают различия и затрагивают несвязанные соединения.

Материал подготовлен редакцией с помощью ИИ и проверен по документации Microsoft и Wintun; публичный вопрос использован только как обезличенный сигнал, без копирования конфигурации.

Источники и проверка

Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.

Ответы

0 опубликовано
Ответов пока нет. Вы можете начать обсуждение.

Ваш ответ

Добавьте свой опыт или уточнение по теме.

Вы публикуете как Аноним Аватар отличает разговоры, но не раскрывает личные данные.

Ответ появится сразу. Не публикуйте личные данные, ключи и приватные ссылки.