☰

¿Linux (4.15.0-130) y Windows (10) tratan ICMP de manera diferente?

tag-icon • tag-icon windows-10 traceroute icmp
¿Linux (4.15.0-130) y Windows (10) tratan ICMP de manera diferente?

Mientras intentaba solucionar problemas de una máquina con Windows 10 con problemas de red erráticos, hice un rastreo de ruta a un host y obtuve resultados algo diferentes de los que veo en mi sistema Ubuntu 18.04 con kernel 4.15.0-130. Para eliminar factores de hardware, pilas de protocolos inestables, problemas de controladores y similares, comparé Windows 10 en una máquina virtual VirtualBox que ejecuta Linux con lo que me proporciona el sistema host. VirtualBox se ha configurado con NAT, es decir, Windows 10 se conecta al host que luego maneja la E/S de la red real. Entonces, ambas sesiones usan el mismo adaptador de red y todo pasa por la misma pila de protocolos en el host. No hay ninguna VPN involucrada; la máquina cliente simplemente está conectada a un enrutador de Internet WiFi/3G.

Se puede acceder al host que estoy rastreando desde Linux (usando el navegador web Firefox) pero no desde Windows 10 (ya sea en la otra máquina con Windows 10 usando Firefox o en VirtualBox usando Chrome).

Windows (ejecutándose en Virtual Box en Linux) me da:

>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.

(Nota: 10.0.2.2 es la dirección de puerta de enlace predeterminada proporcionada por VitualBox; Linux maneja todas las redes a partir de ahí y, por lo tanto, este salto no está presente en la ruta de seguimiento a continuación). Repetir la misma ruta de seguimiento usando Linux (en el mismo sistema que ejecuta Virtual Box sesión con el Windows 10 anterior) me da:

$ 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  * * *
$

¿Qué causa esta diferencia? ¿Es de alguna manera significativa?

Respuesta1

No es la misma ruta de rastreo. En realidad, Linux tracerouteenvía sondas UDP de forma predeterminada, en lugar de ICMP Echo como lo haría Windows. Úselo sudo traceroute --icmppara acercarse algo más a Windows. (Pruébalo mtrmientras lo haces).

Si el sistema final tiene un cortafuegos que descarta silenciosamente paquetes UDP en puertos desconocidos 1 , la falta de respuesta significa que el programa traceroute no tendrá forma de saber adónde fueron y, de hecho, no tendrá forma de reconocer que las sondas finalmente llegaron al final. destino y que no hay necesidad de seguir investigando TTL cada vez más grandes.

1 Lo mismo sucedería con cualquier tipo de sonda traceroute 2 , pero eliminar UDP es mucho más común que eliminar ICMP Echo. (Ni siquiera tiene que ser un bloqueo deliberado; algunos sistemas operativos simplemente lo hacen de forma predeterminada, ignorando UDP e incluso TCP, y permanecen en silencio cuando los estándares exigen un puerto ICMP inalcanzable. A menudo lo llaman "modo oculto" y Afirma que es de alguna manera una característica de seguridad).

2 No existe ningún tipo de paquete dedicado para traceroute; las herramientas simplemente envían lo que pueda producir una respuesta del host final sin confundir ningún servicio real; esto incluye ICMP Echo, pero también paquetes UDP en puertos altos, incluso TCP SYN.

información relacionada