ทรูพุต TCP OpenVPN ที่ต่ำมาก (พอร์ต 100Mbit, การใช้งาน CPU ต่ำ)

ฉันพบอัตราการถ่ายโอน OpenVPN ที่ช้ามากระหว่างเซิร์ฟเวอร์สองแห่ง สำหรับคำถามนี้ฉันจะเรียกเซิร์ฟเวอร์เซิร์ฟเวอร์ A และเซิร์ฟเวอร์ B

ทั้งเซิร์ฟเวอร์ A และเซิร์ฟเวอร์ B กำลังเรียกใช้ CentOS 6.6 ทั้งสองอยู่ในศูนย์ข้อมูลที่มีสาย 100Mbit และการถ่ายโอนข้อมูลระหว่างเซิร์ฟเวอร์ทั้งสองที่อยู่นอก OpenVPN ทำงานใกล้กับ ~ 88Mbps

อย่างไรก็ตามเมื่อฉันพยายามถ่ายโอนไฟล์ใด ๆ ผ่านการเชื่อมต่อ OpenVPN ที่ฉันได้สร้างขึ้นระหว่างเซิร์ฟเวอร์ A และเซิร์ฟเวอร์ B ฉันจะได้รับปริมาณงานประมาณ 6.5Mbps

ผลการทดสอบจาก iperf:

[  4] local 10.0.0.1 port 5001 connected with 10.0.0.2 port 49184
[  4]  0.0-10.0 sec  7.38 MBytes  6.19 Mbits/sec
[  4]  0.0-10.5 sec  7.75 MBytes  6.21 Mbits/sec
[  5] local 10.0.0.1 port 5001 connected with 10.0.0.2 port 49185
[  5]  0.0-10.0 sec  7.40 MBytes  6.21 Mbits/sec
[  5]  0.0-10.4 sec  7.75 MBytes  6.26 Mbits/sec

นอกเหนือจากการทดสอบ IPV ของ OpenVPN แล้วเซิร์ฟเวอร์ทั้งสองไม่ได้ใช้งานอย่างสมบูรณ์โดยไม่มีการโหลดเป็นศูนย์

เซิร์ฟเวอร์ A ถูกกำหนด IP 10.0.0.1 และเป็นเซิร์ฟเวอร์ OpenVPN เซิร์ฟเวอร์ B ได้รับการกำหนด IP 10.0.0.2 และเป็นไคลเอนต์ OpenVPN

การกำหนดค่า OpenVPN สำหรับเซิร์ฟเวอร์ A เป็นดังนี้:

port 1194
proto tcp-server
dev tun0
ifconfig 10.0.0.1 10.0.0.2
secret static.key
comp-lzo
verb 3

การกำหนดค่า OpenVPN สำหรับเซิร์ฟเวอร์ B เป็นดังนี้:

port 1194
proto tcp-client
dev tun0
remote 204.11.60.69
ifconfig 10.0.0.2 10.0.0.1
secret static.key
comp-lzo
verb 3

สิ่งที่ฉันสังเกตเห็น:

1.ความคิดแรกของฉันคือฉันกำลังคอขวด CPU บนเซิร์ฟเวอร์ OpenVPN เป็นแบบเธรดเดียวและเซิร์ฟเวอร์ทั้งสองนี้ใช้โปรเซสเซอร์ Intel Xeon L5520 ซึ่งไม่ใช่วิธีที่เร็วที่สุด อย่างไรก็ตามฉันรันtopคำสั่งระหว่างหนึ่งในการทดสอบ iperf และกด1เพื่อดูการใช้ CPU โดยหลักและพบว่าโหลด CPU ต่ำมากในแต่ละคอร์:

top - 14:32:51 up 13:56,  2 users,  load average: 0.22, 0.08, 0.06
Tasks: 257 total,   1 running, 256 sleeping,   0 stopped,   0 zombie
Cpu0  :  2.4%us,  1.4%sy,  0.0%ni, 94.8%id,  0.3%wa,  0.0%hi,  1.0%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.3%st
Cpu3  :  0.3%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu8  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu9  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu10 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu11 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu12 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu13 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu14 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu15 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    946768k total,   633640k used,   313128k free,    68168k buffers
Swap:  4192188k total,        0k used,  4192188k free,   361572k cached

