Сетевая маршрутизация в Windows: как проверить таблицу маршрутов и приоритет подключений

Быстрый ответ: как проверить маршрут до сервера или интернета

Чтобы понять, куда Windows отправляет трафик, сначала выполните ipconfig /all и проверьте IP-адрес, маску, DHCP, DNS и шлюз. Затем выведите таблицу командой route print -4, определите выбранный путь через Find-NetRoute -RemoteIPAddress <IP> и подтвердите прохождение пакетов с помощью tracert -d <IP> или проверкой нужного TCP-порта через Test-NetConnection <IP> -Port <порт>.

Порядок диагностики такой: состояние сетевого адаптера, IP-конфигурация и шлюз, маршрут до конкретного IP-адреса, метрики, VPN и статические записи. Имя сервера проверяйте отдельно: сначала получите его IP через Resolve-DnsName или nslookup, затем анализируйте маршрут именно к этому адресу.

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

Минимальный набор команд для первичной диагностики

Откройте PowerShell или командную строку. Команды просмотра не меняют сетевую конфигурацию и подходят для первого этапа проверки.

ipconfig /all
route print -4
Get-NetIPConfiguration
Find-NetRoute -RemoteIPAddress <IP>
tracert -d <IP>
Test-NetConnection <IP> -Port <порт>

• ipconfig /all показывает IPv4-адрес, маску, DHCP Enabled, шлюз по умолчанию и DNS Servers.
• route print -4 выводит активные IPv4-маршруты и раздел постоянных записей.
• Get-NetIPConfiguration дает компактную сводку по интерфейсам, адресам, шлюзам и DNS.
• Find-NetRoute показывает маршрут, который Windows подобрала для конкретного адреса назначения.
• tracert -d отображает переходы без попытки разрешать имена узлов, поэтому диагностика проходит быстрее и не смешивает маршрутизацию с DNS.
• Test-NetConnection проверяет TCP-доступность конкретного сервиса, например HTTPS на порту 443 или SMB на порту 445.

Подробный синтаксис операций добавления, изменения и удаления записей собран в шпаргалке по route и netsh.

Что сохранить до изменения маршрутов

Перед любыми правками сохраните исходную конфигурацию. Снимки позволяют сравнить состояние до и после подключения VPN, изменения метрики или перезагрузки.

route print -4 > routes-before.txt
ipconfig /all > ipconfig-before.txt
Get-NetIPInterface -AddressFamily IPv4 > interfaces-before.txt
Get-NetRoute -AddressFamily IPv4 > netroutes-before.txt

Добавление, удаление и изменение маршрутов обычно требует консоли с правами администратора. На удаленном сервере заранее подготовьте консольный или out-of-band-доступ. Не меняйте маршрут, через который идет текущая сессия RDP или WinRM, без проверенного плана отката: удаление шлюза может немедленно оборвать подключение.

Перед анализом маршрутов: проверяем адаптер, DHCP и шлюз по умолчанию

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

Состояние физических и виртуальных сетевых интерфейсов

В Windows откройте параметры сети и проверьте, что нужный Ethernet- или Wi-Fi-адаптер включен и имеет статус «Подключено». Для проводного подключения проверьте кабель, порт роутера или коммутатора и индикаторы линка на обоих устройствах.

Команды PowerShell помогают увидеть все интерфейсы, включая виртуальные:

Get-NetAdapter | Sort-Object ifIndex | Format-Table ifIndex,Name,Status,MacAddress,LinkSpeed
Get-NetIPConfiguration

Зафиксируйте четыре значения:

• имя адаптера, например Ethernet, Wi-Fi или VPN;
• статус интерфейса и физического линка;
• MAC-адрес, чтобы отличить похожие устройства;
• InterfaceIndex, он понадобится для сопоставления интерфейса с маршрутом.

На одном компьютере одновременно могут работать физические Ethernet и Wi-Fi, loopback, Hyper-V, Docker, VLAN, виртуальная пара Ethernet и VPN-интерфейс. Каждый такой объект способен иметь собственный IP-адрес и набор маршрутов. Поэтому проверка только значка Wi-Fi не показывает, через какой интерфейс система отправляет конкретный пакет.

