¿Cómo alterar el comportamiento de la dirección de difusión global (255.255.255.255) en Windows?

Comportamiento deseado

Cuando una aplicación envía un paquete a la dirección IP de transmisión global 255.255.255.255, me gustaría que el paquete se envíe a la dirección de transmisión global Ethernet ( ff:ff:ff:ff:ff:ff), en todas las interfaces.

En Linux y probablemente también en otros sistemas operativos, esto parece funcionar. Windows XP y Windows 7 exhiben comportamientos diferentes al respecto, y ninguno de estos comportamientos es deseable para mi situación.

Comportamiento de Windows XP

El paquete se enviará correctamente a la primera interfaz de red (el orden de la interfaz se especifica en "Conexiones de red / Configuración avanzada / avanzada"). También se enviará a las otras interfaces.

Todo está bien hasta ahora. El problema es que, al enviar a las otras interfaces, la dirección de origen del paquete de difusión es la dirección IP de la primera interfaz. Por ejemplo, imagine esta configuración de red (el orden es importante):

Adaptador 1: dirección IP 192.168.0.1
Adaptador 2: dirección IP 10.0.0.1
Adaptador 3: dirección IP 172.17.0.1

Ahora, si envío un paquete de difusión, se enviarán los siguientes paquetes (con las direcciones IP de origen y de destino):

En el adaptador 1: 192.168.0.1=>255.255.255.255
En el adaptador 2: 192.168.0.1=>255.255.255.255
En el adaptador 3: 192.168.0.1=>255.255.255.255

En la práctica, las aplicaciones que usan paquetes de difusión no funcionarán en ninguna interfaz que no sea el adaptador 1. En mi opinión, este es un error evidente en la pila TCP / IP de Windows XP.

Comportamiento de Windows 7

La modificación del orden de la interfaz de red no parece tener ningún efecto en Windows 7. En cambio, la transmisión parece estar controlada por la tabla de rutas IP.

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0   10.202.254.254       10.202.1.2    286
          0.0.0.0          0.0.0.0      192.168.0.1      192.168.0.3     10
       10.202.0.0      255.255.0.0         On-link        10.202.1.2    286
       10.202.1.2  255.255.255.255         On-link        10.202.1.2    286
   10.202.255.255  255.255.255.255         On-link        10.202.1.2    286
        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
      192.168.0.0    255.255.255.0         On-link       192.168.0.3    266
      192.168.0.3  255.255.255.255         On-link       192.168.0.3    266
    192.168.0.255  255.255.255.255         On-link       192.168.0.3    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.3    266
        224.0.0.0        240.0.0.0         On-link        10.202.1.2    286
  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.3    266
  255.255.255.255  255.255.255.255         On-link        10.202.1.2    286
===========================================================================

Ver las 255.255.255.255rutas? Sí, controlan los paquetes de transmisión. En esta situación, los paquetes de difusión se enviarán a través de 192.168.0.3porque tiene la métrica más baja ... pero no a las otras interfaces.

Puede cambiar la interfaz a través de la cual los paquetes de difusión global se enviarán muy fácilmente (simplemente agregue una 255.255.255.255ruta persistente con una métrica baja). Pero no importa cuánto lo intentes, los paquetes de difusión solo se enviarán en una sola interfaz, no todos como me gustaría que lo haga.

Conclusión

Windows 7 solo envía paquetes de difusión a una interfaz. Puedes elegir cuál, pero ese no es el punto aquí.
Windows XP envía paquetes de difusión a todas las interfaces, pero solo los envía como se espera a una interfaz, lo que en la práctica es equivalente al comportamiento de Windows 7.

La meta

Quiero cambiar esta compatibilidad global de transmisión IP en Windows (preferiblemente Windows 7) de una vez por todas. Por supuesto, la mejor manera sería tener algún tipo de cambio de configuración compatible (pirateo del registro o similar), pero estoy abierto a todas las sugerencias.

¿Algunas ideas?

