Односторонний ping в Windows

Недавно столкнулся на работе со странной проблемой.

Выездная бригада должна была проверить сеть на объекте, подключив 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-запросы.

Спасибо за внимание!

Автор: Жрец

Источник ^[1]