Как проверить IP-адрес, DHCP, DNS и шлюз

В выводе ipconfig /all найдите блок нужного адаптера и проверьте поля IPv4 Address, Subnet Mask, DHCP Enabled, Default Gateway и DNS Servers.

ipconfig /all

В типичной домашней сети роутер выдает IP-адрес и DNS автоматически через DHCP. Для сети с роутером 192.168.1.1 компьютер может получить адрес 192.168.1.50, маску 255.255.255.0, шлюз 192.168.1.1 и DNS роутера. Эти значения служат примером. Сначала проверьте фактический диапазон своей сети.

Адрес из диапазона 169.254.0.0/16 обычно означает, что Windows не получила адрес от DHCP. В такой ситуации проверьте кабель, порт, состояние адаптера, DHCP-сервис на роутере или коммутаторе и наличие VLAN. Анализ маршрута к интернету до восстановления IP-конфигурации не даст полезного результата.

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

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

Почему DNS не нужно путать с маршрутизацией

DNS отвечает на вопрос, какой IP соответствует имени. Маршрутизация отвечает на вопрос, через какой интерфейс и шлюз отправить пакет к уже известному IP. Эти уровни проверяются разными командами.

Resolve-DnsName <hostname>
nslookup <hostname>
Find-NetRoute -RemoteIPAddress <IP-из-ответа>

Если IP-адрес сервера доступен, а имя не разрешается, ищите проблему в DNS, суффиксе поиска, DNS-сервере или локальной политике. Если имя разрешается корректно, но IP недоступен, проверяйте маршрут, шлюз, ACL, VPN, межсетевой экран и состояние удаленного узла.

Как Windows выбирает маршрут: длина префикса, метрика маршрута и приоритет сетевых подключений

Windows сопоставляет IP-адрес назначения с подходящими записями таблицы маршрутов. Сначала выбирается наиболее специфичный префикс, затем среди маршрутов с одинаковой длиной префикса сравнивается эффективная метрика.

Наиболее специфичный маршрут всегда важнее маршрута по умолчанию

Маршрут по умолчанию 0.0.0.0/0 подходит для любого IPv4-адреса, если более точной записи нет. Сеть 10.20.0.0/16 подходит только для диапазона 10.20.0.0-10.20.255.255. Сеть 10.20.30.0/24 уже точнее и будет выбрана для адресов 10.20.30.0-10.20.30.255.

Маршрут 10.20.30.0/24 будет выбран раньше 10.20.0.0/16, даже если его метрика выше. Поэтому снижение метрики Wi-Fi или Ethernet не исправит ошибочную запись к конкретной подсети. При проблеме с одним сервером ищите маршруты /32, /24 и /16, которые перекрывают ожидаемый путь.

Метрика маршрута Windows и метрика интерфейса

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

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Format-Table ifIndex,InterfaceAlias,ConnectionState,AutomaticMetric,InterfaceMetric
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix,RouteMetric | Format-Table DestinationPrefix,NextHop,InterfaceIndex,RouteMetric,PolicyStore

При одинаковом префиксе путь с меньшей эффективной метрикой получает предпочтение. Если Ethernet и Wi-Fi имеют по маршруту 0.0.0.0/0, метрика помогает выбрать один из шлюзов. Если один путь ведет к более узкому корпоративному префиксу, длина префикса имеет приоритет над разницей метрик.

При включенном Automatic Metric Windows назначает значение сама с учетом характеристик интерфейса. Это удобно для обычной рабочей станции, но может мешать на multi-homed-сервере, где администратор ожидает строгое распределение трафика. Ручные метрики задавайте после проверки таблицы и фиксируйте в документации узла.

Как изменить приоритет сетевых подключений Windows корректно

Сначала получите индекс и имя интерфейса:

Get-NetIPInterface -AddressFamily IPv4 | Format-Table ifIndex,InterfaceAlias,AutomaticMetric,InterfaceMetric,ConnectionState

Затем отключите автоматическую метрику только на выбранном интерфейсе и задайте значение:

Set-NetIPInterface -InterfaceIndex <ifIndex> -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric <метрика>

