OpenVPN de bajo rendimiento. ¿Tengo problemas con MTU? Vertederos en el interior

Tengo problemas con un túnel OpenVPN que no alcanza la velocidad de la línea. La puerta de enlace es un servidor virtual Debian Jessy alojado en OVH. El cliente es mi servidor doméstico freebsd 10.2 (Intel I3 Ivy Bridge) o mi RaspberryPI2. Desactivé el cifrado y la autenticación. Tengo una conexión FTTH simétrica de 100mbit / s, pero el túnel solo alcanza una velocidad de 20-40mbit / s. La conexión directa (sin túnel) siempre produce los 100mbit / s que espero. Probé el rendimiento con iperf3. Lo intenté por primera vez con mi servidor de inicio gratuito. Probé todas las configuraciones recomendadas sobre mssfix, fragment, etc. Nada ayudó.

Entonces pensé que tal vez es mi máquina freebsd. Así que instalé un nuevo raspbian Jessy en mi RPI2 e hice más pruebas en profundidad:

En primer lugar, eliminé todas las configuraciones de MTU de las configuraciones de OpenVPN y dejé que la ruta MTU manejara las cosas (con suerte). Como no tengo un firewall activo en ambas máquinas, debería funcionar. Estas son mis configuraciones vpn:

server 10.8.0.0 255.255.255.0
port 1194
proto udp
dev tun
sndbuf 0
rcvbuf 0

user nobody
group nogroup
persist-key
persist-tun
ifconfig-pool-persist ipp.txt
keepalive 10 120
push "redirect-gateway def1"
status openvpn-status.log
verb 3

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/vpn.theissen.io.crt
key /etc/openvpn/easy-rsa/keys/vpn.theissen.io.key
dh /etc/openvpn/easy-rsa/keys/dh4096.pem
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
cipher none
auth none
comp-lzo no



client
proto udp
dev tun12
remote xxx.io 1194
resolv-retry infinite
sndbuf 0
rcvbuf 0

nobind
user nobody
group nogroup
persist-key
persist-tun
verb 3

pkcs12 /etc/openvpn/vpn.theissen.io/alex.p12
tls-auth /etc/openvpn/vpn.theissen.io/ta.key 1
ns-cert-type server
cipher none
auth none
comp-lzo no

En primer lugar, la prueba sin el túnel para mostrar que la conexión al servidor es de casi 100mbit / s:

iperf3 -c vpn.theissen.io
Connecting to host vpn.theissen.io, port 5201
[  4] local 192.168.1.253 port 34512 connected to 149.202.58.183 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  10.8 MBytes  90.5 Mbits/sec    0    335 KBytes       
[  4]   1.00-2.00   sec  11.4 MBytes  95.7 Mbits/sec    0    335 KBytes       
[  4]   2.00-3.00   sec  11.1 MBytes  93.0 Mbits/sec    0    352 KBytes       
[  4]   3.00-4.00   sec  11.2 MBytes  94.0 Mbits/sec    0    369 KBytes       
[  4]   4.00-5.00   sec  11.5 MBytes  95.9 Mbits/sec    0    390 KBytes       
[  4]   5.00-6.00   sec  11.0 MBytes  92.5 Mbits/sec    0    390 KBytes       
[  4]   6.00-7.00   sec  11.4 MBytes  95.2 Mbits/sec    0    390 KBytes       
[  4]   7.00-8.00   sec  11.2 MBytes  94.3 Mbits/sec    0    390 KBytes       
[  4]   8.00-9.00   sec  11.1 MBytes  93.3 Mbits/sec    0    390 KBytes       
[  4]   9.00-10.00  sec  11.3 MBytes  95.1 Mbits/sec    0    390 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   112 MBytes  93.9 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   112 MBytes  93.5 Mbits/sec                  receiver

iperf Done.

Los paquetes de esta conexión los descargué con tcpdump en el servidor. Puede descargarlos aquí (debe extraerlos para abrirlos con wireshark): dumpraw.cap.xz

Así es como se ve un volcado "OK". El tamaño máximo de cuadro que vi es 1514.

Ahora corrí la prueba sobre el túnel:

