OpenVPN a basse prestazioni. Ho problemi di MTU? Discariche dentro

Ho dei problemi con un tunnel OpenVPN che non raggiunge la velocità della linea. Il gateway è un server virtuale Debian Jessy ospitato su OVH. Il client è o il mio homeserver freebsd 10.2 (Intel I3 Ivy Bridge) o il mio RaspberryPI2. Ho disattivato la crittografia e l'autenticazione. Ho una connessione FTTH simmetrica a 100 mbit / s, ma il tunnel raggiunge solo una velocità di 20-40 mbit / s. La connessione diretta (senza tunnel) produce sempre i 100 mbit / s che mi aspetto. Ho testato le prestazioni con iperf3. Ho provato per la prima volta con il mio homeserver freebsd. Ho provato tutte le impostazioni consigliate su mssfix, frammento ecc. Nulla ha aiutato.

Poi ho pensato che forse è la mia macchina freebsd. Quindi ho installato una nuova raspbian Jessy sul mio RPI2 e ho fatto alcuni test più approfonditi:

Prima di tutto ho rimosso tutte le impostazioni MTU dalle configurazioni OpenVPN e ho lasciato che il percorso MTU gestisse le cose (si spera). Dal momento che non ho un firewall attivo su entrambe le macchine, dovrebbe funzionare. Queste sono le mie configurazioni 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

Prima di tutto il test senza tunnel per dimostrare che la connessione al server è effettivamente quasi 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.

I pacchetti di questa connessione ho scaricato con tcpdump sul server. Puoi scaricarli qui (devi estrarlo per aprirli con WireShark): dumpraw.cap.xz

Ecco come appare un dump "OK". La dimensione massima del fotogramma che ho individuato è 1514.

Ora ho eseguito il test sul tunnel:

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. Non più così carino. Soprattutto questa colonna "Retr" non ha un bell'aspetto. Ho pensato che questo fosse il ritrasmettere TCC e quindi dovrebbe esserci qualcosa nella discarica. Vedremo che non è il caso: /. La CPU non è il collo di bottiglia qui perché ho disattivato la crittografia e l'autenticazione. La CPU è al 20% sul server e al 50% sull'IP durante il test.

Ecco come appare il traffico OpenVPN del test:

Per me questo sembra a posto. Ma non so cosa cercare. Dai un'occhiata al dump con WireShark : dump_physical.cap.xz

Anche il traffico sull'interfaccia del tunnel sembra buono per me. Sembra che abbia abbassato correttamente le dimensioni della cornice (a 1444 come sembra):

Ecco il dump: dump_tunnel.cap.xz

Per me sembra tutto a posto ma non ho davvero idea di cosa cercare esattamente. Ho davvero testato tutto con le impostazioni OpenVPN. Forse qualcuno può dirmi se il traffico sembra a posto.

Quello che mi aspetto come una risposta

Almeno una spiegazione di ciò che sta accadendo qui e perché sembra essere indipendente dal software VPN che utilizzo. Tutto ciò che ho trovato su Internet riguardava i problemi di MTU, ma che dovrebbe essere facilmente risolto riducendo il tunnel MTU o gli altri parametri di OpenVPN. Per me questo cambia poco. Quando si osserva il dump, si nota che riduce le dimensioni del segmento tcp e i pacchetti non vengono frammentati. Ci deve essere qualcos'altro. Mi piace davvero sapere cosa .

Aggiornare

Ho provato questo con strongswan e persino con softether. In realtà è lo stesso problema (velocità comparabile, nessun collo di bottiglia della CPU). Sono davvero perplesso qual è il problema qui. Ho anche provato un altro gateway (RaspberryPi2 su amici 100/100 connessione domestica).

Aggiornamento 2

Ho notato che iperf3 riporta tcp ritrasmissioni (retr) ma non ci sono ritrasmissioni nel dump (Wireshark dovrebbe evidenziarle). Cosa sta succedendo?