Меньшее значение повышает приоритет только среди маршрутов с одинаковой длиной префикса. После изменения проверьте конкретное направление:

Find-NetRoute -RemoteIPAddress <IP-цели>
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix,RouteMetric

Если результат не изменился, ищите более специфичную запись. Изменение метрики интерфейса не отменяет маршрут /32 или /24, который точнее подходит к адресу назначения.

Команда route print в Windows: как читать таблицу маршрутов

Команда route print -4 показывает не один маршрут, а весь набор активных IPv4-записей. При проблеме анализируйте строки, которые совпадают с адресом цели, и отдельно проверяйте раздел Persistent Routes.

Поля Network Destination, Netmask, Gateway, Interface и Metric

В выводе route print маска помогает определить длину префикса. Например, 255.255.255.0 соответствует /24, 255.255.0.0 соответствует /16, а 255.255.255.255 соответствует маршруту одного хоста /32.

Значение On-link в поле Gateway означает, что сеть подключена непосредственно к интерфейсу. Windows не отправляет пакет отдельному IP-шлюзу, а разрешает адрес узла в локальном сегменте через ARP. Само значение On-link не говорит об ошибке.

Поле Interface в классическом выводе содержит локальный IP-адрес, а не индекс адаптера. Сопоставьте его с выводом ipconfig /all или Get-NetIPConfiguration. В PowerShell связь видна по InterfaceIndex:

Get-NetIPConfiguration | Format-Table InterfaceAlias,InterfaceIndex,IPv4Address,IPv4DefaultGateway
Get-NetIPInterface -AddressFamily IPv4 | Format-Table ifIndex,InterfaceAlias,InterfaceMetric

Как найти маршрут к конкретному серверу или подсети

Сначала получите IP-адрес сервера. Затем найдите в таблице все записи, диапазон которых включает этот адрес. Сравните маски, определите самый специфичный префикс и только после этого сравните метрики.

Допустим, сервер имеет адрес 10.20.30.25, а в таблице присутствуют такие записи:

Network Destination    Netmask          Gateway       Interface      Metric
0.0.0.0                0.0.0.0          192.168.1.1   192.168.1.50   25
10.20.0.0              255.255.0.0      10.10.0.1     10.10.0.20     15
10.20.30.0             255.255.255.0    10.10.0.254   10.10.0.20     40
10.20.30.25             255.255.255.255  10.10.0.99    10.10.0.20     5

Для адреса 10.20.30.25 совпадают четыре строки. Windows выберет маршрут /32, потому что он описывает один хост. Если этой записи нет, победит 10.20.30.0/24. Маршрут 10.20.0.0/16 и default route в этом сценарии не используются.

Неожиданный /32, /24 или /16 часто объясняет доступность одной части корпоративной сети и недоступность другой. Проверьте шлюз, интерфейс и источник записи, прежде чем менять метрики.

Активные и постоянные маршруты: почему запись возвращается после перезагрузки

В разделе Active Routes находятся записи, которые участвуют в текущем выборе пути. В разделе Persistent Routes отображаются маршруты, которые Windows должна восстановить после перезагрузки.

Постоянная запись могла появиться после ручной команды route -p add, установки VPN-клиента, применения групповой политики, получения параметров через DHCP или работы программного обеспечения сетевого адаптера. Удаление строки из активной таблицы устранит симптом только до следующего запуска механизма, который создает ее снова.

Если маршрут возвращается, зафиксируйте время его появления и сравните таблицу после следующих действий: перезагрузка, переподключение VPN, обновление DHCP-аренды, включение виртуальной машины или запуск управляющего агента.

Проверка таблицы маршрутов через PowerShell

PowerShell удобнее для фильтрации, сортировки и сохранения данных в CSV. Базовый снимок:

Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix,RouteMetric | Format-Table DestinationPrefix,NextHop,InterfaceIndex,RouteMetric,PolicyStore
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Format-Table ifIndex,InterfaceAlias,AutomaticMetric,InterfaceMetric

Для проверки маршрутов по умолчанию используйте фильтр:

