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

Question

Вчера днем я внезапно не смог перенаправить пакеты в vpn моей компании на моей машине с Windows 8, хотя я "успешно" подключился. Может кто-нибудь объяснить мне, как с этой таблицей маршрутизации Windows пытается использовать интерфейс 192.168.2.1 вместо 172.30.0.1 для 172.29.3.91? Я сравнил эту таблицу с моей машиной win 7, которая отлично работает, и я не вижу никакой разницы. Какого черта здесь происходит?

C:\Windows\system32>tracert -d 172.29.3.91

Tracing route to 172.29.3.91 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.2.1
  2  ^C
C:\Windows\system32>route print
===========================================================================
Interface List
 12...bc 5f f4 44 9c 00 ......Realtek PCIe GBE Family Controller
 31...00 05 9a 3c 78 00 ......Cisco Systems VPN Adapter for 64-bit Windows
  1...........................Software Loopback Interface 1
 20...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
 22...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.2.1      192.168.2.4     50
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
       ***172.16.0.0      255.240.0.0       172.30.0.1    172.30.128.96    100***
       172.30.0.0      255.255.0.0         On-link     172.30.128.96    266
    172.30.128.96  255.255.255.255         On-link     172.30.128.96    266
   172.30.255.255  255.255.255.255         On-link     172.30.128.96    266
      192.168.1.0    255.255.255.0       172.30.0.1    172.30.128.96    100
      192.168.2.0    255.255.255.0         On-link       192.168.2.4    306
      192.168.2.1  255.255.255.255         On-link       192.168.2.4    100
      192.168.2.4  255.255.255.255         On-link       192.168.2.4    306
    192.168.2.255  255.255.255.255         On-link       192.168.2.4    306
     206.XXX.XXX.XXX    255.255.255.0       172.30.0.1    172.30.128.96    100
   208.XXS.XXX.XXX  255.255.255.255      192.168.2.1      192.168.2.4    100
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link       192.168.2.4    306
        224.0.0.0        240.0.0.0         On-link     172.30.128.96    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link       192.168.2.4    306
  255.255.255.255  255.255.255.255         On-link     172.30.128.96    266
===========================================================================
Persistent Routes:
  None

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
  1    306 ::1/128                  On-link
  1    306 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

C:\Windows\system32> tracert -d 172.30.0.1

Трассировка маршрута до 172.30.0.1 в течение максимум 30 прыжков

1 4 мс 1 мс 1 мс 192.168.2.1 2 * * ^ C

Answer 1

Я не гуру маршрутизации, но у меня была похожая (но разная) проблема с Win8 с Ethernet и WiFi, подключенными к двум разным сетям, и Wi-Fi, установленный в качестве привилегированной сети в расширенных настройках сети. Работает нормально в Win7, но Win8 продолжал использовать только Ethernet.

Я решил свою проблему, вручную назначив метрики интерфейсам, которые хотел бы выбрать.

Что произойдет, если вы уменьшите показатель этого 172 маршрута ниже 50? Но тогда он попытается отправить все через VPN, а не через шлюз по умолчанию? Извините, не TCP-гуру.