Розуміння таблиць маршрутизації та шлюзів за замовчуванням у Windows

Примітка. Це моя лабораторія домашнього комп’ютера, а не бізнес / виробниче середовище. Я більш ніж радий її зламати та виправити ще раз, тому будь-які пропозиції вітаються!

ПІДСУМОК

Я додав цей короткий підсумок, тому що це питання стає досить довгим. Якщо ви хочете отримати детальнішу інформацію про таблиці маршрутизації, IP-конфігурації тощо, дивіться нижче.

У мене на комп’ютері кілька NIC. Один NIC - це 172.16.200.1 / 24. Коли я намагаюся ввімкнути файл 172.16.200.2 (хост, який існує в мережі), я отримую відповідь. Все йде нормально.

Коли я спробую підключитися до 172.16.200.5 (або будь-якого іншого хоста, який не існує), комп'ютер повернеться до мого маршруту за замовчуванням (0.0.0.0 через мій шлюз за замовчуванням 192.168.0.1) - це буде відправлено мій домашній маршрутизатор, де він втрачається в циклі маршрутизації в моїй мережі провайдерів. Більше деталей подано нижче, якщо потрібно, але я здогадуюсь, що там є гуру, який вже може відповісти на це ...

Моє запитання:

Як зупинити повернення комп’ютера до шлюзу за замовчуванням для приватної мережі, коли хост у цій мережі не відповідає. Ці приватні мережі вже мають явні маршрути із меншими показниками.

Я перевірив це на кількох машинах (Server 2008 R2, Windows 7, Hyper-V Server 2012 R2, Windows Server 2012), і всі вони поводяться однаково. Я починаю визнавати, що це «нормальна поведінка» для машин Windows, але мені цікаво, чи можна це зупинити.

Я створив VM Ubuntu з тією ж конфігурацією, що і мої Windows VM - Ubuntu VM не повертається до маршруту за замовчуванням, як це роблять Windows VM. Я додав таблиці маршрутизації та результати для Ubuntu VM та Windows 8.1 VM внизу цієї публікації.

ДАЛЬНІ ДЕТАЛІ

Я провів обширний пошук цього питання, і найближче питання, яке я бачив, тут: Петля маршрутизації: TTL минув у дорозі , але, на жаль, він не відповідає, як зупинити проблему або змінити поведінку на комп’ютері. Відповідь пропонує виправити маршрутизацію. Я можу змінити маршрутизатор, щоб скинути все, призначене для приватних IP-адрес (або переслати його на IP-адреси моїх односельців, хе-хе), але це не змінить поведінку мого комп'ютера. (Я також прочитав чудовий посібник із підмережі, на який посилався в оригінальній відповіді, який можна знайти за посиланням https://serverfault.com/questions/49765/how-does-ipv4-subnetting-work )

У мене виникають проблеми з розумінням того, чому мої комп’ютери намагатимуться підключитися до приватних IP-адрес через Інтернет, як тільки вони спробували використовувати внутрішні адаптери (на короткий період), а потім не вдалося - наприклад, намагаючись пінг-хосту, який я знаю не існує в моїй мережі ...

Pinging 172.16.200.32 with 32 bytes of data:
Reply from 172.16.200.1: Destination host unreachable.
Reply from 203.29.XXX.YY: TTL expired in transit.
Reply from 203.29.XXX.YY: TTL expired in transit.
Reply from 203.29.XXX.YY: TTL expired in transit.

Ping statistics for 172.16.200.32:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Але pinging хоста, який існує, працює ...

Pinging 172.16.200.2 with 32 bytes of data:
Reply from 172.16.200.2: bytes=32 time<1ms TTL=128
Reply from 172.16.200.2: bytes=32 time<1ms TTL=128
Reply from 172.16.200.2: bytes=32 time<1ms TTL=128
Reply from 172.16.200.2: bytes=32 time<1ms TTL=128

Ping statistics for 172.16.200.2:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