Get-NetRoute -AddressFamily IPv4 | Where-Object {$_.DestinationPrefix -eq '0.0.0.0/0'} | Format-Table DestinationPrefix,NextHop,InterfaceIndex,RouteMetric,PolicyStore

Для сравнения до и после подключения VPN сохраните данные в CSV:

Get-NetRoute -AddressFamily IPv4 | Export-Csv routes.csv -NoTypeInformation -Encoding UTF8
Get-NetIPInterface -AddressFamily IPv4 | Export-Csv interfaces.csv -NoTypeInformation -Encoding UTF8

Для IPv6 запускайте отдельную проверку: route print -6 и Get-NetRoute -AddressFamily IPv6. IPv4-маршрут не объясняет проблему, которая возникает только при обращении к IPv6-адресу.

Как определить активный маршрут до IP-адреса

Общая таблица показывает доступные варианты. Для точного ответа по конкретному серверу используйте Find-NetRoute, затем подтвердите выбор прикладным тестом и трассировкой.

Find-NetRoute: какой интерфейс и шлюз выбраны системой

Find-NetRoute -RemoteIPAddress <IP>

В результате ищите DestinationPrefix, NextHop, InterfaceIndex и метрики. По InterfaceIndex определите имя интерфейса:

Get-NetIPInterface -InterfaceIndex <ifIndex> -AddressFamily IPv4
Get-NetAdapter -InterfaceIndex <ifIndex>

Если результат указывает на Ethernet, проверьте, что адрес и шлюз этого интерфейса соответствуют ожидаемой схеме. Если выбран Wi-Fi, виртуальный адаптер или VPN, выясните, какой префикс направил Windows именно туда. Поле NextHop должно указывать на достижимый шлюз, если маршрут не имеет значение On-link.

Для имени хоста сначала выполните Resolve-DnsName. При нескольких A-записях проверьте каждый возвращенный IP, потому что разные адреса могут попадать в разные маршруты.

tracert и Test-NetConnection: как подтвердить проблему на пути

После проверки локального выбора маршрута используйте трассировку:

tracert -d <IP>

Первый отвечающий переход часто совпадает с ожидаемым локальным шлюзом. Неожиданный первый шлюз указывает на другой интерфейс, VPN или ошибочную запись. Пустые строки и звездочки не доказывают ошибку маршрута: промежуточный маршрутизатор может блокировать ICMP или не отвечать на запросы трассировки.

Проверяйте сам сервис отдельной командой:

Test-NetConnection <IP> -Port 443
Test-NetConnection <IP> -Port 445

Успешная трассировка не гарантирует доступность TCP-порта. Сетевой путь может работать, а firewall, ACL или служба на сервере могут отклонять соединение. Обратная ситуация тоже встречается: ICMP блокируется, но HTTPS или SMB доступен.

Как интерпретировать результат: локальный маршрут, недоступный шлюз или проблема на удаленной стороне

Разделяйте доступность маршрута и доступность приложения. Команда Find-NetRoute доказывает локальное решение Windows. Test-NetConnection проверяет путь до TCP-службы. Для полного вывода нужны оба результата.

Несколько адаптеров и VPN: почему трафик идет не через тот шлюз

Ethernet, Wi-Fi и VPN могут одновременно иметь адреса, шлюзы и маршруты по умолчанию. Виртуальные интерфейсы Hyper-V, Docker и других платформ добавляют собственные локальные сети. Поэтому приоритет подключений Windows нужно оценивать по таблице маршрутов и конкретному адресу назначения.

Full tunnel и split tunnel: какие маршруты добавляет VPN

При схеме full tunnel VPN-клиент может добавить или сделать приоритетным маршрут 0.0.0.0/0. Весь IPv4-трафик, включая интернет-запросы, пойдет через туннельный интерфейс и выбранный VPN-сервер.

При схеме split tunnel VPN добавляет маршруты только к корпоративным подсетям. Интернет продолжает использовать локальный Ethernet- или Wi-Fi-шлюз. Такое поведение зависит от VPN-клиента, профиля подключения и корпоративной политики.

Сравните состояние до и после подключения:

