Недавно столкнулся на работе со странной проблемой.
Выездная бригада должна была проверить сеть на объекте, подключив 2 ноутбука (А и B)к разным её частям. Картина предстала следующая:
Естественно, ноутбуки были немедленно соединены напрямую, но ситуация не изменилась. После ping с ноутбука B, он переставал отвечать на ICMP запросы других узлов сети. При этом сам B пинговал и получал ответы от всех исправно.
Бригада справилась и без ноутбуков, которые с виноватым видом вручили мне: «Посмотри. Сломали может чего...»
Забегая вперед, скажу, что проблема была решена, «виновник» найден. Но причины этой проблемы так и остались покрыты мраком…
Конечно же, коллеги, пытаясь решить проблему, отключили, а затем и снесли антивирус с его брандмауэром, отключили встроенный брандмауэр Windows (на обоих ноутбуках стоит 7 Professional) и перелопатили политики безопасности. В Интернет подобная проблема как-то тоже явно не описана (что странно).
Известно, что односторонний ping, как правило, возникает из-за проблем с маршрутизацией. Но тут были два ноутбука с единственными включенными сетевыми адаптерами (wifi и виртуальные сети, конечно же, тоже отключили) соединенные напрямую двумя метрами витой пары… Необходимость ввода в дело тяжёлой артиллерии в виде WireShark стала очевидна через несколько минут. И вот результат:
IP_A = 192.168.1.10, IP_B = 192.168.1.20
Формальная причина «недоступности» ноутбука B выделена жирным шрифтом. Ноутбук начинал отвечать на запросы, искажая поле id в Echo-reply! И утилита ping обосновано считала эти ответы чужими, предназначенными кому-то ещё. Напомню, речь идёт о совершенно стандартном Windows 7 с совершенно стандартным стеком TCP/IPv4 и об обычной утилите ping.
По запросу о возможных причинах такого искажения id (очень похожего на bytes swapping при проблемах с пониманием Little- и Big-Endian) Интернет-таки выдал пару туманных советов смотреть в сторону Windows ICS (Internet connection sharing). Казалось бы, не наш случай — на компьютерах по одному сетевому адаптеру и «расшаривать» их просто некому! Попробуйте ка оставить у себя только одно сетевое соединение и зайти в его свойства. Вы даже не найдёте там вкладки «Доступ», где и включается ICS…
Так вот, причина была всё-таки во включённом ICS на ноутбуке B. Другой сотрудник чуть ли не год назад включал ICS, и, выполнив работу, просто удалил вторую сеть, для которой открывался доступ к основному сетевому адаптеру ноутбука. Вкладка «Доступ» из свойств соединения исчезла, но ICS остался включён. Как этот факт может влиять на искажение Echo-reply да ещё и сугубо после запуска ping на самом проблемном компьютере? На этот вопрос пока ответ только один: может. Если кто-нибудь укажет на философские причины такого поведения ICMP в Windows, буду премного благодарен.
Пока же вывод один: если уж пришлось использовать Windows ICS, отключайте его сразу по окончании работы. Ну, конечно же, если хотите чтоб компьютер корректно отвечал на ICMP-запросы.
Спасибо за внимание!
Выездная бригада должна была проверить сеть на объекте, подключив 2 ноутбука (А и B)к разным её частям. Картина предстала следующая:
A> ping IP_B - успешно
B> ping IP_A - успешно
A> ping IP_B - с этого момента всегда "превышен интервал ожидания"Естественно, ноутбуки были немедленно соединены напрямую, но ситуация не изменилась. После ping с ноутбука B, он переставал отвечать на ICMP запросы других узлов сети. При этом сам B пинговал и получал ответы от всех исправно.
Бригада справилась и без ноутбуков, которые с виноватым видом вручили мне: «Посмотри. Сломали может чего...»
Забегая вперед, скажу, что проблема была решена, «виновник» найден. Но причины этой проблемы так и остались покрыты мраком…
Конечно же, коллеги, пытаясь решить проблему, отключили, а затем и снесли антивирус с его брандмауэром, отключили встроенный брандмауэр Windows (на обоих ноутбуках стоит 7 Professional) и перелопатили политики безопасности. В Интернет подобная проблема как-то тоже явно не описана (что странно).
Известно, что односторонний ping, как правило, возникает из-за проблем с маршрутизацией. Но тут были два ноутбука с единственными включенными сетевыми адаптерами (wifi и виртуальные сети, конечно же, тоже отключили) соединенные напрямую двумя метрами витой пары… Необходимость ввода в дело тяжёлой артиллерии в виде WireShark стала очевидна через несколько минут. И вот результат:
IP_A = 192.168.1.10, IP_B = 192.168.1.20
No. Time Source Destination Protocol Length Info
1 0.000000000 192.168.1.10 192.168.1.20 ICMP 74 Echo (ping) request id=0x0001
2 0.000829000 192.168.1.20 192.168.1.10 ICMP 74 Echo (ping) reply id=0x0001
3 1.000483000 192.168.1.10 192.168.1.20 ICMP 74 Echo (ping) request id=0x0001
4 1.001482000 192.168.1.20 192.168.1.10 ICMP 74 Echo (ping) reply id=0x0001
5 2.000877000 192.168.1.10 192.168.1.20 ICMP 74 Echo (ping) request id=0x0001
6 2.001817000 192.168.1.20 192.168.1.10 ICMP 74 Echo (ping) reply id=0x0001
7 3.001261000 192.168.1.10 192.168.1.20 ICMP 74 Echo (ping) request id=0x0001
8 3.002127000 192.168.1.20 192.168.1.10 ICMP 74 Echo (ping) reply id=0x0001
13 24.140313000 192.168.1.20 192.168.1.10 ICMP 74 Echo (ping) request id=0x0100
14 24.140386000 192.168.1.10 192.168.1.20 ICMP 74 Echo (ping) reply id=0x0100
15 25.145144000 192.168.1.20 192.168.1.10 ICMP 74 Echo (ping) request id=0x0100
16 25.145211000 192.168.1.10 192.168.1.20 ICMP 74 Echo (ping) reply id=0x0100
17 26.148099000 192.168.1.20 192.168.1.10 ICMP 74 Echo (ping) request id=0x0100
18 26.148166000 192.168.1.10 192.168.1.20 ICMP 74 Echo (ping) reply id=0x0100
19 27.151163000 192.168.1.20 192.168.1.10 ICMP 74 Echo (ping) request id=0x0100
20 27.151231000 192.168.1.10 192.168.1.20 ICMP 74 Echo (ping) reply id=0x0100
23 35.536903000 192.168.1.10 192.168.1.20 ICMP 74 Echo (ping) request <b>id=0x0001</b>
24 35.537891000 192.168.1.20 192.168.1.10 ICMP 74 Echo (ping) reply <b>id=0x0100</b>
25 40.179728000 192.168.1.10 192.168.1.20 ICMP 74 Echo (ping) request <b>id=0x0001</b>
26 40.180542000 192.168.1.20 192.168.1.10 ICMP 74 Echo (ping) reply <b>id=0x0100</b>
28 45.181687000 192.168.1.10 192.168.1.20 ICMP 74 Echo (ping) request <b>id=0x0001</b>
29 45.182177000 192.168.1.20 192.168.1.10 ICMP 74 Echo (ping) reply <b>id=0x0100</b>
31 50.185640000 192.168.1.10 192.168.1.20 ICMP 74 Echo (ping) request <b>id=0x0001</b>
32 50.186516000 192.168.1.20 192.168.1.10 ICMP 74 Echo (ping) reply <b>id=0x0100</b>1-8 это ping A->B
13-20 - ping B->A
23-32 снова ping A->BФормальная причина «недоступности» ноутбука B выделена жирным шрифтом. Ноутбук начинал отвечать на запросы, искажая поле id в Echo-reply! И утилита ping обосновано считала эти ответы чужими, предназначенными кому-то ещё. Напомню, речь идёт о совершенно стандартном Windows 7 с совершенно стандартным стеком TCP/IPv4 и об обычной утилите ping.
По запросу о возможных причинах такого искажения id (очень похожего на bytes swapping при проблемах с пониманием Little- и Big-Endian) Интернет-таки выдал пару туманных советов смотреть в сторону Windows ICS (Internet connection sharing). Казалось бы, не наш случай — на компьютерах по одному сетевому адаптеру и «расшаривать» их просто некому! Попробуйте ка оставить у себя только одно сетевое соединение и зайти в его свойства. Вы даже не найдёте там вкладки «Доступ», где и включается ICS…
Так вот, причина была всё-таки во включённом ICS на ноутбуке B. Другой сотрудник чуть ли не год назад включал ICS, и, выполнив работу, просто удалил вторую сеть, для которой открывался доступ к основному сетевому адаптеру ноутбука. Вкладка «Доступ» из свойств соединения исчезла, но ICS остался включён. Как этот факт может влиять на искажение Echo-reply да ещё и сугубо после запуска ping на самом проблемном компьютере? На этот вопрос пока ответ только один: может. Если кто-нибудь укажет на философские причины такого поведения ICMP в Windows, буду премного благодарен.
Пока же вывод один: если уж пришлось использовать Windows ICS, отключайте его сразу по окончании работы. Ну, конечно же, если хотите чтоб компьютер корректно отвечал на ICMP-запросы.
Спасибо за внимание!