Гаразд, тому у відповіді від 172.16.200.1 на моєму комп’ютері сказано, що відповіді не отримано… але тоді, чому він навіть намагається підключитися через Інтернет? У мене є 4 NIC, і я перебуваю в мережі 172.16.200.0 / 24 на одному з них ...

Ethernet adapter HyperV External (built in):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::582c:97
   IPv4 Address. . . . . . . . . . . : 172.16.1.1
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :

Ethernet adapter Expansion-2 (middle) HomeNetwork:

   Connection-specific DNS Suffix  . : Home
   IPv4 Address. . . . . . . . . . . : 192.168.0.117
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.0.1

Ethernet adapter Expansion-3 (bottom) iSCSI-1 :

   Connection-specific DNS Suffix  . :
   IPv4 Address. . . . . . . . . . . : 172.16.100.1
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :

Ethernet adapter Expansion-1 (top) iSCSI-2:

   Connection-specific DNS Suffix  . :
   IPv4 Address. . . . . . . . . . . : 172.16.200.1
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :

Тож у цей момент було б доцільно подивитися таблицю маршрутизації ...

===========================================================================
Interface List
 16...64 70 02 00 1f 03 ......Gigabit PCI Express Network Adapter #2
 15...64 70 02 00 40 48 ......Gigabit PCI Express Network Adapter
 23...00 24 1d 1d f8 35 ......TST Onboard
 17...64 70 02 00 32 c1 ......Gigabit PCI Express Network Adapter #3
  1...........................Software Loopback Interface 1
 28...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 26...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
 13...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
 27...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3
 29...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #4
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.0.1    192.168.0.117    410
        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.1.0    255.255.255.0         On-link        172.16.1.1    266
       172.16.1.1  255.255.255.255         On-link        172.16.1.1    261
     172.16.1.255  255.255.255.255         On-link        172.16.1.1    261
     172.16.100.0    255.255.255.0         On-link      172.16.100.1    266
     172.16.100.1  255.255.255.255         On-link      172.16.100.1    266
   172.16.100.255  255.255.255.255         On-link      172.16.100.1    266
     172.16.200.0    255.255.255.0         On-link      172.16.200.1    266
     172.16.200.1  255.255.255.255         On-link      172.16.200.1    266
   172.16.200.255  255.255.255.255         On-link      172.16.200.1    266
      192.168.0.0    255.255.255.0         On-link     192.168.0.117    266
    192.168.0.117  255.255.255.255         On-link     192.168.0.117    266
    192.168.0.255  255.255.255.255         On-link     192.168.0.117    266
        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.0.117    266
        224.0.0.0        240.0.0.0         On-link      172.16.100.1    266
        224.0.0.0        240.0.0.0         On-link      172.16.200.1    266
        224.0.0.0        240.0.0.0         On-link        172.16.1.1    261
  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.0.117    266
  255.255.255.255  255.255.255.255         On-link      172.16.100.1    266
  255.255.255.255  255.255.255.255         On-link      172.16.200.1    266
  255.255.255.255  255.255.255.255         On-link        172.16.1.1    261
===========================================================================
Persistent Routes:
  None

Я спочатку подумав, що винуватцем є показник маршруту 0,0.0.0 - спочатку він був 6, тому спробував змінити його на 410, що не змінило поведінку. (До речі, я ніколи раніше не псувався з таблицею маршрутизації на цій машині). Потім я порівняв його з машиною Hyper-V 2012 R2 у мене в 3-х таких же мережах (172.16.1.0, 172.16.100.0 та 172.16.200.0), і я помітив, що машина Hyper-V також має показник 6 для 0,0 .0.0 маршрут, тож я гадаю, що це нормально і правильно ...

Потім я спробував змінити 172.16.200.0 на стійкий маршрут, як показано нижче, але все одно не вийшло.

===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
       172.16.200.0  255.255.255.0       172.16.1.1       1
===========================================================================

Я також намагався збільшити показник (я знаю, що нижчий є кращим, але просто так, так?) ... звичайно, не пощастило.

