24 votos

¿Cómo puedo evitar que la conexión TCP se congela durante un OpenVPN red?

Nuevos detalles añadir al final de esta pregunta; es posible que me estoy centrando en la causa.

Tengo un UDP OpenVPN basado en la configuración de VPN en tap modo (necesito tap porque necesito el VPN para pasar los paquetes de multidifusión, que no parece ser posible con tun redes) con un puñado de clientes a través de Internet. He estado experimentando frecuentes de la conexión TCP se congela a través de la VPN. Es decir, voy a establecer una conexión TCP (por ejemplo, una conexión SSH, pero otros protocolos tienen problemas similares), y en algún momento durante la sesión, parece que el tráfico dejará de ser transmitida a través de que la sesión TCP.

Esto parece estar relacionado con los puntos en los que grandes transferencias de datos se producen, como si yo ejecutar un ls de comandos en una sesión de SSH, o si I cat un largo archivo de registro. Algunas búsquedas en Google vuelta un número de respuestas como la anterior en el Servidor Falla, lo que indica que la probabilidad de que el culpable es un MTU de la cuestión: que durante los períodos de alto tráfico, el VPN está tratando de enviar los paquetes que se caen en algún lugar en las tuberías entre el VPN de los extremos. El de arriba-vinculado respuesta sugiere utilizar las siguientes opciones de configuración de OpenVPN para mitigar el problema:

fragment 1400
mssfix

Este debe limitar la MTU utilizado en la VPN a 1400 bytes y fijar el tamaño máximo del segmento TCP para evitar la generación de cualquier paquete más grande que eso. Este parece mitigar el problema un poco, pero yo todavía frecuente ver a las heladas. Yo he probado un número de tamaños como argumentos a la fragment directiva: 1200, 1000, 576, todos con resultados similares. No puedo pensar en ningún tipo de topología de red entre los dos extremos que podría desencadenar un problema: el servidor VPN se está ejecutando en un pfSense equipo conectado directamente a Internet, y mi cliente también está conectado directamente a Internet a otra ubicación.

Otra extraña pieza del rompecabezas: si ejecuto la tracepath de utilidad, a continuación, que parece band-aid el problema. Un ejemplo de ejecución se ve así:

[~]$ tracepath -n 192.168.100.91
 1:  192.168.100.90                                        0.039ms pmtu 1500
 1:  192.168.100.91                                       40.823ms reached
 1:  192.168.100.91                                       19.846ms reached
     Resume: pmtu 1500 hops 1 back 64 

El anterior plazo es entre dos clientes de la VPN: yo inició el rastreo de 192.168.100.90 para el destino de 192.168.100.91. Tanto a los clientes que se han configurado con fragment 1200; mssfix; , en un intento de limitar la MTU utilizado en el enlace. Los resultados anteriores parecen sugerir que tracepath fue capaz de detectar un path MTU de 1500 bytes entre dos clientes. Supongo que sería algo menor debido a la fragmentación de la configuración especificada en la configuración de OpenVPN. He encontrado que resultan un tanto extraños.

Aún más extraño, sin embargo: si tengo una conexión TCP en el tranque de estado (por ejemplo, una sesión SSH con el listado de un directorio que se congeló en el centro), luego de la ejecución de la tracepath comando que se muestra arriba hace que la conexión a comenzar de nuevo! No puedo calcular cualquier explicación razonable de por qué este sería el caso, pero siento que esta podría estar apuntando hacia una solución, en última instancia, erradicar el problema.

¿Alguien tiene alguna recomendación para otras cosas para probar?

Edit: he vuelto y miró a esto un poco más, y sólo se han hallado más de confusión información:

  • Puedo establecer la conexión OpenVPN para el fragmento en 1400 bytes, como se muestra arriba. Entonces, me he conectado a la VPN a través de Internet y se utiliza Wireshark para mirar los paquetes UDP que fueron enviados al servidor VPN, mientras que el puesto se produjo. Ninguno fue mayor que el especificado 1400 número de bytes, por lo que la fragmentación parece estar funcionando correctamente.

  • Para comprobar que incluso un 1400 bytes MTU sería suficiente, puedo hacer ping al servidor VPN utilizando el siguiente (Linux) comando:

    ping <host> -s 1450 -M do
    

    Esta (creo) envía un 1450 bytes de paquete con la fragmentación de la movilidad (yo, al menos, comprobado que no funciona si lo puse a una, obviamente, demasiado grandes como valor de 1600 bytes). Estos parecen funcionar bien; me responde desde el host con ningún problema.

Así que, tal vez esta no es una MTU problema en absoluto. Estoy confundido en cuanto a qué otra cosa puede ser!

Edit 2: El agujero del conejo se pone cada vez más profundo: ahora he aislado el problema un poco más. Parece estar relacionada con la exacta OS que el cliente de VPN de usa. He logrado duplicar el problema en al menos tres máquinas Ubuntu (versiones 12.04 a través de 13.04). Yo fiable puede duplicar una conexión SSH congelar dentro de un minuto o así, con sólo cat-ción de un gran archivo de registro.

Sin embargo, si hago la misma prueba con un CentOS 6 máquina como un cliente, entonces no veo el problema! He probado con el mismo cliente de OpenVPN versión que yo estaba usando en Ubuntu máquinas. Puedo cat archivos de registro durante horas sin ver la conexión de congelación. Esto parece proporcionar una idea de la causa última, pero no estoy seguro de lo que la intuición es.

He examinado el tráfico a través de la VPN usando Wireshark. Yo no soy un TCP experto, así que no estoy seguro de qué hacer con los detalles escabrosos, pero la esencia es que, en algún punto, un paquete UDP se cae debido al limitado ancho de banda del enlace a Internet, causando retransmisiones de TCP en el interior del túnel VPN. En el CentOS cliente, estas retransmisiones se producen correctamente y mover las cosas con alegría. En algún punto con los clientes Ubuntu, sin embargo, el extremo remoto comienza a retransmitir el mismo segmento TCP y otra vez (con el retardo en la transmisión creciente entre cada retransmisión). El cliente envía lo que parece ser un válido TCP ACK para cada retransmisión, pero el extremo remoto todavía sigue transmitiendo el mismo segmento TCP periódicamente. Esto se extiende ad infinitum y la conexión de los puestos. Mi pregunta aquí sería:

  • ¿Alguien tiene alguna recomendación de cómo solucionar y/o determinar la causa root de la TCP problema? Es como si el extremo remoto no está aceptando los mensajes de CONFIRMACIÓN enviados por el cliente VPN.

Una diferencia común entre los CentOS de nodo y las distintas versiones de Ubuntu es que Ubuntu tiene una mucho más reciente versión del kernel de Linux (de 3.2 en Ubuntu 12.04 a 3.8 en 13.04). Un puntero a algunos de los nuevos bug en el kernel tal vez? Estoy asumiendo que si eso fuera así, entonces yo no sería el único que tiene el problema, que yo no creo que esto parece particularmente exótico de instalación.

11voto

Este comando resuelve por mí:

$ sudo ip link set dev tun0 mtu 1350 && echo ":)"

Puede Verificar la configuración con tun0

$ ip a s

Saludos!

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X