— Etienne Dechamps
fuente

¿Qué estás usando para generar estas transmisiones? No puedo hacer que mi pila de XP haga nada más que transmisiones dirigidas. es decir, 10.202.255.255 en su caso.

— Scott Lundberg, el

¿Puede hacer referencia a un RFC u otro documento que indique el comportamiento correcto que describe? Si bien estoy de acuerdo con su comportamiento deseado, llamarlo comportamiento correcto debería hacer referencia a una especificación que define lo que es correcto. ¿Podría ser que la implementación de enrutamiento específica se deja al proveedor (Microsoft en este caso)?

— Jason R. Coombs

Scott Lundberg: muchas aplicaciones (especialmente juegos) enviarán difusión global. Puede generar algunos usando netcat: "nc -v -u 255.255.255.255 5000" por ejemplo.

— Etienne Dechamps

Jason R. Coombs: de hecho, tal vez tuve una mala elección de palabras. Debería haber usado "comportamiento deseable". No creo que haya un RFC para esto, pero puedo estar equivocado.

— Etienne Dechamps

¿Estás enviando un paquete TCP o UDP? De acuerdo con esto, lo que importa es social.msdn.microsoft.com/Forums/en/peertopeer/thread/… .

— Nissan Fan

Respuestas:

No es que esté en el negocio de defender a Microsoft, pero después de leer las siguientes RFC que intentan definir cómo funcionan las transmisiones, no creo que Microsoft esté necesariamente violando ninguna RFC. En mi opinión, el problema debe solucionarse a nivel de aplicación (es decir, transmisiones dirigidas, no globales) que alcanzarán las rutas apropiadas en la tabla de enrutamiento y solo se enviarán desde la interfaz correcta para esa red IP.

Ambos afirman que no hay un estándar definido para las transmisiones. También menciona en 919 que se debe seleccionar una interfaz física específica para la transmisión. En el caso de una máquina multi-homed, multi-NIC que genera la transmisión, no creo que se indique claramente lo que debería suceder. Se supone que las transmisiones nunca deben ser transmitidas por enrutadores de una interfaz a otra, entonces, ¿es la máquina Windows un enrutador o no en este caso?
Si está actuando como un enrutador, cualquier host que responda a la transmisión con la dirección IP incorrecta para esa red (adaptadores 2 y 3 en su ejemplo) debe enviar el paquete a la dirección de Ethernet de los adaptadores 2 y 3 en respuesta al adaptador La dirección IP de 1 y el host de Windows deben enrutarlo a la interfaz adecuada.
Eso suena confuso ... pero no se me ocurre una mejor manera de expresar esto

Y finalmente, RFC 919 dice específicamente de RFC 919

Dado que suponemos que el problema ya se ha resuelto en la capa de enlace de datos, un host IP que desee
enviar una transmisión local o una transmisión dirigida solo necesita
especificar la dirección de destino apropiada y enviar el datagrama como de
costumbre. Cualquier algoritmo sofisticado solo necesita residir en puertas de enlace.

Una lectura que sugiera que la dirección IP de origen es irrelevante para una transmisión.

Dado que cada aplicación parece manejar las transmisiones de manera diferente, creo que ahí es donde reside la responsabilidad. Por ejemplo. nbtstatenvía transmisiones dirigidas en máquinas con múltiples NIC, mientras que los juegos pueden usar transmisiones globales.
En resumen, la aplicación debe ser reparada, no el sistema operativo en este caso ...

EDITAR: Aquí hay un enlace para las mismas circunstancias, pero en Linux. El kernel de Linux lo maneja enviando solo un paquete a la interfaz predeterminada (NIC A en este ejemplo). Recomiendan que la aplicación enumere las NIC y envíe una transmisión dirigida a cada NIC. Enlace

— Scott Lundberg
fuente