У вікні "Розширені налаштування" у вікні мережевих підключень я підтвердив, що адаптер 192.168.0.117 є найнижчим у порядку адаптерів та зв'язків ...

Отож, трохи стукнувшись головою, я застряг. Очевидно, що видалення маршруту 0.0.0.0 зупиняє його, але, звичайно, це зупинить і мій Інтернет ...

Як на землі я можу зупинити свою машину від спроби пройти через мій шлюз за замовчуванням 192.168.0.1, коли він намагається досягти хоста 172.16.200.0…

http://technet.microsoft.com/en-us/library/cc779122%28v=ws.10%29.aspx ("Таблиця маршрутизації IP: TCP / IP"), здається, говорить про те, що "Маршрут за замовчуванням зазвичай пересилає IP дейтаграма (для якої немає відповідного або явного локального маршруту) до адреси шлюзу за замовчуванням для маршрутизатора в локальній підмережі. " Наскільки ясніше я можу отримати цей маршрут!

Відповідь тут стійкий шлюз маршрутів Windows недоступний, тому використовуваний маршрут за замовчуванням говорить про те, що це нормальна поведінка - коли додається стійкий маршрут, він буде намагатися використовувати цей маршрут, якщо це можливо, але потім повернеться до стандартного маршруту, коли це не вдасться. Звичайно, це може спричинити досить серйозні проблеми з дорожнім рухом, не кажучи вже про проблеми безпеки (приватна інформація просочується в Інтернет, або принаймні приватні мережі ваших Інтернет-провайдерів ...)

Деякі додаткові відомості: Цей сервер запускає NPS / RRAS, як правило - вимкнення його та навіть його видалення нічого не зробило. Крім того, я створив абсолютно новий VM 2008 R2, надав йому два NIC, один безпосередньо в мережі 192.168.0.0, а інший у мережі 172.16.200.0, і він зробив те саме ... Я сподіваюся, ви можете сказати, що я витратили на це трохи часу.

Я встановив свій домашній маршрутизатор, щоб переслати всі речі 172.16.XX назад на власний комп’ютер, але це вирішення…

Що-небудь мені не вистачає? Щось очевидне, можливо? Я запитую неможливе?

[ОНОВЛЕННЯ №1 І №2]

Я переглянув кожен біт конфігурації на моєму маршрутизаторі і, схоже, не обробляє жодних проксі-запитів ARP - у нього навіть немає налаштувань, які я бачу.

Я використовував MS Network Monitor 3.4, щоб перевірити, чи відповідає маршрутизатор на запити ARP, і ні. Я бачу, як запит ARP надсилається, коли я намагаюся пінг неіснуючого хоста, і я не отримую відповідей ARP. Pinging хоста, який існує, природно дає мені відповідь ARP. Чи безпечно припустити в цей момент, що мій маршрутизатор не обробляє ARP-запити проксі?

Таблиця маршрутизації на маршрутизаторі БИЛА наступною:

 > route show
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.20.21.36     *               255.255.255.255 UH    0      0        0 ppp0
192.168.0.0     *               255.255.255.0   U     0      0        0 br0
default         *               0.0.0.0         U     0      0        0 ppp0

Ці записи я додав нижче як тимчасовий захід зупинки - це зупиняє мої бідні "втрачені" пакети від переходу до мого провайдера:

172.16.1.0      192.168.0.117   255.255.255.0   UG    1      0        0 br0
172.16.100.0    192.168.0.117   255.255.255.0   UG    1      0        0 br0
172.16.200.0    192.168.0.117   255.255.255.0   UG    1      0        0 br0

[ОНОВЛЕННЯ №3 - Додано таблиці маршрутизації VM Ubuntu та Win8.1]

Гаразд, тому я створив абсолютно новий Ubuntu VM та абсолютно новий Windows 8.1 VM. Ubuntu VM не намагається повернутися до маршруту 0,0.0.0, але Windows 8.1. Я спробував старий хост ping-a-existant і спостерігав за трафіком на маршрутизаторі 172.16.1.1. Він отримує ICMP-запити від Windows 8.1 VM та передає їх, але він ніколи не бачить ICMP-трафіку від Ubuntu VM.

