Qué hacer si Linux se atasca
El primer paso es capturar paquetes. Los pasos son los siguientes
Iniciar la captura de paquetes en el servidor Linux.
SSH desde el portátil al servidor Linux, introduce el nombre de usuario y pulsa Enter.
Espere unos 10 segundos hasta que la interfaz de inicio de sesión le solicite que ingrese su contraseña.
Dejar de capturar paquetes.
Esto le brindará un paquete de red que cubre este fenómeno. Generalmente, no hay tráfico de interferencia en el laboratorio y se puede analizar sin filtrar. Sin embargo, es mejor desarrollar el hábito del filtrado al realizar experimentos para adaptarse a los paquetes capturados en el entorno de producción. Debido a que iniciamos sesión a través del protocolo SSH, podemos usar "ssh" directamente para filtrar, como se muestra en la figura. Todos los paquetes SSH están cifrados, por lo que no podemos ver qué significa cada paquete, pero esto no afecta el análisis. Como puede verse en la Figura 2, el paquete No. 21 y el paquete No. 25 están separados exactamente por 10 segundos.
Los acontecimientos ocurridos entre estos dos paquetes pueden ser la causa de este fenómeno. Entonces usé "frame.number> 21 && frame.number< 25" para filtrar,
Análisis
Como puede ver en la imagen, el servidor Linux estaba ocupado enviando solicitudes a el servidor DNS Consulta el registro PTR (es decir, resolución inversa) de 10.32.200.23 e intenta obtener el nombre de dominio correspondiente a esta dirección IP. La IP pertenecía a la computadora portátil que usamos para la prueba, pero como no había ningún registro PTR en el servidor DNS, esperamos 5 segundos para ambas consultas pero aún así no obtuvimos resultados. Se desperdiciaron un total de 10 segundos.
De esto podemos deducir que cuando este servidor Linux reciba una solicitud de acceso SSH, primero consultará el registro PTR correspondiente a la IP del cliente. Si no recibe respuesta después de 5 segundos, envíe otra consulta. Si aún no hay respuesta después de esperar 5 segundos para la segunda consulta, la consulta se abandonará por completo. Incluso podemos adivinar que si la consulta DNS tiene éxito, no habrá necesidad de esperar esos 10 segundos en vano.
Para verificar esta suposición, agregué el registro PTR de 10.32.200.23 al servidor DNS e inicié sesión nuevamente.
Esta vez inicié sesión inmediatamente. Como se puede ver en la captura de pantalla de Wireshark en la figura, la consulta de DNS se realizó correctamente, por lo que casi no hay tiempo para hacer una pausa entre el paquete 21 y el paquete 26.
Resultados
Ahora que entendemos que la consulta DNS es la causa del problema, sabemos cómo investigar más. Simplemente busque "ssh dns" en Google y los enlaces de la primera página tratarán sobre este tema. Simplemente elija algunos artículos y léalos, e incluso un principiante de Linux como yo podrá estudiar este tema a fondo. Resulta que este comportamiento está definido en el archivo "/etc/ssh/sshd_config". La configuración predeterminada es así:
[root@Linux_Server ~]# cat /etc/ssh/sshd_config |grep. -i usedns #UseDNS sí
El problema se puede solucionar cambiándolo a lo siguiente sin cambiar la configuración en el servidor DNS:
[root@Linux_Server~]# cat /etc /ssh/sshd_config | grep -i usedns UseDNS no