uTorrent hace que DNS deje de funcionar ocasionalmente

8

Mientras usa uTorrent, el DNS deja de responder periódicamente.

El problema parece no estar relacionado con el uso excesivo de ancho de banda (como se ve desde el enrutador a la computadora), pero puede estar relacionado con alguna forma de protección contra inundaciones proporcionada por el enrutador (más conexiones entrantes al enrutador que Windows aceptará).

¿Cómo hago para que la red funcione correctamente (sin dejar de poder usar uTorrent, por supuesto)?

windows utorrent

— Andrey
fuente

¿Qué te dice que no puedes resolver nombres de dominio? Funciona nslookup google.com? Si no, ¿qué tal nslookup google.com 8.8.8.8? Agregue el resultado de esos comandos a su pregunta.

— Bob

@Bob ping no pudo resolver el nombre, no sabía sobre el comando nslookup, lo comprobaré una vez que deje de funcionar, (afortunadamente) funciona ahora. ¡Gracias!

— Andrey

Mientras lo hace, anote la dirección IP de cualquier sitio en el que esté probando e intente hacer ping a la dirección IP cuando se caiga (realmente no importará, pero no está de más comprobarlo).

— Bob

@Bob Lo hice, sabía la IP de un sitio que visito. Por lo tanto, es algo totalmente DNS.

— Andrey

@Bob, ¿podrías echar un vistazo a la pregunta actualizada?

— Andrey

13

los clientes bittorent se conectan agresivamente con sus pares ... y algunos enrutadores interpretan esto como una inundación de sincronización

Conexiones abiertas

Cuando se carga uTorrent y las cargas / descargas se pausan (no se detienen), mantiene conexiones abiertas con sus pares. Mientras tanto, legiones de pares de Internet aún intentarán conectarse contigo para averiguar si tienes los bits que quieren.

Eventualmente alcanzará el límite de conexión abierta impuesto por su sistema operativo (en Windows 7 son 10 conexiones) y las conexiones de nuevos clientes comenzarán a hacer cola en su enrutador.

Los clientes en cola comprobarán agresivamente para ver si una conexión es gratuita. Este sondeo agresivo puede interpretarse como un ataque de inundación sincronizada por parte del enrutador.

Soluciones

baje su límite de conexión medio abierta en su software bittorent por debajo del límite de conexión impuesto por su sistema operativo
deshabilite la protección contra inundaciones de IP en su enrutador / módem.

Saturación de ancho de banda

Además, con la conexión de uTorrent (o cualquier tráfico masivo) ejecutándose sin restricciones, la tubería de carga (y posiblemente descarga) alcanza el uso completo, lo que obliga a un poco de tráfico de "mantenimiento" a un segundo plano, lo que termina disminuyendo la utilidad de la red.

Aquí hay un ejemplo:

La descarga de alta velocidad (torrent o de otro tipo) satura el enlace descendente.
El usuario intenta navegar a un sitio no visitado recientemente. La computadora genera una solicitud de información de DNS para el sitio deseado. La "carga" de la solicitud al servidor DNS se realiza correctamente (no se impugna el acceso de canalización ascendente).
El servidor DNS responde (o lo intenta), pero la respuesta se atasca al tratar de llegar a la máquina del usuario porque la tubería de descarga está saturada de contenido de descarga, y dado que hay que descartar algo y la descarga es agresiva para mantener la velocidad, el La respuesta DNS se cae (en algún momento antes de llegar al enrutador local).

Lo mismo puede suceder si la carga no está restringida. Con la carga saturada, los paquetes conocidos como TCP-ACK (que se envían como "Oye, recibí el paquete xyz con éxito" escriben respuestas) se cuelgan, haciendo que las descargas se detengan, lo que hace que la navegación web se vuelva muy irregular.

Soluciones