iperf3 -c 10.8.0.1
Connecting to host 10.8.0.1, port 5201
[  4] local 10.8.0.14 port 36388 connected to 10.8.0.1 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  5.96 MBytes  50.0 Mbits/sec  127    133 KBytes       
[  4]   1.00-2.00   sec  5.19 MBytes  43.5 Mbits/sec    6    120 KBytes       
[  4]   2.00-3.00   sec  5.80 MBytes  48.7 Mbits/sec    0    151 KBytes       
[  4]   3.00-4.00   sec  4.27 MBytes  35.9 Mbits/sec   23   96.5 KBytes       
[  4]   4.00-5.00   sec  4.89 MBytes  41.0 Mbits/sec    0    129 KBytes       
[  4]   5.00-6.00   sec  6.11 MBytes  51.2 Mbits/sec   26    111 KBytes       
[  4]   6.00-7.00   sec  5.50 MBytes  46.1 Mbits/sec    0    143 KBytes       
[  4]   7.00-8.00   sec  5.25 MBytes  44.1 Mbits/sec   15    126 KBytes       
[  4]   8.00-9.00   sec  5.80 MBytes  48.7 Mbits/sec    0    158 KBytes       
[  4]   9.00-10.00  sec  3.97 MBytes  33.3 Mbits/sec   22    105 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  52.7 MBytes  44.2 Mbits/sec  219             sender
[  4]   0.00-10.00  sec  52.3 MBytes  43.8 Mbits/sec                  receiver

iperf Done.

Whoops Ya no es tan agradable. Especialmente esta columna "Retr" no se ve tan bien. Supuse que esta es la retransmisión de TCP y debería haber algo en el vertedero. Veremos que no es el caso: /. La CPU no es el cuello de botella aquí porque desactivé el enriquecimiento y la autenticación. La CPU está al 20% en el servidor y al 50% en el PI durante la prueba.

Así es como se ve el tráfico OpenVPN de la prueba:

Para mí esto se ve bien. Pero no sé qué buscar. Por favor, eche un vistazo al vertedero con wireshark: dump_physical.cap.xz

El tráfico en la interfaz del túnel también me parece bien. Parece que bajó correctamente el tamaño del marco (a 1444 como parece):

Aquí está el volcado: dump_tunnel.cap.xz

Para mí, todo esto se ve bien, pero realmente no tengo idea de qué buscar exactamente. Realmente probé todo con la configuración de OpenVPN. Quizás alguien pueda decirme si el tráfico se ve bien.

Lo que espero como respuesta

Al menos una explicación de lo que está sucediendo aquí y por qué parece ser independiente del software VPN que uso. Todo lo que encontré en Internet fue sobre problemas de MTU, pero eso debería solucionarse fácilmente reduciendo la MTU de túnel u otros parámetros de OpenVPN. Para mí esto cambia poco. Cuando observa el volcado, ve que reduce el tamaño del segmento tcp y que los paquetes no están fragmentados. Debe haber algo más. Realmente me gusta saber qué .

Actualizar

Probé esto con strongswan e incluso con softtether. En realidad es el mismo problema (velocidad comparable, sin cuello de botella en la CPU). Estoy realmente desconcertado sobre cuál es el problema aquí. También probé otra puerta de enlace (RaspberryPi2 en amigos 100/100 conexión a casa).

Actualización 2

Noté que iperf3 informa retransmisiones tcp (retr) pero no hay retransmisiones en el volcado (Wireshark debería resaltarlas). Que esta pasando?

Incluso probé OpenVPN en mi red local (RaspberryPi2 a FreebsdServer). Incluso allí tengo muchas retransmisiones (¿en LAN?):

Connecting to host 192.168.222.11, port 5201
[  4] local 192.168.222.10 port 46196 connected to 192.168.222.11 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  9.19 MBytes  77.0 Mbits/sec    8    141 KBytes       
[  4]   1.00-2.00   sec  8.71 MBytes  73.1 Mbits/sec    3    130 KBytes       
[  4]   2.00-3.00   sec  8.59 MBytes  72.0 Mbits/sec    3    120 KBytes       
[  4]   3.00-4.00   sec  8.65 MBytes  72.5 Mbits/sec    4    108 KBytes       
[  4]   4.00-5.00   sec  8.65 MBytes  72.5 Mbits/sec    4   95.6 KBytes       
[  4]   5.00-6.00   sec  8.52 MBytes  71.5 Mbits/sec    2   80.5 KBytes       
[  4]   6.00-7.00   sec  8.83 MBytes  74.1 Mbits/sec    0    141 KBytes       
[  4]   7.00-8.00   sec  8.59 MBytes  72.0 Mbits/sec    7    106 KBytes       
[  4]   8.00-9.00   sec  8.71 MBytes  73.1 Mbits/sec    3   94.2 KBytes       
[  4]   9.00-10.00  sec  8.59 MBytes  72.0 Mbits/sec    3   79.2 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  87.0 MBytes  73.0 Mbits/sec   37             sender
[  4]   0.00-10.00  sec  86.8 MBytes  72.8 Mbits/sec                  receiver

