☰

Windows 10 ignorando tabela de roteamento

tag-icon • tag-icon windows routing static-routes
Windows 10 ignorando tabela de roteamento

Eu tenho um PC com Windows 10 que possui 2 interfaces de rede. Uma dessas interfaces vai para a LAN principal onde estão localizados o servidor de arquivos, o DNS e o roteador da internet. A segunda interface é uma pequena LAN que possui um PLC e uma IHM. Ambos estão fisicamente na mesma LAN, mas em sub-redes diferentes (desculpe, não posso mudar isso, fora do meu controle).

Portanto, tenho duas interfaces físicas e uma lógica: eth0: DHCP, 172.16.xy, MASK 255.255.255.0, padrão gw 172.16.xz eth1: static 192.168.1.158, MASK 255.255.255.0 static 192.168.19.158, MASK 255.255.2 55,0

A IHM pode ser acessada em 192.168.19.135

Agora, quando reinicio a HMI, inicio um ping para ver quando ela está acessível novamente. Isso deve acontecer depois dos 30 anos. Mas só recebo uma resposta de ping positiva depois dos 80-90 anos.

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.

(desculpe pelo texto em alemão, mas acho que ainda deve ficar claro o que vemos aqui) Recebo outra resposta para o primeiro ping do que para o segundo.

Parece que o Windows depois do XP começou a fazer alguma "mágica de roteamento" e apenas enviar dados pela rota padrão se não conseguir atingir o alvo em uma rota mais específica. Parece que outros também tiverameste problema

Encontrei algumas "soluções" que não são soluções reais para mim (mais sobre isso abaixo)

  1. Portanto, o ping possui um bom parâmetro "-S" para definir o endereço de origem. E sim, isso “resolve” o problema. Recebo uma resposta instantaneamente se a IHM estiver ativa. Mas estou usando esse comando em um script do PowerShell e o parâmetro de origem para "test-connection" tem um significado completamente diferente. E como eu uso isso em um script, ele falha assim que o IP local muda.
  2. Configurei eth0 estaticamente em vez de DHCP e não defini uma rota padrão. Isso também "resolveu" o problema (acho que você pode imaginar por que isso não é realmente uma solução)
  3. Eu só explorei isso teoricamente, mas eu poderia instalar um roteador baseado em Linux com 3 interfaces entre o PC, a LAN e a LAN isolada com o PLC e a HMI e deixar ele fazer todo o roteamento (isso com certeza resolveria o problema! Mas, honestamente, preciso de um computador adicional apenas para contornar o roteamento de janelas quebradas?)
  4. ´arp -d *´ parece ajudar também, mas precisa de privilégios elevados

Tentei adicionar rotas estáticas com diferentes parâmetros e métricas. Nenhuma mudança! Adicionar o MAC da HMI estaticamente não ajuda, pois esse MAC pode mudar.

Então minhas perguntas são:

  1. existe alguma documentação sobre essa mudança de comportamento no Windows?
  2. existe uma maneira de forçar o Windows a usar a interface definida

Responder1

Então, depois de não encontrar uma solução fácil, decidi programar meu caminho para contornar o problema que a Microsoft criou ao bagunçar gravemente o roteamento no Windows.

Estou usando o ping clássico com o parâmetro -S em vez da conexão de teste do cmdlet no PowerShell

a parte ping do meu código agora se parece com isto:

$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 isso basta ter certeza de que a interface onde o CLP e a IHM estão conectados tem o nome "PLC". Então obtenho o endereço como uma string ou uma matriz de endereços (dependendo se a interface possui um ou mais endereços) que devo manipular (bem-vindo à digitação dinâmica...). Então é tão fácil quanto alimentar esses dados para o ping (porque o Test-Connection tenta ser muito inteligente para seu próprio bem). Em $? Eu entendo que o último comando retornou um sucesso e falso se foi uma falha. Então é fácil lidar com isso a partir daí.

Pelo que posso ver, não há documentação da Microsoft sobre esse comportamento e como lidar com ele, o que considero bastante triste.

informação relacionada