Actualmente estoy investigando problemas de red de la LAN de un amigo (de nuevo). La conectividad a Internet es muy lenta y poco fiable y, a veces, los servicios simplemente no funcionan.
He monitoreado el tráfico durante algún tiempo usando Wireshark. Finalmente se me ocurrió un problema reproducible, un git pullover sshque no funcionó. Así es como git pullse veía el registro de Wireshark :
Las retransmisiones TCP siempre comienzan cuando se inicia el intercambio de claves. O el servidor no recibe el paquete de mi máquina o mi máquina no recibe su respuesta. Tengo la sensación de que la causa de esto es también la causa de todos los demás problemas de red de la LAN.
Una cosa que se me ocurrió es la longitud del paquete de 1514, mientras tenía configurado el bit de no fragmentar, de todos los paquetes defectuosos aquí, pero el enrutador de la LAN está configurado para una MTU de 1492. No puedo configurar el enrutador para una MTU mayor que 1500. ¿Podrían los paquetes ser demasiado grandes como para quedar atrapados en el enrutador?
Además, la mayoría de las conexiones seguras (https, ssh) parecen verse afectadas, pero siempre podrían requerir paquetes de mayor tamaño.
Verá, no tengo mucha experiencia con la creación de redes, así que espero que algunos de ustedes con más experiencia puedan entender mejor esto.
Editar: Justo ahora, git pullestá funcionando bien nuevamente. La configuración de MTU no puede ser la causa de los problemas...
Respuesta1
Los paquetes grandes con "no fragmentar" son normales. Así es como el sistema operativo realiza el descubrimiento de MTU: en lugar de permitir que la red fragmente silenciosamente los paquetes, espera que se devuelva un error ICMP "Fragmentación requerida" (que tendría la MTU correcta).
Si ve que se retransmiten paquetes grandes, significa que algún enrutador en el medio está mal configurado y bloquea los paquetes de error ICMP o no los envía cuando es necesario.
Respuesta2
Creo que ocurre un reconocimiento duplicado.solocuando el receptor ve un espacio en los números de secuencia, lo que significa que se perdió un paquete en el camino hacia él; entonces el problema comienza en la dirección 192.168.0.8 hacia el servidor remoto. El hecho de que no haya reconocimientos (ni siquiera duplicados) a pesar de varias retransmisiones probablemente significa que algo está totalmente jodido en esa dirección. (Podría significar que el lado remoto no puede enviar, pero eso no es consistente con el reconocimiento duplicado anterior ni con el reconocimiento final posterior. Significaría que hay 2 problemas en lugar de 1).
Aquí hay algunas ideas:
- Si la conexión se realiza a través de una mala red wifi pública o 3G, entonces puede obtener breves períodos de caída del 100% de los paquetes. Verifique utilizando otro servicio al mismo tiempo y vea si también se ve afectado por la interrupción.
- Hay cortafuegos que reconocen protocolos y pueden tardar un poco en determinar lo que está haciendo antes de que decidan descartar paquetes en una conexión en particular. ¿Tu amigo está ejecutando un firewall exótico que podría desactivarse? ¿Tiene el ISP algunas reglas de uso?
- Intente actualizar los controladores o iniciar desde un Live CD de Linux y ver si sucede lo mismo. Intente cambiar otros aspectos de la conexión, utilizando otros servicios, para delimitar el problema.