OpenVPN baixo desempenho. Eu tenho problemas com o MTU? Despejos dentro

Estou com problemas com um túnel OpenVPN que não atinge a velocidade da linha. O gateway é um servidor virtual Debian Jessy hospedado na OVH. O cliente é meu servidor doméstico freebsd 10.2 (Intel I3 Ivy Bridge) ou meu RaspberryPI2. Desativei a criptografia e a autenticação. Eu tenho uma conexão FTTH simétrica de 100mbit / s, mas o túnel atinge apenas uma velocidade de 20-40mbit / s. A conexão direta (sem túnel) sempre gera os 100mbit / s que eu espero. Testei o desempenho com o iperf3. Eu tentei pela primeira vez com o meu servidor doméstico freebsd. Eu tentei todas as configurações recomendadas sobre mssfix, fragmento etc. Nada ajudou.

Então eu pensei que talvez seja a minha máquina freebsd. Então, instalei uma Jessy raspbian nova no meu RPI2 e fiz mais alguns testes em profundidade:

Antes de tudo, removi todas as configurações de MTU das configurações do OpenVPN e deixei o caminho MTU lidar com as coisas (espero). Como não tenho firewall ativo nas duas máquinas, ele deve funcionar. Estas são minhas configurações de 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

Primeiro de tudo o teste sem o túnel para mostrar que a conexão com o servidor é de fato quase 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.

Os pacotes dessa conexão que eu joguei com o tcpdump no servidor. Você pode baixá-los aqui (você precisa extrair para abri-los com o wireshark): dumpraw.cap.xz

Portanto, é assim que um despejo "OK" se parece. O tamanho máximo de quadro que identifiquei é 1514.

Agora eu executei o teste no 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.

Ops. Não é mais tão legal. Especialmente esta coluna "Retr" não parece tão boa. Eu assumi que este é o retcransmitir TCP e deve haver algo no despejo. Veremos que não é o caso: /. A CPU não é o gargalo aqui porque eu desativei a criptografia e a autenticação. A CPU está em 20% no servidor e 50% no PI durante o teste.

É assim que o tráfego OpenVPN do teste se parece:

Para mim, isso parece bom. Mas eu não sei o que procurar. Dê uma olhada no dump com wireshark: dump_physical.cap.xz

O tráfego na interface do túnel também parece bom para mim. Parece que ele reduziu corretamente o tamanho do quadro (para 1444 como parece):

Aqui está o dump: dump_tunnel.cap.xz

Para mim, isso parece ótimo, mas eu realmente não tenho idéia do que procurar exatamente. Eu realmente testei tudo com as configurações do OpenVPN. Talvez alguém possa me dizer se o tráfego parece bom.

O que eu espero como resposta

Pelo menos uma explicação do que está acontecendo aqui e por que parece ser independente do software VPN que eu uso. Tudo o que encontrei na internet foi sobre problemas de MTU, mas isso deve ser facilmente corrigido, reduzindo o MTU do túnel ou os outros parâmetros do OpenVPN. Para mim, isso muda pouco. Quando você olha para o dump, vê que ele reduz o tamanho do segmento tcp e os pacotes não são fragmentados. Deve haver algo mais. Eu realmente gosto de saber o que .

Atualizar

Eu testei isso com cisne forte e até com éter macio. Na verdade, é o mesmo problema (velocidade comparável, sem gargalo na CPU). Estou realmente confuso qual é o problema aqui. Eu também tentei outro gateway (RaspberryPi2 em amigos 100/100 conexão doméstica).

Atualização 2

Notei que o iperf3 reporta retransmits tcp (retr), mas não há retransmits no dump (o Wireshark deve destacá-los). O que está acontecendo?