No entiendo la relación entre el párrafo que está citando del RFC 919 y la dirección de origen. Me parece obvio que siempre es incorrecto enviar un paquete IP en una interfaz con la dirección de origen de otra interfaz, independientemente de la naturaleza de difusión / unidifusión del paquete. Quiero decir, no se puede decir razonablemente "la dirección IP de origen es irrelevante para una transmisión", ¡por supuesto que sí! ¿De qué otra manera se supone que las aplicaciones saben quién envió la transmisión?

— Etienne Dechamps

"También menciona en 919 que se debe seleccionar una interfaz física específica para la transmisión". ¿Dónde? "La dirección 255.255.255.255 denota una transmisión en una red de hardware local" (RFC919 7.)? En ese caso, estoy respetuosamente en desacuerdo. Estamos discutiendo qué hacer con las transmisiones a nivel de host, no a nivel de red. Además, justo debajo se dice que un host puede "transmitir a todos sus vecinos inmediatos utilizando 255.255.255.255". Todos sus vecinos inmediatos. No "todos los vecinos en una interfaz de red específica".

— Etienne Dechamps

"A las aplicaciones no les importa qué interfaz envió la transmisión. Solo necesitan responder". Huh ... también necesitan enviar transmisiones, no solo responderles. Considere el caso de un navegador de servidor de juegos LAN. Envía paquetes de difusión para descubrir servidores de juegos en la red. Si los paquetes de difusión no se envían a todas las interfaces, el navegador del servidor de juegos no mostrará los servidores de juegos accesibles a través de estas interfaces. En otras palabras, el fracaso épico.

— Etienne Dechamps

"No estoy seguro, pero creo que el sistema operativo está viendo la solicitud 255.255.255.255 y dice que necesita enviar eso en todas las interfaces (para encontrar todos los vecinos inmediatos), pero se solicitó desde una aplicación específica, vinculada a un IP específica (puede ser predeterminada según la métrica) ". Estoy de acuerdo. Eso no significa que sea lo correcto. En mi opinión, viola completamente el principio de la menor sorpresa desde el punto de vista del desarrollador de la aplicación, que solo espera que el paquete se envíe a todos en todas las interfaces.

— Etienne Dechamps

No estoy seguro de lo que quieres decir con duplicado. Los RFC prohíben específicamente el reenvío de paquetes de difusión. Solo debería enviarse un paquete, que creo que es el quid de nuestra discusión. Si el sistema operativo hiciera lo que usted dice, en realidad tendría que generar 9 paquetes en total (3 para cada interfaz) porque la capa de IP tendría que generar tres paquetes con IP de origen separadas (una para cada NIC en la capa 3) y luego cada NIC tendría que enviarlos a través de Ethernet (capa 2). Si hubiera rutas entre redes, ¡obtendrá 3 respuestas! ¿Cuál es la correcta?

— Scott Lundberg, el

Finalmente, lo resolví programáticamente. Escribí un software muy pequeño llamado WinIPBroadcast que se encarga de transmitir las tramas de difusión a todas las interfaces.

Funciona utilizando un hecho interesante: es posible recibir paquetes de difusión global generados localmente cuando se escucha en la dirección de bucle invertido (127.0.0.1). WinIPBroadcast escucha en la dirección local todas las transmisiones utilizando sockets RAW, luego, para cada paquete de difusión, lo transmite a todas las interfaces, excepto a la preferida.

— Etienne Dechamps
fuente

Como la pila de Windows es una bifurcación de la pila BSD, tengo curiosidad por saber si BSD exhibe el mismo comportamiento.

— x0n

Tu software no funciona. The program can't start becuase api-ms-win-core-rtlsupport-l1-2-0.dll is missing from your computer.. Buena suerte encontrando eso .dllen Google.

— Alex G

@AlexG: eso es extraño, pensé que había solucionado ese problema a través de github.com/dechamps/WinIPBroadcast/commit/… . ¿Estás seguro de que estás ejecutando la última versión (1.6)? Siéntase libre de presentar un error en github.com/dechamps/WinIPBroadcast/issues y lo echaré un vistazo.

— Etienne Dechamps