Таблиця Ubuntu VM наведена нижче:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface    MSS   Window irtt
0.0.0.0         172.16.1.1      0.0.0.0         UG    0      0        0 eth0     0     0      0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth1     0     0      0
172.16.1.0      0.0.0.0         255.255.255.0   U     1      0        0 eth0     0     0      0
172.16.200.0    0.0.0.0         255.255.255.0   U     1      0        0 eth1     0     0      0

Таблиця Windows 8.1 наведена нижче:

===========================================================================
Interface List
  9...00 15 5d 01 4c 1c ......Microsoft Hyper-V Network Adapter #2
  3...00 15 5d 01 4c 08 ......Microsoft Hyper-V Network Adapter
  1...........................Software Loopback Interface 1
  4...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       172.16.1.1     172.16.1.101      5
        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.1.0    255.255.255.0         On-link      172.16.1.101    261
     172.16.1.101  255.255.255.255         On-link      172.16.1.101    261
     172.16.1.255  255.255.255.255         On-link      172.16.1.101    261
     172.16.200.0    255.255.255.0         On-link      172.16.200.1    261
     172.16.200.1  255.255.255.255         On-link      172.16.200.1    261
   172.16.200.255  255.255.255.255         On-link      172.16.200.1    261
        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      172.16.1.101    261
        224.0.0.0        240.0.0.0         On-link      172.16.200.1    261
  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      172.16.1.101    261
  255.255.255.255  255.255.255.255         On-link      172.16.200.1    261
===========================================================================
Persistent Routes:
  None

— Гунд
джерело

1. Чи виконує маршрутизатор / брандмауер проксі-сервер проксі для вашого внутрішнього адресного простору? 2. Як виглядає таблиця маршрутизації вашого маршрутизатора / брандмауера?

— joeqwerty

Якщо ви хочете не допустити виходу космічних пакетів RFC 1918, просто нульові маршрути 10/8, 172.16 / 12 та 192.168 / 16 (або направляйте їх назад до вашої локальної мережі). Якщо немає спеціальних домовленостей, ці пакети ні в якому разі не повинні входити / виходити з вашої мережі. Хоча я зовсім не впевнений, що це найкращий підхід (це може зламати речі в іншому кінці).

— CVn

З огляду на версії Windows, про які ви говорите, та загальну тональність цієї публікації, я здогадуюсь, що ви знаходитесь у корпоративному середовищі, і в такому випадку ви можете розглянути питання про позначення цієї публікації для уваги модератора та вимагати переходу на серверну помилку .

— CVn

Привіт Майкл, дякую за відповідь. Я додав маршрутизатори для маршрутів 10/8, 172.16 / 12 та 192.168 / 16, щоб повернутися до свого комп'ютера (192.168.0.117), щоб вони не надсилалися через Інтернет. Мені цікаво, чи потрібно це налаштувати кожен маршрутизатор? Також я повинен уточнити, що це моя домашня лабораторія, а не корпоративне чи ділове середовище. Я використовую його лише для вивчення.

— Гунд

Відмова від маршруту за замовчуванням - це нормальна поведінка, оскільки Vista, про це ви можете прочитати у наступній статті: Вибір вихідної IP-адреси на багатоповерховому комп'ютері Windows .

Проблема циклу, викликана неправильно налаштованим маршрутизатором, який надсилає пакети назад, використовуючи різні підмережі, а не скидаючи їх.

— мтм
джерело

Відповіді на посилання стають марними лише в тому випадку, коли посилання знижується. Поясніть, будь ласка, як вирішити проблему, поки ще цитуєте джерело.

— Райстафаріан

Вибачте, додав деякі деталі.

— mtm

Привіт, вибачте за пізню відповідь, але дякую за це посилання MTM! Він описує, чому я бачу саме таку поведінку, і дав мені хороший вихідний пункт для досліджень, що їх змінюють.

— Гунд