OpenVPN 성능이 저하됩니다. MTU 문제가 있습니까? 내부 덤프

회선 속도에 도달하지 않는 OpenVPN 터널에 문제가 있습니다. 게이트웨이는 OVH에서 호스팅되는 Debian Jessy 가상 서버입니다. 클라이언트는 내 freebsd 10.2 홈 서버 (Intel I3 Ivy Bridge) 또는 내 RaspberryPI2입니다. 암호화 및 인증을 비활성화했습니다. 100mbit / s 대칭 FTTH 연결이 있지만 터널은 20-40mbit / s의 속도에만 도달합니다. 터널없이 직접 연결하면 항상 100mbit / s가 예상됩니다. iperf3로 성능을 테스트했습니다. 먼저 freebsd 홈 서버로 시도했습니다. mssfix, fragment 등에 대한 모든 권장 설정을 시도했습니다.

그렇다면 나는 그것이 내 freebsd 기계라고 생각했습니다. 그래서 나는 RPI2에 신선한 라즈 비안 Jessy를 설치하고 깊이 테스트를 더했습니다.

우선 OpenVPN 구성에서 모든 MTU 설정을 제거하고 경로 MTU가 물건을 처리하도록하십시오. 두 컴퓨터에서 방화벽이 활성화되어 있지 않으므로 작동해야합니다. 이들은 내 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

우선 터널이없는 테스트는 서버와의 연결이 거의 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.

이 연결의 패킷은 서버에서 tcpdump로 덤프했습니다. 여기에서 다운로드 할 수 있습니다 (wireshark로 열려면 압축을 풀어야 함 ) : dumpraw.cap.xz

이것이 "OK"덤프의 모습입니다. 내가 발견 한 최대 프레임 크기는 1514입니다.

이제 터널에서 테스트를 실행했습니다.

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.

으악. 더 이상 좋지 않습니다. 특히이 "Retr"열은 그리 좋아 보이지 않습니다. 나는 이것이 tcp retransmit이라고 가정하고 덤프에 무언가가 있어야합니다. 우리는 그렇지 않다는 것을 알게 될 것입니다 : /. 암호화 및 인증을 비활성화했기 때문에 CPU가 병목 현상이 아닙니다. 테스트 중 CPU는 서버에서 20 %, PI에서 50 %입니다.

테스트의 OpenVPN 트래픽은 다음과 같습니다.

나에게 이것은 괜찮아 보인다. 그러나 나는 무엇을 찾아야할지 모르겠습니다. wireshark가있는 덤프를보십시오 : dump_physical.cap.xz

터널 인터페이스의 트래픽도 나에게 좋아 보인다. 그는 프레임 크기를 올바르게 낮추는 것처럼 보입니다 (1444로 보입니다).

덤프는 다음과 같습니다. dump_tunnel.cap.xz

나에게 이것은 모두 괜찮아 보이지만 정확히 무엇을 찾아야할지 전혀 모른다. OpenVPN 설정으로 모든 것을 실제로 테스트했습니다. 어쩌면 누군가 교통량이 괜찮은지 말해 줄 수 있습니다.

내가 대답으로 기대하는 것

적어도 여기서 일어나는 일과 왜 내가 사용하는 VPN 소프트웨어와 독립적 인 것처럼 보이는지 설명하십시오. 인터넷에서 찾은 모든 것은 MTU 문제에 관한 것이지만 터널 MTU 또는 OpenVPN의 다른 매개 변수를 줄이면 쉽게 해결할 수 있습니다. 나에게 이것은 거의 변하지 않는다. 덤프를 보면 tcp 세그먼트 크기가 줄어들고 패킷이 조각화되지 않음을 알 수 있습니다. 다른 것이 있어야합니다. 나는 정말로 무엇 을 알고 싶습니다 .

업데이트 2

iperf3는 tcp 재전송 (retr)을보고하지만 덤프에는 재전송이 없습니다 (Wireshark가 강조 표시해야 함). 무슨 일이야?

