![A rota do Windows 10 continua voltando depois de um tempo sempre que eu a excluo com a exclusão de rota, como posso excluir a rota para sempre?](https://rvso.com/image/1598571/A%20rota%20do%20Windows%2010%20continua%20voltando%20depois%20de%20um%20tempo%20sempre%20que%20eu%20a%20excluo%20com%20a%20exclus%C3%A3o%20de%20rota%2C%20como%20posso%20excluir%20a%20rota%20para%20sempre%3F.png)
Inicialmente eu tinha um raspberry pi/pi2 em minha rede vencendo meu servidor dhcp roteador e servindo IPs e por causa de algumas opções padrão os clientes Windows começaram a receber o endereço IP do servidor dhcp pi2 como seu gateway. Corrigi isso adicionando uma opção específica de roteador de gateway à minha configuração do dhcpd no Raspberry Pi.
Mas, aparentemente, no meu Windows 10pc .200, continuo recebendo essa rota aparentemente manual (independentemente de ser via wifi ou lan) para um dos meus PCs, vamos chamá-lo de 192.168.1.100 com máscara de rede 255.255.255.255 e gateway 192.168.1.50 (endereço pi2)
Então, quando eu faço route print, dá:
192.168.1.100 255.255.255.255 192.168.1.50 192.168.1.200 26
Então, por causa disso, não consigo conectar/ping do meu Windows 10pc para o ip .100
Funcionará depois de eu rotear delete -p 192.168.1.100 mas depois ele se adicionará novamente
interface netsh ipv4 mostrar rota:
No Manual 1 192.168.1.100/32 10 192.168.1.50
Procurei no registro e não vi nenhuma rota persistente lá (Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\PersistentRoutes )
Como posso saber de onde/como essa rota de rede fantasma continua voltando?
ATUALIZAÇÃO: acabei de voltar a usar o PC e novamente descobri que a rota foi adicionada novamente:
192.168.1.100 255.255.255.255 192.168.1.50 192.168.1.200 26
e quando faço arp -a não vejo mais nenhuma entrada para 192.168.1.100 e não consigo executar ping ou conectar-me a .1.100 até que eu o exclua novamente.
Responder1
As rotas /32 podem aparecer devido a um redirecionamento ICMP, se o firewall estiver configurado para aceitá-las.
Dê uma olhada no seu cache ARP usando arp -a
– ele lista o endereço MAC correto próximo a 192.168.1.100? Pode estar apontando para um dispositivo quecostumava ser.1.100, mas não é mais; portanto, quando sua entrada de cache ARP desatualizada direciona os pacotes para lá, o dispositivo com esse endereço MAC redireciona você para o que considera ser o caminho mais correto.
(O "caminho correto" é baseado no que o proprietário do endereço MAC tem como gateway padrão.)