Eu até tentei o OpenVPN na minha rede local (RaspberryPi2 to FreebsdServer). Mesmo lá eu tenho muitos retransmits (na 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

No modo reverso, tenho uma janela de congestionamento realmente estranha (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

Atualização 3

O uso do iperf com udp resulta no bloqueio temporário dessa porta (eles me enviam um e-mail informando sobre um ataque) e perda maciça de pacotes:

-----------------------------------------------------------
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
fonte

Se você ainda não fez, meu ser que você pode experimentá-lo: tun-mtu 9000 fragment 0 mssfix 0(opções precisam ser adicionados em três linhas diferentes)

— Diamant

Eu já testei isso. Mas eu testei novamente. O que aconteceu é que ele começa com a mesma velocidade, mas as conexões param. Que, a propósito, sempre acontece quando desativo a fragmentação de pacotes OpenVPN. Este guia community.openvpn.net/openvpn/wiki/Gigabit_Networks faz você pensar que o sistema operacional deve lidar com isso, mas obviamente não.

— Alexander Theißen 9/02/16

Oh uau. Estou vendo exatamente o mesmo comportamento nas minhas VPNs e tenho um hardware robusto nas duas extremidades e uma conexão à Internet mais lenta. Eu vou investigar mais; se eu encontrar algo concreto, postarei aqui.

— Harald

Se eu alternar meu teste para UDP (iperf3 -u -b 25m), obtém velocidade máxima dentro e fora do túnel openvpn. Confirmei que não há fragmentação ao usar o TCP - o openvpn está relatando corretamente um pequeno MSS, meus pacotes tcp dentro do túnel têm 1354 bytes e os pacotes UDP chegam sem fragmentação. Estou vendo o mesmo fenômeno que você - os valores de CWND dentro do túnel são cerca da metade do que estão fora do túnel, e a taxa de transferência também é metade, mas não consigo explicar o porquê . Fascinante.

— Harald

Ok, minhas desculpas por criar falsas esperanças. Tentando eliminar um monte de variáveis, eu configuro um OpenVPN com os mesmos parâmetros de configuração, executando na minha LAN local. Fora do túnel, 750Mbps. Dentro do túnel, 117Mbps. Porém, o openvpn consumia 100% de um único núcleo de CPU nos dois pontos de extremidade. Então, mudei o terminal doméstico do meu túnel da Internet para um servidor "real" e vi os 25 Mbps esperados no meu túnel. O OpenVPN nos dois pontos de extremidade consumia cerca de 20% da CPU. Para encurtar a história - no meu caso, o problema é que meu ponto final do túnel do lado doméstico está vinculado à CPU. Desculpe!

— Harald

Para iniciantes, sua execução 'normal' do túnel externo iperf deve ser UDP / 1194 como o fluxo no qual você está com o problema e não o TCP / 5201. Tente primeiro com -b 100M, mas lembre-se de que isso produzirá datagramas de tamanho máximo que não são representativos do tráfego da VPN (o tamanho do datagrama deve ser aleatório). Sintonize com a opção -l para obter o tamanho do datagrama e verifique os resultados. Se os resultados não forem bons (eu diria> 15 ou 20% de perda), você pode suspeitar de um roteador sobrecarregado da Internet que está descartando seus pacotes (provavelmente marcados como o melhor esforço).

Além disso, pode ser interessante ver qual desempenho você obtém se alternar seu túnel VPN para uma porta EF Class UDP (eu diria 5061 por causa do RTP, mas não tenho certeza de que todos os roteadores da Internet tenham configurado QoS corretamente) ou qualquer Porta TCP.

Para mim, não há nada errado com sua configuração e seus diagnósticos não mostram nada de estranho. Além disso, tente outra versão do OpenVPN ou outro software VPN.

— 30gd4n
fonte

Fiz isso. Veja a atualização3. Aguardando ovh para desbloquear a porta para realizar mais testes.

— Alexander Theißen

Aww, desculpe, não vi a última atualização. Enquanto aguarda a OVH, tente montar sua VPN por TCP; quais são os resultados? Também sobre sua segunda edição e a retransmissão de * BSD para PI; você já brincou com os buffers de servidor do iperf? É 8kb padrão, não sei como a pilha é feita no ARM e Linux, mas eu aumentando isso poderia ajudar.

— precisa saber é

Eu quis dizer que eu adicionei depois que você me disse para :). Resultados acima de tcp são piores. O TCP 443 não faz diferença. O engraçado é que, quando eu uso este github.com/sivel/speedtest-cli para testar, ele informa 95m para baixo e 75m para cima. Confio mais no iperf, mas realmente depende do tipo de tráfego, ao que parece. O Playstation4 também leva mais tempo para baixar jogos ou patches no túnel. Quando estiver em casa, farei um túnel diretamente entre dois Rbps, que estão em locais diferentes, mas use o mesmo ISP. Eu fiz isso antes e os resultados foram quase os mesmos. Mas eu tento fazer mais testes.

— Alexander Theißen 7/03/16