2.เวลาในการปิงเพิ่มขึ้นอย่างมากเหนืออุโมงค์ OpenVPN ขณะที่ iperf กำลังทำงาน เมื่อ iperf ไม่ทำงานเวลา ping เหนืออุโมงค์นั้นสม่ำเสมอ 60ms (ปกติ) แต่เมื่อ iperf ทำงานและผลักดันการรับส่งข้อมูลจำนวนมากเวลา ping จะไม่แน่นอน คุณสามารถดูด้านล่างว่าเวลา ping จะเสถียรจนถึง ping ที่ 4 เมื่อฉันเริ่มต้นการทดสอบ iperf:

PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=60.1 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=60.1 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=60.2 ms
** iperf test begins **
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=146 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=114 ms
64 bytes from 10.0.0.2: icmp_seq=6 ttl=64 time=85.6 ms
64 bytes from 10.0.0.2: icmp_seq=7 ttl=64 time=176 ms
64 bytes from 10.0.0.2: icmp_seq=8 ttl=64 time=204 ms
64 bytes from 10.0.0.2: icmp_seq=9 ttl=64 time=231 ms
64 bytes from 10.0.0.2: icmp_seq=10 ttl=64 time=197 ms
64 bytes from 10.0.0.2: icmp_seq=11 ttl=64 time=233 ms
64 bytes from 10.0.0.2: icmp_seq=12 ttl=64 time=152 ms
64 bytes from 10.0.0.2: icmp_seq=13 ttl=64 time=216 ms

3.ดังกล่าวข้างต้นฉันวิ่ง iperf นอกอุโมงค์ OpenVPN และปริมาณงานปกติ - ~ 88Mbps อย่างสม่ำเสมอ

สิ่งที่ฉันได้ลอง:

1.ฉันคิดว่าการบีบอัดอาจทำให้เปรอะเปื้อนดังนั้นฉันจึงปิดการบีบอัดด้วยการลบcomp-lzoทั้งจาก configs และเริ่ม OpenVPN ใหม่ ไม่มีการปรับปรุง

2.แม้ว่าก่อนหน้านี้ฉันพบว่าการใช้งาน CPU ต่ำ แต่ฉันคิดว่ารหัสเริ่มต้นอาจมีความเข้มข้นน้อยเกินไปสำหรับระบบที่จะติดตาม ดังนั้นฉันจึงเพิ่มcipher RC2-40-CBCการตั้งค่าทั้งสอง (รหัสที่มีน้ำหนักเบามาก) และเริ่ม OpenVPN ใหม่ ไม่มีการปรับปรุง

3.ฉันอ่านฟอรัมต่าง ๆ เกี่ยวกับวิธีปรับแต่งส่วน mssfix และ mtu-tun อาจช่วยประสิทธิภาพ ฉันเล่นกับรูปแบบต่าง ๆ ตามที่อธิบายไว้ในบทความนี้แต่ไม่มีการปรับปรุง

มีความคิดเห็นเกี่ยวกับสิ่งใดบ้างที่อาจทำให้ประสิทธิภาพของ OpenVPN แย่ลง?

หลังจาก Googling และไฟล์ปรับแต่งปรับแต่งมากมายฉันพบวิธีแก้ปัญหา ตอนนี้ฉันได้รับความเร็วที่ยั่งยืนที่ 60Mbps และสูงถึง 80Mbps มันช้ากว่าอัตราการถ่ายโอนเล็กน้อยที่ฉันได้รับนอก VPN แต่ฉันคิดว่ามันดีพอ ๆ กับที่จะได้รับ

ขั้นตอนแรกคือการตั้งค่าsndbuf 0และrcvbuf 0ในการกำหนดค่า OpenVPN สำหรับทั้งเซิร์ฟเวอร์และไคลเอนต์

ฉันทำการเปลี่ยนแปลงนั้นหลังจากที่เห็นข้อเสนอแนะให้ทำในโพสต์สาธารณะในฟอรัม (ซึ่งเป็นคำแปลภาษาอังกฤษของโพสต์ดั้งเดิมของรัสเซีย ) ที่ฉันจะพูดที่นี่:

