Сброс сети в Windows удаляет больше, чем неполадку VPN
Сброс очищает адаптеры, маршруты и фильтры WFP, а не только неисправный туннель. Сначала сохраните профиль, список сертификатов и доказательства, затем проверяйте по уровням.
Совет приходит в течение десяти минут после любой жалобы на VPN в Windows: запусти сброс сети, он всё исправит. Не исправит, и он не узкий. Эта кнопка очищает адаптеры, заново связывает протоколы, удаляет статические адреса и маршруты по умолчанию, выбрасывает записи брандмауэра и фильтров и вдобавок забывает профили Wi-Fi. На машине с работающим, но неверно настроенным туннелем он превращает одну диагностируемую неполадку в недокументированную пересборку. Сохраните сначала пять вещей, и вы сохраните возможность это отменить.
Сброс не ограничен профилем VPN
Подключение VPN — один объект среди многих, которые делят сетевой стек. Удаление и повторное добавление адаптера меняет индекс интерфейса, и всё, что ссылалось на этот индекс, от маршрута до правила брандмауэра и до драйвера стороннего фильтра, теперь ссылается на то, чего больше нет.
Виртуализация усугубляет. Коммутаторы Hyper-V, мосты VMware, сети контейнеров и VPN-клиенты с собственными виртуальными адаптерами живут в одном пространстве. Сброс, переустанавливающий базовый стек, может оставить эти компоненты наполовину присутствующими, и получившаяся машина сообщает о работающем оборудовании без работающего пути.
Ничто из этого не довод против того, чтобы когда-нибудь сбрасывать. Это довод против того, чтобы сбрасывать первым, на машине, которую вы не задокументировали, когда настоящая неполадка может быть одной записью маршрута или одним устаревшим фильтром. Сброс — широкий инструмент с узкой долей успеха, и использование его в качестве первого хода гарантирует, что вы никогда не узнаете, что именно из двух это было.
Сохраните доказательства до того, как сохраните настройки
Сам сбой — это данные. Запишите точный код ошибки, время, какой профиль был выбран и зарегистрировал ли шлюз хоть одну попытку. Код, говорящий, что туннель так и не получил ответа, и код, говорящий, что аутентификация не удалась, указывают на совершенно разные исправления. После сброса воспроизвести, возможно, не удастся ни то, ни другое. Относитесь к сломанному состоянию как к активу, который вы вот-вот потратите.
Зафиксируйте состояние, пока оно ещё сломано, в папку вне временных каталогов машины:
mkdir C:\vpn-evidence
ipconfig /all > C:\vpn-evidence\ipconfig.txt
route print > C:\vpn-evidence\routes.txt
Get-VpnConnection -AllUserConnection | Export-Csv C:\vpn-evidence\profiles.csv -NoTypeInformation
netsh wfp show state file=C:\vpn-evidence\wfp.xml
Последняя команда — та, которую люди пропускают, и часто именно она объясняет неполадку. Оставшиеся фильтры удалённого клиента живут как постоянная политика, и выгруженный XML — единственная локальная запись о них. Прочитайте его до того, как сброс сотрёт то, что вы пытались опознать.
Сохраните конфигурацию, которая не вернётся
Некоторые параметры создаются заново автоматически. Статические адреса, нестандартные маршруты, суффиксы DNS, исключения прокси и правила брандмауэра — нет. Сами профили тоже, они живут в файле телефонной книги, который сброс за вас не восстановит.
| What to save | Where it lives | Why the reset loses it |
|---|---|---|
| VPN profiles | rasphone.pbk in ProgramData or the user profile | Profiles are not part of the adapter state |
| Static IP and DNS | Adapter configuration | Adapters are removed and recreated |
| Persistent filters | WFP policy store | Filter state is cleared with the stack |
| Third-party bindings | Adapter binding list | Components must be reinstalled manually |
Get-NetIPConfiguration | Out-File C:\vpn-evidence\netip.txt
Get-NetRoute -AddressFamily IPv4 | Export-Csv C:\vpn-evidence\netroutes.csv -NoTypeInformation
Get-DnsClientServerAddress | Export-Csv C:\vpn-evidence\dns.csv -NoTypeInformation
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject,Thumbprint,NotAfter
Список сертификатов важнее, чем кажется. Сброс сети не уничтожает клиентские сертификаты, но список говорит, от каких зависел профиль и не истекает ли какой-то скоро. Обнаружение истёкшего сертификата после пересборки тратит пересборку впустую.
Запишите путь восстановления до начала работы
Если машина удалённая и VPN — единственный вход, сброс может оборвать сеанс, и без человека на месте обратного пути может не быть. Подтвердите, что есть доступ вне полосы, или что человек доступен, прежде чем запускать что-либо, что трогает адаптеры.
Держите установщики и данные подключения там, где машина сможет достать их потом. Клиент, который приходится переустанавливать с портала поставщика, доступного через туннель, — это циклическая зависимость, и это самый частый способ, которым эта процедура превращается в простой.
Затем запишите, что вы делаете и почему, включая точные команды. Следующему человеку нужно знать, был сброс экспериментом или решением, а «мы перепробовали всё» — не запись.
Проверяйте по уровням после сброса
Восстановление слишком многого сразу делает результат нечитаемым. Работайте снизу: адаптер и адрес, затем разрешение имён, затем этап идентичности туннеля, затем приложение. У каждого уровня есть команда, отвечающая на его собственный вопрос:
Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceDescription
Resolve-DnsName intranet.example.internal
Get-VpnConnection -Name 'Corp' | Select-Object ConnectionStatus,TunnelType
Test-NetConnection -ComputerName intranet.example.internal -Port 443
Если уровень адаптера здоров, а разрешение имён нет, остановитесь и почините разрешение. Переустановка VPN-клиента в этот момент добавляет переменную и убирает улику. Восстанавливайте только те настройки, которые можете объяснить, по одной, проверяя один и тот же уровень после каждой.
Собственное руководство Microsoft по устранению неполадки 720, например, отличает проблемы привязки от проблем выделения адресов вместо того, чтобы предписывать общий сброс, и это верный инстинкт для любого кода в этом семействе. Прочитайте, что утверждает код, прежде чем тянуться к самому широкому доступному инструменту.