OpenVPN: ¿Cómo mitigar los problemas de MTU de ruta por cliente?

Tenemos docenas de dispositivos integrados instalados en los clientes, todos llamando a casa a nuestro servicio OpenVPN. Eso funciona bien en general, pero algunos de nuestros clientes tienen problemas severos de MTU. Nuestra influencia en los clientes para reparar sus redes es limitada, por lo que necesitamos que OpenVPN se encargue de ello. En pocas palabras, mi pregunta es:

¿Cómo puedo mitigar las MTU de ruta baja de algunos clientes en una base por cliente, es decir, sin utilizar configuraciones globales que se adapten al peor de los casos para todos los clientes?

Tenga en cuenta que nuestro peor de los casos es bastante malo: la ruta MTU 576, elimina todos los fragmentos, no se fragmenta, no respeta el bit DF. Ya ves por qué preferiría no resolver este problema a nivel mundial.

La página de manual de OpenVPN ofrece una serie de opciones relacionadas con MTU, en particular --link-mtu, --tun-mtu, --fragment and --mssfix. Pero también dice

--link-mtu [...] Es mejor no configurar este parámetro a menos que sepa lo que está haciendo.

--tun-mtu [...] Es mejor usar las opciones --fragment y / o --mssfix para tratar los problemas de dimensionamiento de MTU.

Así que comencé a experimentar --fragmenty --mssfixpronto tuve que darme cuenta de que al menos el primero debe configurarse no solo del lado del cliente, sino también del lado del servidor . Luego busqué en la configuración por cliente del lado del servidor a través de --client-config-dirpero dice

Las siguientes opciones son legales en un contexto específico del cliente: --push, --push-reset, --iroute, --ifconfig-push y --config.

¡No se mencionan las opciones de MTU!

Así que aquí están mis preguntas más específicas:

¿Por qué exactamente link-mtuy tun-mtudesanimados? ¿Cuáles son los posibles problemas con estas opciones? Tenga en cuenta que estoy bastante cómodo con el munging de encabezado IP de bajo nivel.
¿Cuál de las opciones link-mtu tun-mtu fragment mssfixdebe reflejarse en el lado del servidor para que funcione?
¿En cuál de las opciones link-mtu tun-mtu fragment mssfixse puede usar client-config-dir?
En caso de que las cuatro opciones tengan que reflejarse en el lado del servidor y no puedan usarse en el interior client-config-dir: ¿Hay alguna alternativa para combatir la MTU de ruta baja por cliente?

Notas:

Algunas de mis preguntas ya se han hecho hace 5 años aquí , pero en realidad no se han respondido en ese momento, por lo tanto, me atrevo a duplicarlas.
El servidor OpenVPN es actualmente 2.2.1 en Ubuntu 12.04. Estamos preparando una actualización a 2.3.2 en Ubuntu 14.04
Los clientes OpenVPN son 2.2.1 en Debian 7.6
Me complace determinar la ruta de un MTU de un cliente yo mismo manualmente
Actualmente no podemos probar mucho del lado del servidor. Pero estamos construyendo un banco de pruebas completamente separado, debería estar listo pronto.

Estoy agradecido por cualquier consejo útil.

ip openvpn mtu ip-fragmentation

— Nils Toedtmann
fuente

576? Querido Dios. No he visto un MTU tan bajo desde los días de acceso telefónico. ¿Eso va sobre un antiguo enlace en serie?

— Michael Hampton

¿Podría ejecutar dos servidores OpenVPN? Tal vez podría ejecutar ambos servidores en la misma dirección IP pública y usar el reenvío de puertos (o una política de enrutamiento) para dirigir a los clientes a un servidor OpenVPN diferente dependiendo de si están en una red problemática conocida o no (según lo determine una lista de clientes Direcciones IP).

— Kasperd

@MichaelHampton también me preguntaba. Es> 600kbit / sy RTT ~ 30ms, no me parece una serie antigua. Dado que tienen otras configuraciones estúpidas (por ejemplo, no responden al DF con 'fragmentación necesaria'), supongo que esta es solo otra más. Les dijimos, pero aún no hemos recibido respuesta.

— Nils Toedtmann

@kasperd idea interesante. Podría ejecutar varias instancias de servidor OpenVPN. Tendría que tener quizás 3 o 4, para diferentes rangos de MTU. El NAT por cliente del lado del servidor no funcionaría (no puedo predecir las direcciones IP del cliente público dinámico), pero de todos modos tendría que alterar la configuración del cliente para la configuración de MTU (¿correcto?), Así que simplemente configuraría los diferentes puertos directamente en el cliente - ¡Pero sería una pesadilla de mantenimiento que preferiría evitar!

— Nils Toedtmann el

@NilsToedtmann ¿Qué criterio usarías para detectar qué clientes están afectados? Otro enfoque podría ser ejecutar un script en el servidor después de que un cliente se haya conectado. El script puede intentar hacer ping a la dirección IP del cliente con diferentes tamaños de paquetes para determinar qué funciona y cuáles no. Luego puede insertar iptablesreglas para reducir el MSS en todos los paquetes SYN hacia o desde la dirección IP de ese cliente.

— kasperd

Resolví el problema en el lado del cliente agregando la opción mssfix 1300al archivo de configuración.

Desde la página de manual de openvpn:

--mssfix max
    Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes.

La idea original para mi solución vino de personalvpn.org

— Oz123
fuente

Entonces mssfix, ¿ se puede configurar solo en el lado del cliente? Bueno, eso es algo al menos. Sin embargo, no ayuda con los paquetes UDP (razón por la cual estaba interesado en las otras opciones, pero al menos las recomendadas también fragmentdeben establecerse en el lado del servidor)

— Nils Toedtmann

mssfix puede agregarse tanto en el servidor como en el cliente. Sin embargo, el valor más pequeño se usará en la negociación

— Ahmed

Dada la falta de respuestas, ahora estoy publicando una solución que no es muy elegante, pero simple: ejecutar otra instancia de OpenVPN en TCP para "clientes malos"

proto tcp

y baje el TCP MSS en el cliente, por ej.

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o ${OUT_DEV} -j TCPMSS --set-mss ${PATH-MTU-MINUS-40}

Una ventaja de esta solución es que cada cliente puede configurar su MSS individual.

Esto es ciertamente TCP sobre TCP, pero debería funcionar bastante bien en muchos escenarios .

Tenga en cuenta que todavía estoy muy interesado en soluciones que no requieren proto tcp, y las marcaré como respuesta válida si cumplen más o menos con mis requisitos detallados.

— Nils Toedtmann
fuente