มันคือเดือนกรกฎาคม 2004 ความเร็วอินเทอร์เน็ตในบ้านปกติในประเทศที่พัฒนาแล้วคือ 256-1024 Kbit / s ในประเทศที่พัฒนาน้อยกว่าคือ 56 Kbit / s Linux 2.6.7 ได้รับการเผยแพร่เมื่อไม่นานมานี้และ 2.6.8 ซึ่งการปรับขนาด TCP Windows จะเปิดใช้งานโดยค่าเริ่มต้นจะเปิดตัวในเดือนเดียวเท่านั้น OpenVPN กำลังพัฒนาอย่างต่อเนื่องเป็นเวลา 3 ปีแล้วเวอร์ชั่น 2.0 เกือบจะวางจำหน่ายแล้ว หนึ่งในนักพัฒนาตัดสินใจที่จะเพิ่มรหัสสำหรับซ็อกเก็ตบัฟเฟอร์ฉันคิดว่าการรวมขนาดบัฟเฟอร์ระหว่าง OS ใน Windows มีบางอย่างผิดปกติกับ MTU ของอะแดปเตอร์หากมีการตั้งค่าขนาดบัฟเฟอร์ที่กำหนดเองดังนั้นในที่สุดจะเปลี่ยนเป็นรหัสต่อไปนี้:

#ifndef WIN32
o->rcvbuf = 65536;
o->sndbuf = 65536;
#endif

หากคุณใช้ OpenVPN คุณควรรู้ว่าสามารถทำงานผ่าน TCP และ UDP ได้ หากคุณตั้งค่าบัฟเฟอร์ซ็อกเก็ต TCP แบบกำหนดเองให้ต่ำเป็น 64 KB อัลกอริทึมการปรับขนาดหน้าต่าง TCP ไม่สามารถปรับขนาดหน้าต่างเป็นมากกว่า 64 KB นั่นหมายความว่าอย่างไร? นั่นหมายความว่าหากคุณกำลังเชื่อมต่อกับเว็บไซต์ VPN อื่น ๆ ผ่านลิงค์ที่มีความยาวมากเช่นสหรัฐอเมริกาไปยังรัสเซียด้วยการ ping ประมาณ 100 ms คุณจะไม่สามารถรับความเร็วได้มากกว่า 5.12 Mbit / s ด้วยการตั้งค่าบัฟเฟอร์ OpenVPN เริ่มต้น คุณต้องการบัฟเฟอร์อย่างน้อย 640 KB เพื่อรับ 50 Mbit / s ผ่านลิงก์นั้น UDP จะทำงานได้เร็วขึ้นเนื่องจากไม่มีขนาดหน้าต่าง แต่จะไม่ทำงานอย่างรวดเร็ว

ในขณะที่คุณอาจเดาได้ว่ารุ่นล่าสุดของ OpenVPN ยังคงใช้ขนาดบัฟเฟอร์ซ็อกเก็ต 64 KB เราควรแก้ไขปัญหานี้อย่างไร วิธีที่ดีที่สุดคือไม่อนุญาตให้ OpenVPN ตั้งขนาดบัฟเฟอร์ที่กำหนดเอง คุณควรเพิ่มรหัสต่อไปนี้ในทั้งเซิร์ฟเวอร์และไฟล์ปรับแต่งไคลเอนต์:

sndbuf 0
rcvbuf 0

ผู้เขียนอธิบายต่อไปถึงวิธีการปรับขนาดบัฟเฟอร์ให้กับไคลเอ็นต์หากคุณไม่ได้ควบคุมการกำหนดค่าไคลเอ็นต์ด้วยตนเอง

หลังจากที่ฉันทำการเปลี่ยนแปลงเหล่านั้นอัตราความเร็วของฉันจะสูงถึง 20Mbps ฉันเห็นว่าการใช้งาน CPU สูงเพียงเล็กน้อยบนแกนเดียวดังนั้นฉันจึงลบcomp-lzo(บีบอัด) ออกจากการกำหนดค่าทั้งไคลเอนต์และเซิร์ฟเวอร์ ยูเรก้า! ความเร็วในการถ่ายโอนเพิ่มขึ้นถึง 60Mbps และ 80Mbps

ฉันหวังว่าสิ่งนี้จะช่วยให้คนอื่นแก้ไขปัญหาของตัวเองด้วยความช้าของ OpenVPN!