Calcule cuáles son las capacidades máximas de su conexión (arriba y abajo, individualmente) y establezca la velocidad máxima de sus clientes de transferencia masiva para no usar más del 80% de esa velocidad. Esto dejará "margen de maniobra" para que cosas como los paquetes DNS y TCP-ACK eviten el tráfico masivo y se solucionen rápidamente.
Utilice un enrutador que pueda manejar la configuración del tráfico de manera que se pueda priorizar cierto tráfico (DNS, IMCP Ping, TCP-ACK) antes que otras formas de tráfico, y algunas formas de tráfico (torrent en particular) pueden ser priorizadas. Este es mi método preferido. Esto puede brindar el beneficio adicional de permitir que la tubería completa hacia arriba y hacia abajo sea utilizable para el tráfico de torrentes cuando el tráfico de mayor prioridad no lo desafía.
Use alguna combinación de 1 y 2 para restringir el tráfico de "mal comportamiento".

Si está interesado en obtener más información sobre las distribuciones de Linux / BSD de conformación de tráfico, MonoWall e IPCop tienen buena información.

— asesino
fuente

Esto es correcto en general, pero en este caso no fue el problema. Todas las cargas y descargas fueron pausadas. Entonces uTorrent generó solo su tráfico de servicio. El problema era que de alguna manera uTorrent forzó una alerta de falsos positivos en el firewall del enrutador.

— Andrey

Si uTorrent no estaba saturando la tubería ascendente o descendente (o ambas), entonces no debería haber causado ningún problema ... a menos que uTorrent y el enrutador a través de UPNP (que deshabilitaría personalmente) estuvieran mal configurados. . NUNCA tuve UPNP nada más que un problema.

— Killermist

@JeremyW que finalmente parece una respuesta. Pero reducir el límite de conexión medio abierta no ayudó, los configuré en 10, pero aún así DNS no funcionó correctamente.

— Andrey

@Andrey O, tal vez la solución es ir en la otra dirección. Si las ventanas pueden manejar las conexiones, increméntelas para que no queden atrapadas en el enrutador, convirtiéndose en atrasos.

— Killermist

@killermist mientras estoy de acuerdo con nuestras ediciones, la pregunta ya no es cómo puedo tener uTorrent y DNS, porque di una respuesta, la pregunta es más por qué es así.

— Andrey

5

Cuando tengo algo así, Wireshark es mi mejor amigo.

Pero primero es bueno darse cuenta de estas tres cosas:

El hecho de que el ping funcione no significa que el DNS (o cualquier otro servicio) esté funcionando, y viceversa.

Esto se debe a que el ping usa un protocolo completamente diferente (ICMP, mientras que el DNS usa IP y una combinación de UDP y TCP), en un nivel de modelo de red completamente diferente. Cualquier cosa en el camino, desde su firewall personal a través del número de enrutadores hasta el host real donde se está ejecutando el servicio, puede configurarse para descartar uno de estos pero no el otro (ya sea paranoia del administrador o algún caso de falla), aunque normalmente le sucede a ICMP que a otros
En general, también es bueno aclarar si se están perdiendo sus solicitudes (DNS) o las respuestas.

Bueno, el programa particular que está utilizando debería aclararlo, pero como regla general, es más fácil verlo usted mismo en la GUI de Wireshark :)
Como he mencionado, el DNS normalmente usa UDP como forma de entregar el contenido de la solicitud y la respuesta.

A diferencia de su hermano TCP, UDP se define de una manera que no hay garantía de que el paquete se entregará, y no hay nada que un enrutador deba (ni pueda) hacer para informarle sobre la falla. (Esto es un sacrificio para la otra característica de UDP: es increíblemente rápido. Los enrutadores no tienen que guardar ninguna información sobre el remitente ni el orden de los paquetes, simplemente lo transmiten y olvidan. Incluso pueden darles con mayor seguridad que TCP.)

Por lo general, lo primero que haría sería:

Iniciar Wireshark
Haga clic en Opciones de captura
Para el filtro de captura, configure host 1.2.3.4para asegurarse de que solo está capturando tráfico entre usted y 1.2.3.4
Iniciar captura
Una vez que hayas encendido de esta manera, prueba tus comandos

Sin embargo, según su última actualización: no conozco este software, pero definitivamente sospecharía del cliente uTorrent. Es posible que una aplicación envíe demasiados UDP que, por ejemplo, se alcanza algún límite en su enrutador doméstico y comienza a tirar paquetes UDP.

— Alois Mahdal
fuente