En modo inverso tengo una ventana de congestión realmente extraña (wtf?):

Accepted connection from 192.168.222.10, port 46197
[  5] local 192.168.222.11 port 5201 connected to 192.168.222.10 port 46198
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  5]   0.00-1.00   sec  8.90 MBytes  74.7 Mbits/sec    3   1.48 GBytes       
[  5]   1.00-2.00   sec  8.45 MBytes  70.9 Mbits/sec    2   1.59 GBytes       
[  5]   2.00-3.00   sec  8.66 MBytes  72.7 Mbits/sec  518    214 MBytes       
[  5]   3.00-4.00   sec  7.96 MBytes  66.8 Mbits/sec   37    703 MBytes       
[  5]   4.00-5.00   sec  8.09 MBytes  67.9 Mbits/sec    0    719 MBytes       
[  5]   5.00-6.00   sec  8.04 MBytes  67.5 Mbits/sec    0    734 MBytes       
[  5]   6.00-7.00   sec  8.07 MBytes  67.7 Mbits/sec    1    703 MBytes       
[  5]   7.00-8.00   sec  8.07 MBytes  67.7 Mbits/sec    1    703 MBytes       
[  5]   8.00-9.00   sec  7.99 MBytes  67.1 Mbits/sec    2    693 MBytes       
[  5]   9.00-10.00  sec  8.06 MBytes  67.6 Mbits/sec    1    693 MBytes       
[  5]  10.00-10.09  sec   684 KBytes  64.5 Mbits/sec    0    695 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-10.09  sec  83.0 MBytes  69.0 Mbits/sec  565             sender
[  5]   0.00-10.09  sec  0.00 Bytes  0.00 bits/sec                  receiver

Actualización 3

El uso de iperf con udp produce un bloqueo temporal de ese puerto (me envían un correo electrónico informándome sobre un ataque) y una pérdida masiva de paquetes:

-----------------------------------------------------------
Server listening on 1194
-----------------------------------------------------------
Accepted connection from 185.22.143.160, port 15906
[  5] local 149.202.58.183 port 1194 connected to 185.22.143.160 port 4355
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  2.89 MBytes  24.2 Mbits/sec  0.727 ms  1017/1387 (73%)  
iperf3: OUT OF ORDER - incoming packet = 1409 and received packet = 1470 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1410 and received packet = 1471 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1411 and received packet = 1472 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1445 and received packet = 1473 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1463 and received packet = 1473 AND SP = 5
[  5]   1.00-2.00   sec  3.29 MBytes  27.6 Mbits/sec  0.716 ms  1110/1526 (73%)  
[  5]   2.00-3.00   sec  3.30 MBytes  27.7 Mbits/sec  0.732 ms  1103/1526 (72%)  
[  5]   3.00-4.00   sec  3.27 MBytes  27.4 Mbits/sec  0.717 ms  1108/1526 (73%)  
[  5]   4.00-5.00   sec  1.56 MBytes  13.1 Mbits/sec  0.837 ms  546/746 (73%)  
[  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]  10.00-10.06  sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-10.06  sec   118 MBytes  98.5 Mbits/sec  0.837 ms  4884/6711 (73%)  
[SUM]  0.0-10.1 sec  4884 datagrams received out-of-order

— Alexander Theißen
fuente

Si aún no lo ha hecho, puede intentarlo: tun-mtu 9000 fragment 0 mssfix 0(las opciones deben agregarse en tres líneas diferentes)

— Diamant

