☰

Обрабатывают ли Linux (4.15.0-130) и Windows (10) ICMP по-разному?

tag-icon • tag-icon windows-10 traceroute icmp
Обрабатывают ли Linux (4.15.0-130) и Windows (10) ICMP по-разному?

Пытаясь устранить неполадки на машине с Windows 10 с нестабильными сетевыми проблемами, я выполнил трассировку маршрута к хосту и получил несколько иные результаты, чем те, что я вижу на своей системе Ubuntu 18.04 с ядром 4.15.0-130. Чтобы исключить факторы оборудования, ненадежные стеки протоколов, проблемы с драйверами и тому подобное, я затем сравнил Windows 10 в виртуальной машине VirtualBox под управлением Linux с тем, что дает мне хост-система. VirtualBox был настроен с NAT, т. е. Windows 10 подключается к хосту, который затем обрабатывает фактический сетевой ввод-вывод. Таким образом, оба сеанса используют один и тот же сетевой адаптер, и все проходит через один и тот же стек протоколов на хосте. VPN не задействован; клиентская машина просто висит на маршрутизаторе WiFi/3G Internet.

К хосту, маршрутизацию которого я отслеживаю, можно получить доступ из Linux (с помощью веб-браузера Firefox), но не из Windows 10 (ни с другого компьютера с Windows 10 с помощью Firefox, ни в VirtualBox с помощью Chrome).

Windows (запущенная в Virtual Box на Linux) выдает мне:

>tracert -d www.brewforafrica.co.za

Tracing route to www.brewforafrica.co.za [41.203.18.81]
over a maximum of 30 hops:

  1    <1 ms     1 ms    <1 ms  10.0.2.2
  2     3 ms     3 ms     3 ms  192.168.0.1
  3    56 ms    23 ms    36 ms  10.113.42.52
  4    83 ms    31 ms    22 ms  10.251.60.253
  5     *        *        *     Request timed out.
  6    74 ms    34 ms    29 ms  10.251.60.233
  7    88 ms    39 ms    20 ms  10.251.60.234
  8     *      103 ms    39 ms  10.113.145.33
  9    25 ms    33 ms    24 ms  196.207.35.36
 10    82 ms    32 ms    43 ms  192.168.133.110
 11    54 ms    25 ms    42 ms  41.21.235.25
 12    69 ms    80 ms    62 ms  10.118.24.61
 13   103 ms    35 ms    35 ms  196.60.9.24
 14    46 ms    45 ms    53 ms  197.189.193.1
 15    95 ms    53 ms    35 ms  41.203.18.81

Trace complete.

(Примечание: 10.0.2.2 — это адрес шлюза по умолчанию, предоставляемый VitualBox; Linux обрабатывает все сетевые соединения с этого момента, и поэтому этот переход отсутствует в трассировке ниже.) Повторение той же трассировки с использованием Linux (на той же системе, где запущен сеанс Virtual Box с указанной выше Windows 10) дает мне:

$ traceroute -n www.brewforafrica.co.za

traceroute to www.brewforafrica.co.za (41.203.18.81), 30 hops max, 60 byte packets
 1  192.168.0.1  1.416 ms  1.580 ms  1.668 ms
 2  10.113.42.52  24.311 ms  25.119 ms  38.804 ms
 3  10.251.60.253  39.793 ms  39.875 ms  39.922 ms
 4  * * *
 5  10.251.60.233  40.122 ms  41.365 ms  51.445 ms
 6  10.251.60.234  51.910 ms  50.416 ms  50.508 ms
 7  10.113.145.33  50.836 ms  27.691 ms  27.251 ms
 8  196.207.35.36  31.254 ms  73.984 ms  63.871 ms
 9  192.168.133.110  73.479 ms  73.528 ms  62.612 ms
10  41.21.235.25  52.088 ms  61.699 ms  61.572 ms
11  10.118.24.61  62.102 ms  62.275 ms  61.833 ms
12  196.60.9.24  61.680 ms  51.679 ms  39.123 ms
13  197.189.193.1  40.032 ms  40.073 ms  43.791 ms
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
$

Чем вызвана эта разница и имеет ли она хоть какое-то значение?

решение1

Это не тот же traceroute. Linux tracerouteна самом деле отправляет UDP-пробы по умолчанию, а не ICMP Echo, как это делает Windows. Используйте, sudo traceroute --icmpчтобы приблизиться к Windows. (Попробуйте, mtrпока вы этим занимаетесь.)

Если в конечной системе установлен брандмауэр, который тихо отбрасывает пакеты UDP на неизвестных портах 1 , отсутствие ответа означает, что программа traceroute не сможет узнать, куда они отправились, и, более того, не сможет распознать, что зонды наконец достигли конечного пункта назначения и что нет необходимости продолжать зондировать все большие и большие значения TTL.

1 То же самое произойдет с любым видом traceroute-пробы 2 , но отбрасывание UDP встречается гораздо чаще, чем отбрасывание ICMP Echo. (Это даже не обязательно должна быть преднамеренная блокировка — некоторые операционные системы просто делают это по умолчанию, игнорируя UDP и даже TCP, оставаясь незамеченными, когда стандарты требуют ICMP Port Unreachable. Они часто называют это «скрытым режимом» и утверждают, что это своего рода функция безопасности.)

2 Для traceroute не существует специального типа пакета; инструменты просто отправляют то, что с большой вероятностью вызовет ответ от конечного хоста, не вмешиваясь в работу реальных служб — сюда входят ICMP Echo, а также пакеты UDP на высоких портах и ​​даже пакеты TCP SYN.

Связанный контент