หลังจากพยายามแล้วฉันก็ไปถึงทางออกที่ดี ในกรณีของฉันการตอบกลับของ @ Elliot ไม่ได้ช่วยอะไร ยิ่งไปกว่านั้นฉันพบข้อมูลโค้ดนี้เพื่อเพิ่มลงในการกำหนดค่าเซิร์ฟเวอร์ที่ทำให้งานสำเร็จ

sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"

ฉันมีเซิร์ฟเวอร์ OpenVPN เล็ก ๆ น้อย ๆ ที่ทำงานบนราสเบอร์รี่ PI3และตอนนี้ฉันได้รับ71 Mbps downlink และ 16mbps อัปลิงค์ การดาวน์โหลดถูก จำกัด เนื่องจากพลังงานของ CPU ตอนนี้การกำหนดค่าของฉันมีดังต่อไปนี้:

client-to-client
duplicate-cn
keepalive 10 120
cipher AES-128-CBC
#cipher AES-256-CBC <<<---- lowers the speed to around 50Mbps, still not bad
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
tun-mtu 9000

OpenVPN 2.4.0 arm-unknown-linux-gnueabihf พร้อม OpenSSL 1.0.2l

รู้สึกแปลก ๆ ว่าปัญหาดังกล่าวเกี่ยวกับการกำหนดค่าเริ่มต้นของบัฟเฟอร์ยังคงมีอยู่

[แก้ไข]ไฟล์ client.ovpn ของฉันมีโครงสร้างดังนี้:

client
dev tun
proto tcp
remote SERVER.IP.ADDRESS.HERE
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ns-cert-type server
tun-mtu 9000
key-direction 1
cipher AES-128-CBC
comp-lzo
verb 1
mute 20
<ca>
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN RSA PRIVATE KEY-----
[...]
-----END RSA PRIVATE KEY-----
</key>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
[...]
-----END OpenVPN Static key V1-----
</tls-auth>

ตามการกำหนดค่าของคุณใช้ TCP เป็นการขนส่งสำหรับอุโมงค์ พิจารณาการใช้ UDP แทน TCP ตั้งแต่เต้ารับการเชื่อมต่อ TCP แบบเรียงซ้อนเพื่อสร้างปัญหาในสถานการณ์การสูญเสียแพ็กเก็ต

จากการอ้างอิงดูทำไม TCP เกิน TCP เป็นความคิดที่ไม่ดี

เรามีเซิร์ฟเวอร์ข้ามทวีปสองเครื่องที่เชื่อมโยงถึงกันความเร็วระหว่างเซิร์ฟเวอร์ทั้งสองนั้นอยู่ที่ประมาณ 220 Mbit / s

ภายในอุโมงค์ OpenVPN (UDP) ความเร็วจะเฉลี่ยที่ 21 Mbit / s - ช้าลงประมาณ 10 เท่า

(มีความหน่วงแฝงที่สำคัญระหว่างเซิร์ฟเวอร์: ประมาณ 130 มิลลิวินาทีและการถ่ายโอนถูกวัดโดยใช้ Iperf3 ในโหมด TCP)

ลองคำแนะนำทั้งหมดเกี่ยวกับคำตอบที่นี่ในการเขียนนี้และไม่มีอะไรช่วย

สิ่งหนึ่งที่ในที่สุดก็ช่วยได้ก็คือ:

--txqueuelen 4000

ตามคู่มืออ้างอิงของ OpenVPN:

–txqueuelen n 
(Linux only) Set the TX queue length on the TUN/TAP interface. Currently defaults to 100.

หลังจากตั้งค่าพารามิเตอร์นี้บนเซิร์ฟเวอร์และไคลเอนต์ฉันก็สามารถเข้าถึงความเร็ว 'direct-link' เดียวกัน (~ 250Mbit / s) ภายใต้อุโมงค์ OpenVPN

ฉันใช้แล้วrcvbuf 0และsndbuf 0อย่างน้อยก็คนเดียวก็ไม่ได้ช่วยอะไรเลย

ฉันได้พบคำแนะนำเหล่านี้ทั้งใน: หน้านี้ในฟอรั่ม OpenVPNและยังอยู่ในหน้านี้ในวิกิพีเดีย UDPspeeder