Ho anche provato OpenVPN sulla mia rete locale (da RaspberryPi2 a FreebsdServer). Anche lì ho un sacco di ritrasmissioni (su 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

In modalità inversa ho una finestra di congestione davvero strana (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

Aggiornamento 3

L'utilizzo di iperf con udp comporta un blocco temporaneo ovh di quella porta (mi inviano un'email che mi informa di un attacco) e un'enorme perdita di pacchetti:

-----------------------------------------------------------
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 non l'hai ancora fatto, mio essere, puoi provarlo: tun-mtu 9000 fragment 0 mssfix 0(le opzioni devono essere aggiunte in tre righe diverse)

— Diamant,

L'ho già testato. Ma ho provato di nuovo. Quello che è successo è che inizia con la stessa velocità ma poi le connessioni si bloccano. Che tra l'altro succede sempre quando disabilito la frammentazione del pacchetto OpenVPN. Questa guida community.openvpn.net/openvpn/wiki/Gigabit_Networks ti fa pensare che il sistema operativo debba gestirlo, ma ovviamente non lo fa.

— Alexander Theißen,

Oh wow Sto vedendo lo stesso identico comportamento sulle mie VPN e ho hardware robusto ad entrambe le estremità e una connessione Internet più lenta. Ho intenzione di indagare ulteriormente; se trovo qualcosa di concreto, posterò qui.

— Harald,

Se cambio il mio test su UDP (iperf3 -u -b 25m) ottengo la massima velocità sia all'interno che all'esterno del tunnel openvpn. Ho confermato che non c'è frammentazione quando si utilizza TCP: openvpn riporta correttamente un piccolo MSS, i miei pacchetti tcp all'interno del tunnel sono tutti 1354 byte e i pacchetti UDP arrivano senza frammentazione. Sto vedendo lo stesso fenomeno come te: i valori CWND all'interno del tunnel sono circa la metà di quelli che sono al di fuori del tunnel e anche il rendimento è la metà, ma non riesco a spiegarne il perché . Affascinante.

— Harald,

Ok, mi scuso per aver creato false speranze. Nel tentativo di eliminare un sacco di variabili, ho installato un OpenVPN con gli stessi parametri di configurazione, in esecuzione sulla mia LAN locale. Fuori dal tunnel, 750 Mbps. All'interno del tunnel, 117 Mbps. Ma openvpn consumava il 100% di un singolo core della CPU su entrambi gli endpoint. Quindi ho spostato l'endpoint di casa del mio tunnel Internet su un server "reale" e ho visto i 25 Mbps previsti attraverso il mio tunnel. OpenVPN su entrambi gli endpoint consumava circa il 20% di CPU. Per farla breve: nel mio caso, il problema è che il mio endpoint tunnel lato home è associato alla CPU. Scusate!

— Harald,

Tanto per cominciare la tua corsa iperf "normale" al di fuori del tunnel dovrebbe essere UDP / 1194 come flusso su cui hai il problema e non TCP / 5201. Prova prima con -b 100M, ma tieni presente che questo produrrà datagrammi di dimensioni massime che non sono rappresentativi del tuo traffico VPN (le dimensioni del datagramma dovrebbero essere casuali). Sintonizzati con l'opzione -l per la dimensione del datagramma e controlla i risultati. Se i risultati non sono buoni (direi> 15 o 20% di perdita), potresti sospettare un router Internet sovraccarico che sta rilasciando i tuoi pacchetti (probabilmente contrassegnati come il migliore sforzo).

Inoltre, potrebbe essere interessante vedere quali prestazioni ottieni se passi il tuo tunnel VPN a una porta UDP di classe EF (direi 5061 a causa dell'RTP, ma non sei sicuro che tutti i router Internet abbiano configurato correttamente QoS) o qualsiasi Porta TCP.

Per me, non c'è niente di sbagliato nella tua configurazione e la tua diagnostica non mostra nulla di strano. Inoltre, prova un'altra versione di OpenVPN o altro software VPN.

— 30gd4n
fonte

Fatto quello. Guarda update3. In attesa che OVH sblocchi la porta per condurre ulteriori test.

— Alexander Theißen,

Aww, scusa, non ho visto l'ultimo aggiornamento. Durante l'attesa di OVH prova a montare la tua VPN su TCP; quali sono i risultati? Anche sulla tua seconda modifica e la ritrasmissione da * BSD a PI; hai giocato con i buffer del server di iperf? È un valore predefinito di 8kb, non so come sia fatto lo stack su ARM e Linux, ma aumentarlo potrebbe essere d'aiuto.

— 30gd4n

Volevo dire che l'ho aggiunto dopo che me l'hai detto :). I risultati su PCC sono peggiori. Tcp 443 non fa differenza. La cosa divertente è che quando uso questo github.com/sivel/speedtest-cli per i test, riporta 95m in giù e 75m in alto. Mi fido di più di iperf, ma dipende davvero dal tipo di traffico, quindi sembra. Playstation4 richiede anche più tempo per scaricare giochi o patch sul tunnel. A casa farò un tunnel direttamente tra due Rbps che si trovano in posizioni diverse ma usano lo stesso isp. L'ho fatto prima e i risultati erano quasi gli stessi. Ma provo a fare ulteriori test.

— Alexander Theißen