La sesión SSH a través de OpenVPN se corta / bloquea después de unas pocas líneas

Tengo una gran cantidad de PC sin ventilador idénticas con Debian 6 (ARM). La mayoría de estos están conectados a través de Comcast y funcionan bien. Algunos están conectados a módems 'WiMax' y tienen problemas de comunicación.

Específicamente: si hago un ssh a uno de estos e intento un comando como 'ps -ax', obtendré aproximadamente 3 líneas y luego la sesión se bloqueará. Si lo dejo reposar, eventualmente se cerrará con una 'sesión cerrada por igual'.

Lo que he intentado:

ssh -vvv → no hay mensajes de error
ssh <user@host> 'command'→ esto a veces devolverá la salida completa del comando. A veces no se conecta en absoluto.

¿Sugerencias sobre otras cosas para probar?

Descubrí que puedo ejecutar algunos comandos con éxito: por ejemplo, presionar regresar una docena de veces o más está bien. cd ~y luego lffunciona como lo hace df -h. Puedo ejecutar dfmuchas veces con éxito, pero tan pronto como intento algo con más salida (por ejemplo ls /etc) se bloquea.

¿Hay alguna diferencia en que estoy tratando de comunicarme entre estos dos hosts usando OpenVPN?

networking ip openvpn

— ethrbunny
fuente

Asegúrese de que su MTU de ruta no sea inferior a su MTU de interfaz configurada. SSH no se fragmenta, por lo tanto, con el bit DF establecido, los paquetes se descartan en su lugar. Lea esto para una explicación mucho más detallada.

— Aaron Copley

Intenté configurar MTU en todas las interfaces a 1400 sin efecto aparente. Probado con el ping -c 1 -s $((5000-28)) -M do machine-ipque devolvió 1500 - igual que la máquina

— ethrbunny

tracepath -n <ip>confirma esto: 1500 está permitido todo el camino.

— ethrbunny

Perdona mi ignorancia, pero ¿cómo -Tayuda en este caso?

— Aaron Copley

<Lee el segundo párrafo> Es un problema de MTU. <Sigue leyendo> Sí, problema de MTU. Vea este hilo para una explicación. No voy a votar para cerrar como duplicado porque hay un punto que el otro hilo no discute: lo que necesita cambiar en su configuración de VPN para solucionar el problema.

— Gilles 'SO- deja de ser malvado'

Respuestas:

Tiene los síntomas de un problema de MTU : algunas conexiones TCP se congelan, de manera más o menos reproducible para un comando o URL determinado, pero sin un patrón general fácilmente discernible. Un síntoma revelador es que las sesiones ssh interactivas funcionan bien siempre que no ejecute comandos con una salida grande. Consulte No se puede acceder a determinados sitios https en Linux a través de PPPoE para obtener una explicación.

OpenVPN tiene varias opciones relacionadas con MTU: busque “mtu” en el manual. No tengo suficiente experiencia para confiar en la opción que necesita cambiar. (Incluso es posible que pueda cambiar algo en la configuración del módem Wimax). La opción más probable para cambiar es mssfix: intente reducir el valor hasta que solucione el problema. El valor predeterminado es 1450; algo así como alrededor de 1400 podría solucionar su problema. Prueba openvpn --fragment 1200 -mssfix; si ayuda, aumente el valor hasta que comience a romperse.

— Gilles 'SO- deja de ser malvado'
fuente

Estoy comenzando configurando mssfix 1200en el servidor y reiniciando. Hasta ahora tan bueno. Si esto funciona, subiré a 1300 o 1400 y veré qué sucede. Sin embargo, hay demasiados clientes para cambiar todas las configuraciones remotas, por lo que el lado del servidor tendrá que hacerlo.

— ethrbunny

¡ Sabía que era MTU!

— Aaron Copley

La respuesta de Gilles es completamente correcta, pero también hay otra causa potencial para esto.

Hubo un error en la versión 2.3.0 de OpenVPN que desconectaba a los clientes al enviar grandes cantidades de datos: https://community.openvpn.net/openvpn/ticket/263

Este problema solo ocurrió cuando se usa TCP. UDP no se vio afectado por completo.

— Patricio
fuente

Tuvimos el mismo problema, y de hecho fue un problema de MTU. Sin embargo, para nosotros, el problema no estaba en la configuración de openVPN sino en la interfaz tun0.

Cómo lo resolvimos: primero encuentre el tamaño máximo de paquete que pasó, con

ping <host> -s 1500 -M do

y reduciendo el valor de 1500 hasta que un valor pasara (para nosotros, 1350).

Una vez que se encuentra el valor correcto, cambie la interfaz tun0 con

sudo ip link set dev tun0 mtu 1350

como lo propuso Sebastián aquí . Después de eso, la VPN fue sin problemas.

— Eino Gourdin
fuente