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

Два представления одного туннеля

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

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

Прочитайте оба представления, ничего не меняя

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

Get-VpnConnection | Select-Object Name,ServerAddress,TunnelType,SplitTunneling,ConnectionStatus

У представления интерфейса другая форма: один туннель может занимать две строки, когда несёт оба семейства адресов. Читайте индекс как идентичность, а псевдоним как метку, выбранную кем-то, и ожидайте, что псевдоним изменится между версиями клиента.

Get-NetIPInterface | Select-Object InterfaceIndex,InterfaceAlias,AddressFamily,ConnectionState,InterfaceMetric

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

Пройдите по маршруту до назначения

Спросите стек, какой путь он выберет для адреса, с которым приложение действительно связывается. Это вопрос, на который список интерфейсов не может ответить сам.

Find-NetRoute -RemoteIPAddress 10.60.20.10 | Select-Object -First 1
Get-NetIPAddress -InterfaceIndex 37 | Select-Object IPAddress,AddressFamily,PrefixLength

Первая команда сообщает два поля, которые стоит прочитать: псевдоним интерфейса выбранного источника и следующий прыжок для этого назначения. Индекс 37 во второй команде — это то, что напечатал первый вывод, а не константа для копирования, и адрес 10.60.20.10 приведён для примера. Если выбранный источник принадлежит физическому адаптеру, а назначение должно быть внутри туннеля, вы нашли проблему выбора, потому что интерфейс VPN может быть полностью здоровым и просто не иметь предпочтения. Метрика — лишь часть этого решения, поскольку специфичность маршрута, политика и состояние интерфейса участвуют все.

Сравните три состояния в одинаковых условиях

Запишите список интерфейсов и выбранный маршрут до подключения, во время подключения и после отключения, каждый раз с одним и тем же назначением и одними и теми же командами. Это сравнение отделяет текущий туннельный интерфейс от старого скрытого адаптера, оставленного удалением, и от второго клиента, который тоже работает. Оно также скажет, исчезает ли туннельный интерфейс чисто, потому что адаптер, остающийся после отключения, — это другая проблема, чем тот, который так и не появился. Без трёх снимков каждый незнакомый псевдоним выглядит виновником.

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

Не удаляйте то, что вы не определили

Незнакомые адаптеры обычно кому-то принадлежат: управляемому клиенту, виртуальному коммутатору, сети контейнеров или агенту безопасности. Удаление одного может убрать работающий компонент и оставить исходный симптом ровно там, где он был. Если маршрут устарел, найдите владельца маршрута и исправьте его там; если профиль неверен, отредактируйте профиль. Документация Get-NetIPInterface перечисляет использованные выше поля, включая столбцы метрики и состояния, которые делают сравнение осмысленным.

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

Похожие статьи