Cuando tiene tiempos de espera en las solicitudes, no estoy seguro de que Wireshark pueda ayudar. Desde el lado del cliente, parece que el servidor DNS simplemente ignora las solicitudes, pero el enrutador descarta las solicitudes o las respuestas debido a alguna alerta de falsos positivos en la inundación de IP.

— Andrey

@Andrey Tienes razón en que Wireshark no te dirá dónde se perdió el paquete: si estaba en el camino de regreso o de regreso. Sin embargo, puede ayudar asegurarse de que los paquetes realmente abandonaron su caja, en caso de que ocurra algo realmente funky. (Al igual que su firewall personal es paranoico o algo más está misteriosamente roto.) Siempre me gusta poner estas cosas de la ecuación lo antes posible;)

— Alois Mahdal

3

Me gustaría probar la herramienta de referencia DNS de GRC . Prueba los servidores DNS que está configurado para usar, así como muchos otros servidores DNS. No solo prueba su velocidad, sino también su fiabilidad. Es gratis y no necesita ser instalado (solo es Windows). También hay mucha buena información sobre DNS en esas páginas.

— Paul Walker
fuente

Probé esta aplicación, los resultados son extraños, por lo general, la mayoría de los servidores DNS no responden. Obviamente, es imposible que todos los servidores de repente dejen de funcionar. Algo está mal entre mí y los servidores, y no sé qué podría ser.

— Andrey

3

Me gustaría saber en qué parte del mundo se encuentra, y sería útil tener un resultado tracert / traceroute para google.com y 8.8.8.8.

El problema podría ser causado por su enrutador o por su conexión a los servidores de Google. La naturaleza intermitente de su problema huele a mala conectividad, pero simplemente hay demasiados factores al analizar los problemas de conectividad a Internet para darle una respuesta inmediata.

La red de Google ocasionalmente puede sobrecargarse. Tengo casos diarios en los que una solicitud de google.com se agota y necesita reiniciarse, y uso su servidor local para mi país. Es en parte una cuestión de suerte a qué segmento de la red de Google se enruta la solicitud, e incluso puede haber ineficiencias en los algoritmos internos de distribución de solicitudes de Google.

Probablemente sea lo mismo con los servidores de nombres de Google. Aunque Google tiene varios de ellos, la solicitud puede enrutarse a un servidor interno o segmento de red momentáneamente sobrecargado.

No has mencionado en qué parte del mundo estás situado. Si no se encuentra en los EE. UU., Cada solicitud puede tomar una ruta diferente y puede experimentar problemas o retrasos ocasionales si depende de demasiados servidores intermedios.

Sin mencionar las "optimizaciones" o posibles deficiencias de su ISP, o cualquier optimización que Google haya hecho para dividir la carga en sus servidores en todo el mundo.

Usar un servidor DNS lejano puede penalizarlo de otras maneras. Ver :

¿Por qué usar Google DNS / OpenDNS es una mala idea?
¿Debo usar el DNS de mi ISP o el 8.8.8.8 de Google?

— harrymc
fuente

2

Encontré la solución, aunque no lo entiendo completamente, si alguien puede explicarlo correctamente, publíquelo como respuesta y le daré recompensas, porque otras respuestas no ayudaron.

Como mencioné en el apéndice de la pregunta, uTorrent estaba relacionado con el problema, porque cerrar uTorrent resolvió el problema. Decidí averiguar cómo solucionarlo sin necesidad de cerrar uTorrent. En este hilo y en este (fue muy relevante porque las personas allí tienen el mismo ISP y enrutador) ¡Encontré sugerencias de que debería deshabilitar la protección contra inundaciones de IP en mi enrutador y funcionó! El problema y la solución eran exóticos, posiblemente específicos del enrutador Cisco EPC3925 o incluso de un ISP en particular (popular en Europa, por eso era difícil buscar algo en inglés en Google).

— Andrey
fuente

Si hubiera mencionado que esto solo sucede cuando uTorrent está activo, nuestras respuestas habrían sido más relevantes.

— harrymc

@harrymc No lo sabía al principio, cuando me hicieron una pregunta. Una vez que descubrí que es uTorrent está causando problemas, lo agregué inmediatamente al texto de la pregunta.

— Andrey