route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix,RouteMetric
Find-NetRoute -RemoteIPAddress <публичный_IP>
Find-NetRoute -RemoteIPAddress <корпоративный_IP>

Если после запуска VPN появился новый default route, проверьте, ожидает ли этого политика full tunnel. Если добавились только маршруты к корпоративным диапазонам, вероятен split tunnel. Сравнивайте результат до и после, а не делайте вывод по одному значку VPN.

Маршрут до VPN-сервера нельзя направлять внутрь того же туннеля

Транспорт до внешнего адреса VPN-сервера должен оставаться доступным через исходный физический шлюз. Если изменить default route так, что пакет к VPN-серверу пойдет внутрь этого же туннеля, соединение может потерять транспорт и разорваться.

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

Ethernet, Wi-Fi и виртуальные адаптеры: что проверять при конфликте приоритетов

Сопоставьте три источника:

1. Get-NetIPInterface показывает InterfaceIndex, имя и метрику интерфейса.
2. ipconfig /all показывает IP-адрес, DHCP, DNS и шлюз.
3. Find-NetRoute показывает путь к конкретному серверу или публичному IP.

Временное отключение ненужного адаптера допустимо как диагностический тест. Если после отключения Wi-Fi сервер стал доступен, это подтверждает влияние второго подключения, но не указывает точную ошибочную запись. Для постоянной конфигурации найдите конфликтующий маршрут или настройте метрику, а не полагайтесь на старый порядок подключений в графическом интерфейсе.

Для лаборатории с Windows-клиентом, отдельным шлюзом и несколькими подсетями можно использовать изолированную облачную инфраструктуру Timeweb Cloud. В рабочей сети сначала составьте схему адресов и предусмотрите откат изменений.

Ошибочная запись и статические маршруты Windows: безопасное исправление

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

Признаки ошибочного маршрута в таблице

• Подсеть идет через неизвестный или недостижимый шлюз.
• Более специфичный префикс перекрывает ожидаемый корпоративный маршрут.
• Запись указывает на выключенный, удаленный или неиспользуемый адаптер.
• Для одного сервера появился неожиданный маршрут /32.
• После подключения VPN изменился маршрут по умолчанию без ожидаемой причины.
• После запуска VPN появились частные диапазоны, направленные на неправильный туннель.
• Одна сеть доступна, а соседняя с похожей адресацией использует другой шлюз.

Запись On-link не считают ошибочной только из-за этого значения. Она корректна для сети, которая действительно подключена непосредственно к интерфейсу. Проверяйте адрес интерфейса, маску и фактическую топологию.

Частые ошибки с неправильным шлюзом, маской, метрикой и конфликтующими записями разобраны в статье о проверке и исправлении ошибок маршрутизации.

Как безопасно протестировать временный статический маршрут

Временный маршрут добавляют без ключа -p. Сначала убедитесь, что шлюз доступен через выбранный интерфейс и находится в локальной подсети.

route add <сеть> mask <маска> <шлюз> metric <метрика> if <ifIndex>

Пример для сети 10.20.30.0/24 через шлюз 10.20.0.1 и интерфейс 12:

route add 10.20.30.0 mask 255.255.255.0 10.20.0.1 metric 5 if 12

После добавления проверьте выбор и сервис:

Find-NetRoute -RemoteIPAddress <IP-цели>
Test-NetConnection <IP-цели> -Port <порт>
tracert -d <IP-цели>

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

На удаленной машине тестируйте изменения с запасным каналом доступа. Команда, которая удаляет маршрут к текущему RDP-серверу или меняет default route, может оборвать сессию до завершения проверки.

Удаление, замена и закрепление статического маршрута

Если временный маршрут не дал нужного результата, удалите его:

route delete <сеть>

Когда гипотеза подтверждена, можно изменить существующую запись:

route change <сеть> mask <маска> <шлюз> metric <метрика> if <ifIndex>

Постоянную запись добавляйте только после успешного теста:

route -p add <сеть> mask <маска> <шлюз> metric <метрика> if <ifIndex>

После изменения снова выполните route print -4, Find-NetRoute и проверку нужного TCP-порта. Проверьте поведение после переподключения VPN и перезагрузки. Если маршрут создают DHCP, VPN-клиент, групповая политика или другое управляющее ПО, исправляйте источник. Иначе запись вернется.

