☰

Windows 10 ignora la tabla de enrutamiento

tag-icon • tag-icon windows routing static-routes
Windows 10 ignora la tabla de enrutamiento

Tengo una PC con Windows 10 que tiene 2 interfaces de red. Una de esas interfaces va a la LAN principal donde se encuentran el servidor de archivos, el DNS y el enrutador de Internet. La segunda interfaz es una pequeña LAN que tiene un PLC y una HMI. Ambos están físicamente en la misma LAN pero en subredes diferentes (lo siento, no puedo cambiar eso, está fuera de mi control).

Entonces tengo dos interfaces físicas y una lógica: eth0: DHCP, 172.16.xy, MASK 255.255.255.0, gw predeterminado 172.16.xz eth1: static 192.168.1.158, MASK 255.255.255.0 static 192.168.19.158, MASK 255.2 55.255.0

Se puede acceder a la HMI en 192.168.19.135

Ahora, cuando reinicio la HMI, inicio un ping para ver cuándo se puede acceder a ella nuevamente. Esto debería suceder después de unos 30 años. Pero sólo recibo una respuesta de ping positiva después de 80-90 segundos.

Ping wird ausgeführt für 192.168.19.135 mit 32 Bytes Daten:
Antwort von 192.168.19.158: Zielhost nicht erreichbar.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

(Perdón por el texto en alemán, pero creo que aún debería quedar claro lo que vemos aquí). Recibo otra respuesta para el primer ping que para el segundo.

Parece que Windows después de XP comenzó a hacer algo de "magia de enrutamiento" y simplemente envía datos por la ruta predeterminada si no puede alcanzar el objetivo en una ruta más específica. Parece que otros también han tenidoeste problema

Encontré algunas "soluciones" que no son soluciones reales para mí (más sobre eso a continuación)

  1. Entonces ping tiene un bonito parámetro "-S" para definir la dirección de origen. Y sí, esto "resuelve" el problema. Recibo una respuesta instantánea si la HMI está activa. Pero estoy usando ese comando en un script de PowerShell y el parámetro de origen para "probar conexión" tiene un significado completamente diferente. Y como uso esto en un script, esto falla tan pronto como cambia la IP local.
  2. Configuré eth0 estáticamente en lugar de mediante DHCP y no definí una ruta predeterminada. Esto también "resolvió" el problema (creo que puedes imaginar por qué esto no es realmente una solución)
  3. Solo he explorado esto en teoría, pero podría instalar un enrutador basado en Linux con 3 interfaces entre la PC, la LAN y la LAN aislada con el PLC y la HMI y dejar que haga todo el enrutamiento (¡esto seguramente resolvería el problema! Pero, sinceramente, ¿necesito una computadora adicional sólo para solucionar el enrutamiento de ventanas rotas?)
  4. ´arp -d *´ parece ayudar también, pero necesita privilegios elevados

Intenté agregar rutas estáticas con diferentes parámetros y métricas. ¡Ningún cambio! Agregar la MAC de la HMI estáticamente no ayuda ya que esta MAC puede cambiar.

Entonces mis preguntas son:

  1. ¿Existe alguna documentación sobre este cambio de comportamiento en Windows?
  2. ¿Hay alguna manera de forzar a Windows a usar la interfaz definida?

Respuesta1

Entonces, después de no encontrar una solución fácil, decidí programar para solucionar el problema que Microsoft ha creado al estropear gravemente el enrutamiento en Windows.

Ya no uso el ping clásico con el parámetro -S en lugar del cmdlet test-connection en powershell

la parte ping de mi código ahora se ve así:

$localIPs = (Get-NetIPConfiguration -InterfaceAlias "PLC").IPv4Address.IPAddress

# because this command returns a string, when the interface has a single IP-address but an array of strings if the interface has more than one address, we need to check for this
if ($localIPs.GetType().Name -eq "string") { # only a single IP
  $localIP = $localIPs
}
else { # more than one IP
  $localIP = $localIPs[0] # since it seems that windows does use the ip address as a synonym for the interface, it's not important which of the addresses of that interface we use. So we're just picking the first one
}

$pingcount = 180

do {
  ping $HMI4IP -n 1 -w 1000 -S $localIP | Out-Null # redirect the output of ping to /dev/null
  $pingreply = $?
  $pingcount = $pingcount - 1
}
until ($pingcount -eq '0' -or $pingreply)
if ($pingreply) {
  # code here
}
else {
  exit 1337 # return with an error code, we've not reached our target
}

Para esto solo necesito asegurarme que la interfaz donde están conectados el PLC y el HMI se llame "PLC". Luego obtengo la dirección como una cadena o una matriz de direcciones (dependiendo de si la interfaz tiene una o más direcciones) que tengo que manejar (bienvenido a la escritura dinámica...). Entonces es tan fácil como enviar estos datos para hacer ping (porque Test-Connection intenta ser demasiado inteligente para su propio bien). ¿En dólares? Obtengo verdadero si el último comando devolvió un éxito y falso si fue un error. Entonces eso es fácil de manejar a partir de ahí.

Hasta donde puedo ver, no hay documentación de Microsoft sobre este comportamiento y cómo manejarlo, lo cual creo que es bastante triste.

información relacionada