Nota: Este es el laboratorio de computación de mi casa y no un entorno comercial / de producción. Estoy más que feliz de romperlo y arreglarlo nuevamente, así que cualquier sugerencia es bienvenida.
RESUMEN
He agregado este resumen rápido porque esta pregunta se está haciendo bastante larga. Si desea más detalles sobre las tablas de enrutamiento, configuraciones de IP, etc., consulte a continuación.
Tengo algunas NIC en una computadora. Una NIC es 172.16.200.1 / 24. Cuando intento hacer ping a 172.16.200.2 (un host que existe en la red), recibo una respuesta. Hasta aquí todo bien.
Cuando trato de conectarme a 172.16.200.5 (o cualquier otro host que no exista), la computadora volverá a mi ruta predeterminada (0.0.0.0 a través de mi puerta de enlace predeterminada 192.168.0.1); esto será enviado por mi enrutador doméstico donde luego se pierde en un bucle de enrutamiento en la red de mi ISP. A continuación se brindan muchos más detalles si es necesario, pero supongo que hay un gurú que ya puede responder esto ...
Mi pregunta es:
¿Cómo puedo evitar que mi computadora vuelva a la puerta de enlace predeterminada para una red privada cuando no hay respuesta de un host en esa red? Estas redes privadas ya tienen rutas explícitas con métricas más bajas.
He probado esto en algunas máquinas (Server 2008 R2, Windows 7, Hyper-V Server 2012 R2, Windows Server 2012) y todas se comportan de la misma manera. Estoy empezando a aceptar que este es un "comportamiento normal" para las máquinas con Windows, pero tengo curiosidad por saber si se puede detener.
He creado una máquina virtual de Ubuntu con la misma configuración que mis máquinas virtuales de Windows: la máquina virtual de Ubuntu no vuelve a la ruta predeterminada como lo hacen las máquinas virtuales de Windows. He agregado las tablas de enrutamiento y los resultados para la VM de Ubuntu y la VM de Windows 8.1 al final de esta publicación.
MÁS DETALLES
He realizado una búsqueda exhaustiva sobre este tema y la pregunta más cercana que he visto está aquí: Bucle de enrutamiento: TTL expiró en tránsito , pero desafortunadamente no responde cómo detener el problema o alterar el comportamiento en la computadora. La respuesta sugiere arreglar la ruta. Puedo cambiar mi enrutador para dejar todo destinado a direcciones IP privadas (o reenviarlo a las direcciones IP de mis compañeros, jejeje), pero eso no cambiará el comportamiento de mi computadora. (También he leído la gran guía de subredes que fue referencia en la respuesta original, que se puede encontrar en /server/49765/how-does-ipv4-subnetting-work )
Tengo problemas para entender por qué mis computadoras intentarán conectarse a direcciones IP privadas a través de Internet una vez que hayan intentado usar sus adaptadores internos (durante un período breve) y luego hayan fallado; por ejemplo, al intentar hacer ping a un host que conozco no existe en mi red ...
Pinging 172.16.200.32 with 32 bytes of data:
Reply from 172.16.200.1: Destination host unreachable.
Reply from 203.29.XXX.YY: TTL expired in transit.
Reply from 203.29.XXX.YY: TTL expired in transit.
Reply from 203.29.XXX.YY: TTL expired in transit.
Ping statistics for 172.16.200.32:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Pero hacer ping a un host que existe funciona ...
Pinging 172.16.200.2 with 32 bytes of data:
Reply from 172.16.200.2: bytes=32 time<1ms TTL=128
Reply from 172.16.200.2: bytes=32 time<1ms TTL=128
Reply from 172.16.200.2: bytes=32 time<1ms TTL=128
Reply from 172.16.200.2: bytes=32 time<1ms TTL=128
Ping statistics for 172.16.200.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Aceptar, por lo que la respuesta de 172.16.200.1 está diciendo mi equipo no se recibió ninguna respuesta ... pero entonces, ¿por qué incluso intentar conectarse a través de mi conexión a Internet? Tengo 4 NIC y estoy en la red 172.16.200.0 / 24 en uno de ellos ...
Ethernet adapter HyperV External (built in):
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::582c:97
IPv4 Address. . . . . . . . . . . : 172.16.1.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Ethernet adapter Expansion-2 (middle) HomeNetwork:
Connection-specific DNS Suffix . : Home
IPv4 Address. . . . . . . . . . . : 192.168.0.117
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.1
Ethernet adapter Expansion-3 (bottom) iSCSI-1 :
Connection-specific DNS Suffix . :
IPv4 Address. . . . . . . . . . . : 172.16.100.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Ethernet adapter Expansion-1 (top) iSCSI-2:
Connection-specific DNS Suffix . :
IPv4 Address. . . . . . . . . . . : 172.16.200.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Entonces, en este punto, tendría sentido mirar la tabla de enrutamiento ...
===========================================================================
Interface List
16...64 70 02 00 1f 03 ......Gigabit PCI Express Network Adapter #2
15...64 70 02 00 40 48 ......Gigabit PCI Express Network Adapter
23...00 24 1d 1d f8 35 ......TST Onboard
17...64 70 02 00 32 c1 ......Gigabit PCI Express Network Adapter #3
1...........................Software Loopback Interface 1
28...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
26...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
13...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
27...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3
29...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #4
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.117 410
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
172.16.1.0 255.255.255.0 On-link 172.16.1.1 266
172.16.1.1 255.255.255.255 On-link 172.16.1.1 261
172.16.1.255 255.255.255.255 On-link 172.16.1.1 261
172.16.100.0 255.255.255.0 On-link 172.16.100.1 266
172.16.100.1 255.255.255.255 On-link 172.16.100.1 266
172.16.100.255 255.255.255.255 On-link 172.16.100.1 266
172.16.200.0 255.255.255.0 On-link 172.16.200.1 266
172.16.200.1 255.255.255.255 On-link 172.16.200.1 266
172.16.200.255 255.255.255.255 On-link 172.16.200.1 266
192.168.0.0 255.255.255.0 On-link 192.168.0.117 266
192.168.0.117 255.255.255.255 On-link 192.168.0.117 266
192.168.0.255 255.255.255.255 On-link 192.168.0.117 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.117 266
224.0.0.0 240.0.0.0 On-link 172.16.100.1 266
224.0.0.0 240.0.0.0 On-link 172.16.200.1 266
224.0.0.0 240.0.0.0 On-link 172.16.1.1 261
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.117 266
255.255.255.255 255.255.255.255 On-link 172.16.100.1 266
255.255.255.255 255.255.255.255 On-link 172.16.200.1 266
255.255.255.255 255.255.255.255 On-link 172.16.1.1 261
===========================================================================
Persistent Routes:
None
Primero pensé que la métrica de la ruta 0.0.0.0 era la culpable: originalmente era 6, así que intenté cambiarla a 410, lo que no ha cambiado el comportamiento. (Por cierto, nunca me he metido con la tabla de enrutamiento en esta máquina antes). Luego lo comparé con una máquina Hyper-V 2012 R2 que tengo en 3 de las mismas redes (172.16.1.0, 172.16.100.0 y 172.16.200.0) y noté que la máquina Hyper-V también tiene una métrica de 6 para 0.0 .0.0 ruta, así que supongo que esto es normal y correcto ...
Luego intenté cambiar el 172.16.200.0 para que sea una ruta persistente, como se muestra a continuación, pero aún así no funcionó.
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
172.16.200.0 255.255.255.0 172.16.1.1 1
===========================================================================
También intenté aumentar la métrica (sé que más bajo es más preferido, pero solo en caso, ¿eh?) ... por supuesto, no tuve suerte.
En la "Configuración avanzada" en la ventana Conexiones de red, he confirmado que el adaptador 192.168.0.117 es el más bajo en el orden de Adaptadores y enlaces ...
Entonces, después de golpearme la cabeza un poco, estoy perplejo. Obviamente, eliminar la ruta 0.0.0.0 la detiene, pero por supuesto también detendrá mi internet ...
¿Cómo puedo evitar que mi máquina intente pasar por mi puerta de enlace predeterminada 192.168.0.1 cuando intenta alcanzar un host en 172.16.200.0 ...
http://technet.microsoft.com/en-us/library/cc779122%28v=ws.10%29.aspx ("La tabla de enrutamiento IP: TCP / IP") parece sugerir que "La ruta predeterminada normalmente envía un Datagrama IP (para el que no hay una ruta local coincidente o explícita) a una dirección de puerta de enlace predeterminada para un enrutador en la subred local ". ¡Cuánto más explícito puedo obtener con esa ruta!
La respuesta aquí La puerta de enlace de ruta persistente de Windows no está disponible, por lo que la ruta predeterminada utilizada sugiere que este es un comportamiento normal: cuando se agrega una ruta persistente, intentará usar esa ruta si es posible, pero luego volverá a la ruta predeterminada cuando eso falle. Seguramente eso podría presentar algunos problemas de tráfico bastante serios, sin mencionar los problemas de seguridad (información privada que se filtra en Internet, o al menos las redes privadas de su ISP ...)
Alguna información adicional: este servidor ejecuta NPS / RRAS generalmente, deshabilitándolo, e incluso eliminarlo no hizo nada. Además, creé una nueva VM 2008 R2 2008, le di dos NIC, una directamente en la red 192.168.0.0 y la otra en la red 172.16.200.0 e hizo lo mismo ... Espero que se den cuenta de que Pasé un poco de tiempo en esto.
He configurado el enrutador de mi casa para reenviar todas las cosas 172.16.XX a mi computadora, pero eso es una solución ...
¿Hay algo que me falta? ¿Algo obvio, tal vez? ¿Estoy preguntando lo imposible?
[ACTUALIZACIÓN # 1 Y # 2]
He revisado cada bit de configuración en mi enrutador y no parece manejar ninguna solicitud de ARP proxy, ni siquiera tiene ninguna configuración que pueda ver.
Utilicé MS Network Monitor 3.4 para probar si el enrutador responde a las solicitudes ARP, y no lo hacen. Puedo ver la solicitud ARP que se envía cuando intento hacer ping a un host no existente y no recibo ninguna respuesta ARP. Hacer ping a un host que existe, naturalmente, me da una respuesta ARP. ¿Es seguro asumir en este momento que mi enrutador no está manejando solicitudes ARP proxy?
La tabla de enrutamiento en el enrutador fue la siguiente:
> route show
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.20.21.36 * 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 * 255.255.255.0 U 0 0 0 br0
default * 0.0.0.0 U 0 0 0 ppp0
Agregué estas entradas a continuación como una medida temporal provisional: evita que mis pobres paquetes "perdidos" vayan a mi ISP:
172.16.1.0 192.168.0.117 255.255.255.0 UG 1 0 0 br0
172.16.100.0 192.168.0.117 255.255.255.0 UG 1 0 0 br0
172.16.200.0 192.168.0.117 255.255.255.0 UG 1 0 0 br0
[ACTUALIZACIÓN # 3 - Tablas de enrutamiento de máquinas virtuales Ubuntu y Win8.1 agregadas]
Bien, entonces creé una nueva máquina virtual Ubuntu y una nueva máquina virtual Windows 8.1. Ubuntu VM no intenta volver a su ruta 0.0.0.0, pero Windows 8.1 sí. Probé el viejo host ping-a-non-existant y observé el tráfico en el enrutador 172.16.1.1. Recibe las solicitudes ICMP de la VM de Windows 8.1 y las pasa, pero nunca ve ningún tráfico ICMP de la VM de Ubuntu.
La tabla de Ubuntu VM está abajo:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface MSS Window irtt
0.0.0.0 172.16.1.1 0.0.0.0 UG 0 0 0 eth0 0 0 0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth1 0 0 0
172.16.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 0 0 0
172.16.200.0 0.0.0.0 255.255.255.0 U 1 0 0 eth1 0 0 0
La tabla de Windows 8.1 está a continuación:
===========================================================================
Interface List
9...00 15 5d 01 4c 1c ......Microsoft Hyper-V Network Adapter #2
3...00 15 5d 01 4c 08 ......Microsoft Hyper-V Network Adapter
1...........................Software Loopback Interface 1
4...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.16.1.1 172.16.1.101 5
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
172.16.1.0 255.255.255.0 On-link 172.16.1.101 261
172.16.1.101 255.255.255.255 On-link 172.16.1.101 261
172.16.1.255 255.255.255.255 On-link 172.16.1.101 261
172.16.200.0 255.255.255.0 On-link 172.16.200.1 261
172.16.200.1 255.255.255.255 On-link 172.16.200.1 261
172.16.200.255 255.255.255.255 On-link 172.16.200.1 261
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 172.16.1.101 261
224.0.0.0 240.0.0.0 On-link 172.16.200.1 261
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 172.16.1.101 261
255.255.255.255 255.255.255.255 On-link 172.16.200.1 261
===========================================================================
Persistent Routes:
None
Respuestas:
La recuperación de errores a la ruta predeterminada es un comportamiento normal desde Vista, puede leer sobre esto en el siguiente artículo: Selección de la dirección IP de origen en una computadora Windows con múltiples hosts .
Problema de bucle causado por un enrutador mal configurado, que devuelve los paquetes utilizando una subred diferente, en lugar de descartarlos.
fuente