Ya lo he probado. Pero lo probé de nuevo. Lo que sucedió es que comienza con la misma velocidad pero luego las conexiones se bloquean. Lo cual, por cierto, siempre sucede cuando desactivo la fragmentación de paquetes de OpenVPN. Esta guía community.openvpn.net/openvpn/wiki/Gigabit_Networks te hace pensar que el sistema operativo debería manejarlo, pero obviamente no lo hace.

— Alexander Theißen

Oh wow. Veo exactamente el mismo comportamiento en mis VPN, y tengo hardware robusto en ambos extremos y una conexión a Internet más lenta. Voy a investigar más a fondo; si encuentro algo concreto, volveré a publicar aquí.

— Harald

Si cambio mi prueba a UDP (iperf3 -u -b 25m) obtengo velocidad máxima tanto dentro como fuera del túnel openvpn. He confirmado que no hay fragmentación cuando uso TCP: openvpn informa correctamente de un pequeño MSS, mis paquetes tcp dentro del túnel tienen 1354 bytes y los paquetes UDP llegan sin fragmentar. Estoy viendo el mismo fenómeno que usted: los valores de CWND dentro del túnel son aproximadamente la mitad de lo que están fuera del túnel, y el rendimiento también es la mitad, pero no puedo explicar por qué . Fascinante.

— Harald

Bien, mis disculpas por crear falsas esperanzas. Intentando eliminar un montón de variables, configuro un OpenVPN con los mismos parámetros de configuración, ejecutándome en mi LAN local. Fuera del túnel, 750Mbps. Dentro del túnel, 117Mbps. Pero - openvpn estaba consumiendo el 100% de un solo núcleo de CPU en ambos puntos finales. Entonces moví el punto final de mi túnel de Internet a un servidor "real" y vi los 25Mbps esperados a través de mi túnel. OpenVPN en ambos puntos finales consumía aproximadamente un 20% de CPU. Larga historia corta: en mi caso, el problema es que mi punto final del túnel del lado local está vinculado a la CPU. ¡Lo siento!

— Harald

Para empezar, su ejecución 'normal' de túnel externo iperf debe ser UDP / 1194 como el flujo en el que tiene el problema y no TCP / 5201. Intente con -b 100M primero, pero tenga en cuenta que esto producirá datagramas de tamaño máximo que no es representativo de su tráfico VPN (el tamaño del datagrama debe ser aleatorio). Sintonice con la opción -l para el tamaño del datagrama y verifique los resultados. Si los resultados no son buenos (diría> 15 o 20% de pérdida), puede sospechar que un enrutador de Internet sobrecargado está cayendo sus paquetes (probablemente marcados como el mejor esfuerzo).

Además, podría ser interesante ver qué rendimiento obtiene si cambia su túnel VPN a un puerto UDP de clase EF (diría que 5061 debido a RTP, pero no estoy seguro de que todos los enrutadores de Internet hayan configurado la QoS correctamente) o cualquier Puerto TCP.

Para mí, no hay nada malo con su configuración y sus diagnósticos no muestran nada extraño. Además, pruebe con otra versión de OpenVPN u otro software VPN.

— 30gd4n
fuente

Hizo que. Mira la actualización 3. Esperando a que Ovh desbloquee el puerto para realizar más pruebas.

— Alexander Theißen

Aww, lo siento, no vi esa última actualización. Mientras espera a OVH, intente montar su VPN sobre TCP; cuales son los resultados También sobre su segunda edición y la retransmisión de * BSD a PI; ¿Has jugado con los búferes de servidor de iperf? Es un valor predeterminado de 8 kb, no sé cómo se hace la pila en ARM y Linux, pero creo que aumentarla podría ayudar.

— 30gd4n

Quise decir que lo agregué después de que me dijeras :). Los resultados sobre tcp son peores. Tcp 443 no hace la diferencia. Lo curioso es que cuando uso este github.com/sivel/speedtest-cli para probar, informa 95m hacia abajo y 75m hacia arriba. Confío más en iperf, pero realmente depende del tipo de tráfico, así que parece. Playstation4 también tarda más en descargar juegos o parches sobre el túnel. Cuando esté en casa, haré un túnel directamente entre dos Rbps que están en diferentes ubicaciones pero usan el mismo ISP. Lo hice antes y los resultados fueron casi iguales. Pero trato de hacer más pruebas.

— Alexander Theißen