로컬 네트워크 (RaspberryPi2 to FreebsdServer)에서 OpenVPN을 시도했습니다. 심지어 거기에도 많은 재전송이 있습니다 (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

역 모드에서는 정말 이상한 혼잡 창이 있습니다 (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

업데이트 3

idpf를 udp와 함께 사용하면 ovh가 해당 포트를 일시적으로 차단하고 (공격에 대해 알려주는 이메일을 보내줍니다) 엄청난 패킷 손실이 발생합니다.

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

— 알렉산더 테이 센
소스

아직 해보지 않았다면 시도해 볼 수 있습니다. tun-mtu 9000 fragment 0 mssfix 0(옵션은 세 줄로 추가해야합니다)

— Diamant

나는 이미 그것을 간증합니다. 그러나 나는 다시 테스트했다. 일어난 일은 같은 속도로 시작하지만 연결이 중단된다는 것입니다. 그런데 OpenVPN 패킷 조각화를 비활성화하면 항상 발생합니다. 이 안내서 community.openvpn.net/openvpn/wiki/Gigabit_Networks를 통해 OS가 처리해야한다고 생각하지만 분명히 그렇지는 않습니다.

— Alexander Theißen

오 와우. VPN에서 똑같은 동작을보고 있으며 양쪽 끝에 하드웨어가 강하고 인터넷 연결 속도가 느립니다. 더 자세히 조사하겠습니다. 구체적인 내용을 찾으면 여기에 다시 게시하겠습니다.

— Harald

테스트를 UDP (iperf3 -u -b 25m)로 전환하면 openvpn 터널 내부와 외부에서 최고 속도를 얻습니다. TCP를 사용할 때 조각화가 없음을 확인했습니다-openvpn이 작은 MSS를 올바르게보고하고 터널 내부의 tcp 패킷이 모두 1354 바이트이며 UDP 패킷이 조각화되지 않은 채 도착합니다. 터널 내부의 CWND 값은 터널 외부의 값의 절반 정도이며 처리량도 절반이지만, 이유 를 설명하기가 어렵습니다 . 매혹적인.

— Harald

알았어, 거짓 희망을 만들어 줘서 죄송합니다. 모든 변수를 제거하기 위해 로컬 LAN에서 실행되는 동일한 구성 매개 변수로 OpenVPN을 설정했습니다. 터널 외부, 750Mbps 터널 내부 117Mbps 그러나 openvpn은 두 엔드 포인트 모두에서 단일 CPU 코어를 100 % 소비했습니다. 그래서 인터넷 터널의 홈 엔드 포인트를 "실제"서버로 옮기고 터널을 통해 예상되는 25Mbps를 보았습니다. 두 엔드 포인트 모두에서 OpenVPN은 약 20 %의 CPU를 소비했습니다. 짧은 이야기-내 경우에는 문제는 내 홈 터널 끝 점이 CPU에 바인딩되어 있다는 것입니다. 죄송합니다!

— Harald

초보자의 경우 '정상'외부 터널 iperf 실행은 TCP / 5201이 아니라 문제가있는 흐름으로 UDP / 1194 여야합니다. 먼저 -b 100M으로 시도하지만 VPN 트래픽을 대표하지 않는 최대 크기의 데이터 그램을 생성한다는 점을 명심하십시오 (데이터 그램 크기는 다소 임의적이어야 함). 데이터 그램 크기에 -l 옵션을 사용하여 조정하고 결과를 확인하십시오. 결과가 좋지 않으면 (> 15 또는 20 % 손실이라고 말하면) 인터넷 라우터가 과부하되어 (아마 최선의 노력으로 표시된) 패킷을 삭제하는 것으로 의심 될 수 있습니다.

또한 VPN 터널을 EF 클래스 UDP 포트 (RTP로 인해 5061이라고 말하지만 모든 인터넷 라우터가 올바르게 QoS를 구성했는지 확실하지는 않음)로 전환하면 어떤 성능을 얻는 지 흥미로울 수 있습니다. TCP 포트.

나에게는 설정에 아무런 문제가 없으며 진단에 이상한 것이 나타나지 않습니다. 또한 다른 버전의 OpenVPN 또는 다른 VPN 소프트웨어를 사용해보십시오.

— 30gd4n
소스

그거 했어. update3을보십시오. 추가 테스트를 수행하기 위해 ovh가 포트를 차단 해제하기를 기다리는 중입니다.

— Alexander Theißen

죄송합니다. 마지막 업데이트는 보지 못했습니다. OVH를 기다리는 동안 VPN over TCP를 마운트하십시오. 결과는 무엇입니까? 또한 두 번째 편집과 * BSD에서 PI 로의 재전송에 대해서도; iperf의 서버 버퍼를 가지고 놀았습니까? 기본값은 8kb이며 ARM 및 Linux에서 스택이 어떻게 작성되는지 모르지만 스택을 늘리면 도움이 될 것입니다.

— 30gd4n

나는 당신이 나에게 말한 후에 그것을 추가한다는 것을 의미했습니다. :). tcp에 대한 결과가 더 나쁩니다. Tcp 443은 차이가 없습니다. 재미있는 점은이 github.com/sivel/speedtest-cli 를 테스트 할 때 95m 아래로 75m 위로보고한다는 것입니다. 나는 iperf를 더 신뢰하지만 실제로 트래픽 유형에 따라 달라 보입니다. 또한 Playstation4는 터널을 통해 게임이나 패치를 다운로드하는 데 시간이 더 걸립니다. 집에있을 때는 다른 위치에 있지만 동일한 isp를 사용하는 두 Rbps간에 직접 터널을 설정합니다. 나는 전에 그것을했고 거의 동일한 결과를 얻었습니다. 하지만 추가 테스트를 시도합니다.

— Alexander Theißen

OpenVPN 성능이 저하됩니다. MTU 문제가 있습니까? 내부 덤프

내가 대답으로 기대하는 것

최신 정보

업데이트 2

업데이트 3