ในหมายเหตุอื่น: ฉันสามารถเข้าถึงความเร็วที่สูงขึ้นโดยใช้การถ่ายโอน UDP ใน iperf แต่การทำเช่นนั้นจะต้องเสียแพ็คเก็ตที่สูงพอสมควร

หากมีโอกาสที่คุณจำเป็นต้องใช้ VPN ในการขุดอุโมงค์สองแห่งที่มีลิงก์ที่สูญเสียฉันขอแนะนำให้คุณพิจารณาการใช้การส่งต่อข้อผิดพลาด (FEC) ในอุโมงค์ภายใต้ VPN เอง สองสิ่งที่ฉันจัดการเพื่อค้นหาและทำงานด้วยคือ:

• UDPspeeder ที่กล่าวมาข้างต้นซึ่งเชื่อมต่อกับ UDP
• kcptunซึ่งเชื่อมต่อการเชื่อมต่อ TCP;

ทั้งสองสามารถช่วยได้มากกับ packetloss (โดยใช้แบนด์วิดท์มากขึ้นในตอนแรก) และในที่สุดก็นำไปสู่การรับส่งข้อมูลที่สูงขึ้นแม้จะมีโอเวอร์เฮดที่เพิ่มขึ้น

(นั่นเพราะแพ็คเก็ตการสูญเสียสามารถยุ่งจริงๆค่าเครือข่ายโดยเฉพาะ TCP .ดูรายละเอียดหน้า 6)

ฉันต้องการใช้ OpenVPN บน UDP ด้วยเหตุผลทั้งหมด แต่ฉันพบว่ามันยากที่จะจัดการกับ UDPspeeder เมื่อคุณมีเวลาแฝงมากกว่า 100ms &> 10 Mbit / s speed

kcptun อย่างไรก็ตามทำงานได้ดีกับ tweaking น้อยมากและจริง ๆแล้วเซิร์ฟเวอร์ของเราเพิ่มปริมาณงานกันมากขึ้น =)

บนโน้ตขยายที่นี่คุณสามารถหาคำอธิบายรายละเอียดเพิ่มเติมเกี่ยวกับการปรับเปลี่ยนบางส่วนของผลการดำเนินงาน OpenVPN

สำหรับฉันฉันมีเซิร์ฟเวอร์ VPS พร้อมการตั้งค่าเซิร์ฟเวอร์ openvpn ในญี่ปุ่นและการเชื่อมต่อไคลเอ็นต์ของฉันใช้ DDWRT ในโหมดไคลเอนต์ OpenVPN ใน NYC ฉันได้รับเพียง 1-2mbps กับการเชื่อมต่อ 100mbit ที่ดีที่สุดที่ฉันสามารถปรับให้เหมาะสมคือ 5mbps ซึ่งเพียงพอสำหรับสิ่งที่ฉันต้องการซึ่งปรับให้เหมาะสมที่สุดเท่าที่ฉันจะทำได้

การตั้งค่าเซิร์ฟเวอร์ OpenVPN ของฉัน:

tun-mtu 9000
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"
comp-lzo
txqueuelen 4000
######
port 10111
proto udp
dev tun
user nobody
group nobody
persist-key
persist-tun
keepalive 10 120
topology subnet
server x.x.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 1.0.0.1"
push "dhcp-option DNS 1.1.1.1"
push "redirect-gateway def1 bypass-dhcp"
dh none
ecdh-curve prime256v1
#tls-crypt tls-crypt.key 0
crl-verify crl.pem
ca ca.crt
cert server_IzA1QdFzHLRFfEoQ.crt
key server_IzA1QdFzHLRFfEoQ.key
auth SHA256
#cipher AES-128-GCM
#cipher AES-128-CBC
#ncp-ciphers AES-128-GCM
#ncp-ciphers AES-128-CBC
#tls-server
#tls-version-min 1.2
#tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
#tls-cipher TLS-DHE-RSA-WITH-AES-128-CBC-SHA
status /var/log/openvpn/status.log
verb 3

การตั้งค่าไคลเอนต์ DDWRT OpenVPN ของฉันยังเห็นในภาพหน้าจอของฉัน:

tun-mtu 9000
comp-lzo
##########
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verify-x509-name server_IzA1QdFzHLRFfEoQ name
auth SHA256
auth-nocache
setenv opt block-outside-dns # Prevent Windows 10 DNS leak
verb 3