Примечание. Это лаборатория моего домашнего компьютера, а не бизнес-среда. Я более чем счастлив сломать и исправить это снова, поэтому любые предложения приветствуются!
РЕЗЮМЕ
Я добавил это краткое резюме, потому что этот вопрос становится довольно длинным. Если вам нужна дополнительная информация о таблицах маршрутизации, IP-конфигурациях и т. Д., Смотрите ниже.
У меня есть несколько сетевых карт на компьютере. Один 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, но мне любопытно, можно ли это остановить.
Я создал виртуальную машину Ubuntu с той же конфигурацией, что и мои виртуальные машины Windows - виртуальная машина Ubuntu не использует маршрут по умолчанию, как виртуальные машины Windows. Я добавил таблицы маршрутизации и результаты для Ubuntu VM и Windows 8.1 VM внизу этого поста.
ДАЛЬНЕЙШИЕ ПОДРОБНОСТИ
Я сделал обширный поиск по этому вопросу , и самый близкий вопрос , который я видел здесь: Routing цикл: TTL истек в пути , но , к сожалению, не дает ответ , как остановить эту проблему или изменить поведение на компьютере. Ответ предлагает исправить маршрутизацию. Я могу изменить свой маршрутизатор, чтобы отбрасывать все, что предназначено для частных IP-адресов (или перенаправлять его на IP-адреса моих соседей по дому, хе-хе-хе), но это не изменит поведение моего компьютера. (Я также прочитал большое руководство по подсетям, которое было ссылкой в исходном ответе, которое можно найти по адресу /server/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 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 - его отключение и даже удаление ничего не сделали. Кроме того, я создал совершенно новую виртуальную машину 2008 R2 R2, предоставил ей две сетевые карты, одну непосредственно в сети 192.168.0.0, а другую в сети 172.16.200.0, и она сделала то же самое ... Надеюсь, вы можете сказать, что я потратил немного времени на это.
Я настроил свой домашний маршрутизатор на пересылку всего 172.16.XX обратно на свой компьютер, но это обходной путь…
Я что-то пропустил? Возможно, что-то очевидное? Я спрашиваю о невозможном?
[ОБНОВЛЕНИЕ № 1 И № 2]
Я перебрал каждый бит конфигурации на моем маршрутизаторе, и он, похоже, не обрабатывает запросы прокси ARP - у него даже нет никаких настроек, которые я могу видеть.
Я использовал MS Network Monitor 3.4, чтобы проверить, отвечает ли на запросы ARP маршрутизатор, а они нет. Я вижу, что запрос ARP отправляется, когда я пытаюсь пропинговать несуществующий хост, и я не получаю никаких ответов ARP. Пинг хоста, который существует, естественно, дает мне ответ 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 - Добавлены таблицы маршрутизации виртуальных машин Ubuntu и Win8.1]
Итак, я создал совершенно новую Ubuntu VM и совершенно новую Windows 8.1 VM. Виртуальная машина Ubuntu не пытается вернуться к маршруту 0.0.0.0, но Windows 8.1 делает это. Я попробовал старый ping-a-non-existant-host и наблюдал за трафиком на маршрутизаторе 172.16.1.1. Он получает запросы ICMP от виртуальной машины Windows 8.1 и передает их, но никогда не видит трафика ICMP от виртуальной машины Ubuntu.
Таблица виртуальных машин Ubuntu находится ниже:
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
Ответы:
Откат к маршруту по умолчанию является нормальным поведением начиная с Vista, об этом вы можете прочитать в следующей статье: Выбор исходного IP-адреса на многосетевом компьютере Windows .
Проблема петли, вызванная неправильно настроенным маршрутизатором, который отправляет пакеты обратно, используя другую подсеть, а не отбрасывает их.
источник