Типовые симптомы, контроль после изменений и сброс сети

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

Не открывается один сервер или сетевая папка

1. Разрешите имя сервера через Resolve-DnsName и выпишите полученный IP.
2. Выполните Find-NetRoute -RemoteIPAddress <IP-сервера>.
3. Проверьте маршруты /32, /24 и /16, которые совпадают с адресом.
4. Сравните NextHop и InterfaceIndex с ожидаемой сетевой схемой.
5. Проверьте порт службы: Test-NetConnection <IP-сервера> -Port 445 для SMB или другой порт приложения.
6. Если маршрут корректен, проверьте firewall, ACL, службу на сервере и политики VPN.

Если IP доступен, а имя нет, вернитесь к DNS. Изменение таблицы маршрутов не исправит ошибку разрешения имен.

Не работает интернет при активных Ethernet, Wi-Fi или VPN

Сначала выведите все маршруты по умолчанию:

Get-NetRoute -AddressFamily IPv4 | Where-Object {$_.DestinationPrefix -eq '0.0.0.0/0'} | Format-Table DestinationPrefix,NextHop,InterfaceIndex,RouteMetric,PolicyStore

Затем выполните Find-NetRoute -RemoteIPAddress <публичный_IP> и проверьте:

• есть ли доступный шлюз по умолчанию;
• не указывает ли маршрут на выключенный или не подключенный адаптер;
• не получен ли адрес 169.254.x.x вместо адреса DHCP;
• не появился ли после запуска VPN ожидаемый или ошибочный full tunnel;
• не направлен ли интернет через виртуальный интерфейс без выхода во внешнюю сеть.

Сравните результат при подключенном и отключенном VPN. Если интернет должен идти через локальный роутер, а выбран туннель, проверяйте профиль VPN и маршрут по умолчанию. Если корпоративная политика требует full tunnel, такой путь может быть штатным, а причину недоступности нужно искать на VPN-шлюзе или в его правилах.

Когда нужен сброс параметров сети в Windows 11

Сброс сети используйте после фиксации конфигурации и исключения физической проблемы, DHCP, DNS, метрик, VPN-маршрутов и статических записей. Эта процедура не заменяет поиск причины.

Путь в Windows 11:

1. Откройте «Параметры».
2. Перейдите в «Сеть и Интернет».
3. Откройте «Дополнительные сетевые параметры».
4. Выберите «Сброс сети».
5. Нажмите «Сбросить сейчас» и подтвердите действие.

После сброса требуется перезагрузка устройства. Сохраните заранее статический IP, DNS, параметры VPN, настройки виртуальных адаптеров и сведения о нужных сетевых профилях. После запуска Windows может потребоваться повторно настроить VPN, статический адрес, DNS, виртуальные коммутаторы и другие сетевые параметры.

Финальный чек-лист после исправления

• Нужный физический или виртуальный адаптер включен и имеет ожидаемый статус.
• IPv4-адрес, маска или префикс и шлюз соответствуют схеме сети.
• DHCP выдает корректные параметры либо статическая настройка задокументирована.
• DNS-имя разрешается в ожидаемый IP-адрес.
• Find-NetRoute выбирает правильный интерфейс и NextHop для внутреннего сервера.
• Find-NetRoute выбирает ожидаемый путь для публичного IP.
• Test-NetConnection подтверждает доступность нужного TCP-порта.
• tracert -d показывает ожидаемый первый шлюз, если промежуточные устройства отвечают на ICMP.
• В Persistent Routes нет лишней или конфликтующей записи.
• Поведение сохраняется после переподключения VPN, обновления DHCP и перезагрузки.
• Итоговые выводы route print -4 и Get-NetIPInterface сохранены в документации узла.

Для диагностики маршрутизации в Windows достаточно двигаться по цепочке: адаптер, IP-конфигурация, DNS, выбранный маршрут, шлюз, TCP-порт и удаленная служба. Такой порядок помогает отделить ошибочную запись таблицы от проблем канала, VPN, фильтрации или самого сервера.