No hay internet después de que el contrato de arrendamiento de dhcp se renueva

Hoy tuvimos varias máquinas que dejaron de tener acceso a internet. Después de una gran cantidad de solución de problemas, el hilo común es que a todos se les renovó su contrato de arrendamiento de dhcp hoy (estamos en contratos de arrendamiento de 8 días aquí).

Todo lo que esperaría se ve bien después de la renovación del contrato de arrendamiento: tienen una dirección IP, un servidor DNS y una puerta de enlace válidos. Tienen acceso a recursos internos (archivos compartidos, intranet, impresoras, etc.). Un poco más de solución de problemas revela que no pueden hacer ping o tracert a nuestra puerta de enlace, pero pueden llegar a nuestro conmutador core layer3 justo en frente de la puerta de enlace. Asignar una IP estática a la máquina funciona como una solución temporal.

Una arruga final es que hasta ahora los informes solo han llegado para clientes en la misma vlan que la puerta de enlace. Nuestro personal administrativo y facultad está en la misma vlan que los servidores e impresoras, pero los teléfonos, llaveros / cámaras, estudiantes / wifi y laboratorios tienen sus propios vlans y hasta donde yo no he visto nada en ninguno de los otros vlans ha tenido un problema todavía.

Tengo un boleto separado con el proveedor de la puerta de enlace, pero sospecho que tomarán la decisión fácil y me dirán que el problema está en otra parte de la red, así que también pregunto aquí. He borrado los cachés de arp en la puerta de enlace y el interruptor central. Cualquier idea bienvenida.

Actualización:
intenté hacer ping desde la puerta de enlace a algunos hosts afectados, y lo extraño es que obtuve una respuesta: desde una dirección IP completamente diferente. Intenté algunos más al azar y finalmente obtuve esto:

Vie 02 sep 2011 13:08:51 GMT-0500 (horario de verano central)
PING 10.1.1.97 (10.1.1.97) 56 (84) bytes de datos.
64 bytes de 10.1.1.105: icmp_seq = 1 ttl = 255 tiempo = 1.35 ms
64 bytes de 10.1.1.97: icmp_seq = 1 ttl = 255 tiempo = 39.9 ms (DUP!)

10.1.1.97 es el objetivo real previsto del ping. 10.1.1.105 se supone que es una impresora en otro edificio. He Nunca visto un paquete de actualización en una respuesta de ping antes.

Mi mejor suposición en este momento es un enrutador wifi deshonesto en una de nuestras habitaciones compartidas en la subred 10.1.1.0/24 con una mala puerta de enlace.

...continuado. Ahora apagué la impresora ofensiva y los pings a un host afectado desde la puerta de enlace simplemente fallan por completo.

Actualización 2:
compruebo las tablas arp en una máquina afectada, la puerta de enlace y cada cambio entre ellas. En cada punto, las entradas para esos dispositivos eran todas correctas. No verifiqué todas las entradas de la tabla, pero todas las entradas que pudieran afectar el tráfico entre el host y la puerta de enlace estaban bien. ARP no es el problema.

Actualización 3:
Las cosas están funcionando en este momento, pero no puedo ver nada de lo que hice para solucionarlos, por lo que no tengo idea de si esto podría ser solo una pausa temporal. De todos modos, no hay mucho que pueda hacer para diagnosticar o solucionar problemas ahora, pero actualizaré más si se rompe nuevamente.

"Mi mejor suposición en este momento es un enrutador wifi no autorizado en una de nuestras habitaciones compartidas en la subred 10.1.1.0/24 con una mala puerta de enlace".

Esto sucedió en mi oficina. El dispositivo ofensivo resultó ser un dispositivo Android deshonesto:

http://code.google.com/p/android/issues/detail?id=11236

Si el dispositivo Android obtiene la IP de la puerta de enlace de otra red a través de DHCP, puede unirse a su red y comenzar a responder a las solicitudes ARP para la IP de la puerta de enlace con su MAC. Su uso de la red común 10.1.1.0/24 aumenta la probabilidad de este escenario deshonesto.

Pude verificar el caché ARP en una estación de trabajo afectada en la red. Allí, observé un problema de flujo ARP en el que la estación de trabajo cambiaba de dirección entre el MAC correcto y una dirección MAC de algún dispositivo no autorizado. Cuando busqué el sospechoso MAC que tenía la estación de trabajo para la puerta de enlace, regresó con un prefijo Samsung. El usuario astuto con la estación de trabajo con problemas respondió que sabía quién tenía un dispositivo Samsung en nuestra red. Resultó ser el CEO.

Como ya se discutió en la sección de comentarios, obtener una captura de paquetes es realmente crítico. Sin embargo, también hay una herramienta realmente genial llamada arpwatch:

http://ee.lbl.gov/

(o http://sid.rstack.org/arp-sk/ para windows)

Esta herramienta le enviará un correo electrónico o simplemente mantendrá un registro de todas las nuevas direcciones MAC que se ven en la red, así como cualquier cambio en las direcciones MAC para IP en una subred determinada (flip-flops). Para este problema, habría detectado las dos teorías actuales al informar que había flip-flops para IP que cambiaban de MAC, o vería un nuevo MAC para el enrutador DHCP falso cuando comenzó a comunicarse con los hosts. El único inconveniente de la herramienta es que necesita tener el host conectado a todas las redes que supervisa, pero es un pequeño precio por la excelente información que puede proporcionar para ayudar a diagnosticar este tipo de problemas.

Una forma rápida de detectar los servidores DHCP falsos típicos es hacer ping a la puerta de enlace que sirve y luego examinar su MAC en la tabla ARP correspondiente. Si la infraestructura de conmutación es administrada, el MAC también se puede rastrear hasta el puerto que lo hospeda y el puerto se puede cerrar o rastrear hasta la ubicación del dispositivo infractor para obtener una reparación adicional.

El uso de DHCP Snooping en los conmutadores que lo admiten también puede ser una opción efectiva para proteger una red de servidores DHCP corruptos.