ฉันจะปรับปรุงความน่าเชื่อถือ OpenVPN ผ่านลิงก์เวลาแฝงสูงได้อย่างไร

11

เรากำลังเรียกใช้ OpenVPN VPN ผ่านลิงก์ดาวเทียม BGAN โดยมีเวลา ping ประมาณ 3 วินาที เราใช้มันในการกำหนดค่าtunและเรากำลังทำงานบน Linux (CentOS) เป็นอีเมลหลักที่จะถูกส่งผ่านลิงก์ แต่ทันทีที่อีเมลมีไฟล์แนบขนาดใหญ่ VPN ดูเหมือนจะหยุดทำงาน

"ผมสามารถ ping ผ่านอุโมงค์ แต่การทำงานจริงใด ๆ ทำให้เกิดการล็อคขึ้น. นี่คือปัญหา MTU?" คำถามในคำถามที่พบบ่อยเกี่ยวกับ OpenVPN ดูเหมือนว่าจะอธิบายปัญหาของฉันอย่างแน่นอน แต่การใช้งานmssfixและfragmentยังไม่ได้ทำอะไรมากมายเพื่อปรับปรุงสถานการณ์

การทดสอบหลักของฉันคือการคัดลอกไฟล์ 2MB มากกว่า VPN กับSCP มันจะคัดลอกประมาณ 192kbytes แล้วรายงาน a - จนตรอก -รัฐ หากฉันรอสองสามวินาทีมันจะเริ่มการคัดลอกอีกครั้งจากนั้นหยุดอีกครั้งหลังจากนั้นสองสามกิโลไบต์

การหยุดนี้เกิดขึ้นหรือไม่ว่าฉันได้ตั้งค่าfragmentหรือmssfixตัวเลือกในการกำหนดค่า OpenVPN ของฉัน (แม้ว่าการตั้งค่าfragment 1000ดูเหมือนจะลดการถ่วงเวลา แต่ไม่ได้กำจัด) OpenVPN mtu-testรายงานว่า 1542 เป็นขนาด MTU

ฉันได้ค้นหาอินเทอร์เน็ตสำหรับคำแนะนำเพิ่มเติมเกี่ยวกับวิธีการและเมื่อใช้mssfixและfragmentแต่ฉันเพียง แต่หาหน้าพูดเช่นเดียวกับคำถามที่พบบ่อยและไม่ได้ให้รายละเอียดเป็นวิธีการและเมื่อใช้พารามิเตอร์

คำถามของฉันคือ:

ฉันจะใช้mssfixและเมื่อfragmentใด
ฉันจะใช้mssfixและfragmentรวมกันหรือไม่
ถ้าmssfixและfragmentเป็นวิธีการแก้สิ่งที่เป็นtun-mtu, link-mtuและmtu-discพารามิเตอร์สำหรับการ?

นอกจากนี้ฉันใช้เครื่องมือiperfเพื่อวัดแบนด์วิดธ์ หากไม่มี VPN จะมีการวัดตามลำดับอย่างน้อย 210Kbits / วินาที

เมื่อใช้iperfผ่าน VPN ( $ iperf -c remoteserver -t60 -i5) มันจะเริ่มต้นที่ 10Kbits / วินาทีจากนั้นขึ้นไปเรื่อย ๆ จนกระทั่งรายงาน 1.2Mbits / วินาทีและจากนั้นมันจะหยุดทำงานซึ่งจะรายงาน 0kbits / วินาทีสำหรับการวนซ้ำ (I คิดว่า 1.2Mbits / วินาทีอาจเป็นเพราะ OpenVPN บางตัวทำการบัฟเฟอร์หรืออื่น ๆ )

คือiperfวิธีที่ดีที่สุดในการวัดแบนด์วิดธ์?

ความช่วยเหลือใด ๆ กับสถานการณ์นี้จะได้รับการชื่นชมอย่างมาก

openvpn

— iWerner
แหล่งที่มา

openvpn ใช้ TCP หรือ UDP ในขณะนี้หรือไม่?

— pjc50

ขณะนี้ใช้ UDP

— iWerner

ขอบคุณสำหรับคำตอบทั้งหมด แต่ฉันต้องหยุดชั่วคราวเพราะหน่วย BGAN หมดเวลาออกอากาศ วันนี้ฉันหวังว่าจะได้รับ cointinue ฉันควรจะพูดถึงว่าเราต้องการอยู่กับ UDP เช่นใช้ TCP จะเป็นคู่ของข้อมูลที่ส่งผ่านเครือข่าย (และด้วยเหตุนี้ค่าใช้จ่ายสำหรับการที่ลูกค้าของเราที่มีอยู่แล้วมีความละเอียดอ่อนมาก)

— iWerner

5

ค.ศ. 1542 ในฐานะ MTU ไม่เคยได้ยินเรื่องนี้สำหรับลิงค์ WAN โดยปกติแล้ว MTU คือขนาดบรรจุสูงสุดขนาดแพ็คเก็ต ip ลบส่วนหัวสำหรับ IP (20 ไบต์) และ ICMP (8 ไบต์) นั่นหมายถึง MTU = 1500 สำหรับ Ethernet LAN แบบดั้งเดิม นอกจากนี้ VPN ส่วนใหญ่แนะนำค่าใช้จ่ายสำหรับการห่อหุ้มแพ็กเก็ต VPN MTU ทั่วไปคือ 1400

ในเครือข่ายสมัยใหม่มันเป็นเรื่องยากที่จะสรุปว่า MTU จะเป็นอย่างไรในเวลาใดก็ได้เนื่องจากเส้นทางการเข้าและออกอาจแตกต่างกันและอาจเปลี่ยนแปลงได้เนื่องจากการกำหนดเส้นทางใหม่โดยอัตโนมัติ สำหรับเครือข่ายเช่นนี้อาจมีประสิทธิภาพมากกว่าในการตั้งค่า MTU ให้ต่ำบนโฮสต์ของคุณที่อยู่ด้านใดด้านหนึ่งของลิงก์ VPN เช่น 576

MSS (ขนาดเซกเมนต์สูงสุด) คือ MTU ลบส่วนหัว IP + TCP (40 ไบต์) โดยทั่วไปจะมีการเจรจาต่อรองโดยสแต็กเครือข่ายและมักจะไม่มีปัญหาการเจรจาเช่นเดียวกับ MTU เว้นแต่ว่า MTU จะผิด (โดยทั่วไปการเจรจาต่อรองของ MTU จะถูกทำให้ผิดปกติโดย ICMP หรือเราเตอร์หลุมดำที่ถูกบล็อก)

สิ่งแรกที่ฉันจะทำคือจับแพ็คเก็ตเครือข่ายที่ปลายส่งของคุณและเรียงลำดับการแสดงผลตามขนาดเฟรม (คุณอาจต้องเพิ่มคอลัมน์นี้ใน Wireshark) คุณควรตรวจสอบว่าคุณไม่ได้ส่งเฟรมใด ๆ ที่มีขนาดใหญ่เกินไปสิ่งที่คุณคาดหวังว่าจะเป็น ไม่ใช่เรื่องผิดปกติสำหรับการ์ดเครือข่ายที่ทันสมัยในการส่งเฟรมขนาดใหญ่ถ้าตัวเลือกเช่น Large Send Offload หรือ Jumbo Frames เปิดใช้งาน ฉันเห็นเฟรมมากกว่า 30,000 ไบต์เมื่อเปิดใช้งานตัวเลือกเหล่านี้

— เกร็กเบน
แหล่งที่มา

+1 สำหรับการจับแพ็คเก็ตก่อนที่จะเปลี่ยนแปลงอะไร แม้ว่าคุณจะไม่พบกรอบขนาดใหญ่ใด ๆ คุณอาจเห็นแพ็คเก็ต 'ปกติ' กระจัดกระจายอยู่ที่ไหนสักแห่ง

— Javier

1

ตามค่าเริ่มต้น OpenVPN จะตั้งค่า MTU ของอุปกรณ์รับสัญญาณเป็น 1500 (ซึ่งเหมือนกับ MTU บนอุปกรณ์อีเธอร์เน็ตบนเครื่องของเรา) ฉันยังไม่แน่ใจว่าการแยกส่วนของแพ็กเก็ต VPN เป็นสิ่งที่ดีหรือไม่ดี คำตอบในกระทู้นี้ดูเหมือนจะบ่งบอกว่ามันไม่ดีในขณะที่การอ้างอิงอื่น ๆ ที่ฉันพบบนเว็บแสดงถึงว่ามันเป็นสิ่งที่ดี

— iWerner

2

@iwerner: คุณพยายามกำหนดขนาดของ mtu ด้วย ping ไหม? หาก ICMP ไม่ถูกปิดการใช้งานในที่ใดที่หนึ่งคุณสามารถใช้สิ่งต่อไปนี้บน windows: ping -f -l 1372 <ปลายทาง ip> ลดจำนวนลงเรื่อย ๆ จนกว่าจะสำเร็จ บน linux, ping -s 1372 -M ทำ <ปลายทาง ip> FYI, คำถามที่พบบ่อยเกี่ยวกับ OpenVPN แนะนำให้ใช้ mssfix 1200 แต่ไม่ได้ระบุสาเหตุของปัญหา การใช้โซลูชัน VPN เพื่อแยกส่วนจะมีศักยภาพสำหรับประสิทธิภาพในการทำงาน หากคุณมีการตั้งค่า VPN ที่มีขนาดใหญ่คุณจะไม่สามารถใช้การแยกส่วนบนปลายหัวกลางเพียงปลายสำนักงานระยะไกล

— เกร็ก Askew

2

เพิ่งอยากรู้อยากเห็นคุณลองลด MTU ของอินเตอร์เฟสเครือข่ายหรือไม่? บางทีลิงก์ดาวเทียมอาจทำให้การกระจายตัวไม่ดี ในฐานะที่เป็นโน้ตต่อต้านคุณอาจลอง openvpn ผ่าน TCP สำหรับการเปลี่ยนแปลง ฉันรู้ว่ามันควรลดการแสดง แต่ถ้าคุณไม่มีการควบคุมการกระจายตัวตามเส้นมันอาจช่วยคุณได้

— lorenzog
แหล่งที่มา

ฉันกำลังจะแนะนำสิ่งที่ตรงกันข้าม :) - กรณีความล่าช้าสูงนี้เป็นกรณีที่ปัญหา TCP-in-TCP ปรากฏขึ้นและ UDP จะหลีกเลี่ยงปัญหานั้น

— pjc50

ฉันคิดว่าเขากำลังใช้พอร์ต UDP ที่เป็นค่าเริ่มต้นสำหรับ openvpn ดังนั้นจึงแนะนำสิ่งที่ตรงกันข้าม .. ใช่โดยปกติฉันจะเห็นด้วยกับคุณ แต่เดี๋ยวก่อนเราทุกคนรู้ว่าดูแลระบบคือการทดลองและข้อผิดพลาดและมัก 'ลองทำที่ตรงข้ามดูถ้ามันงาน' :)

— lorenzog

ขอบคุณ ขณะนี้เรากำลังใช้ UDP อยู่และการลองใช้ TCP ไม่เคยเกิดขึ้นกับฉัน (ถ้าฉันมีตัวแทนมากขึ้นฉันจะได้

— upvoting

@iWerner: ขอบคุณ :) ลองลด MTU อย่างต่อเนื่องบน iface และดูว่ามันหยุดเมื่อไหร่ (ถ้ามี)

— lorenzog

2

เมื่อคุณใช้ TCP เพิ่มขนาดหน้าต่างของ TCP วิธีนี้จะช่วยในการ "จำนวนของแพ็คเก็ตในอากาศ"

ไม่นานมานี้ฉันต้องเล่นกับสิ่งนี้ แต่นี่คือลิงค์เดียวที่Google พบสำหรับฉัน

หลังจากที่ฉันได้อ่านคำถามของคุณอีกครั้งฉันเห็นว่าคุณกำลังใช้งาน BGAN - ฉันมีลักษณะที่ดีในเรื่องนี้ (หรือเพียงแค่ google สำหรับ: "BGAN การปลอมแปลง")

สำหรับการวัดแบนด์วิดท์ฉันพบว่า iperf นั้นค่อนข้างดีตราบใดที่คุณใช้ขนาดแพ็คเก็ตที่เหมาะสม

— ไหลวน
แหล่งที่มา

สิ่งนี้น่าสนใจ - กล่าวว่าตัวเร่งความเร็ว TCP พร้อมใช้งานสำหรับ Redhat ในขณะที่คน inmarsat ที่เราพูดถึงบอกว่ามันมีเฉพาะสำหรับ Windows และ OS X (และนี่เป็นสิ่งที่เว็บไซต์ Inmarsat / BGAN พูด)

— iWerner

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

— Eddy

ฉันวิ่งหนีจากผู้ให้บริการดาวเทียมของเรา ยากที่จะหาคนที่รู้ว่าพวกเขากำลังพูดถึงอะไร ฉันจะพยายามต่อไปในระหว่างนี้นี่คือสิ่งที่ต้องลอง: sourceforge.net/projects/pepsalจากรายละเอียดโครงการมันกำลังทำอะไรที่ซอฟแวร์ Inmarsat กำลังทำอยู่: PEPsal เป็น TCP แบบบูรณาการหลายชั้นและโปร่งใส Performance Enhancing Proxy ซึ่งแยกการเชื่อมต่อออกเป็นสองส่วนโดยใช้การปรับปรุง Linux TCP เมื่อส่งข้อมูลและส่วนใหญ่จะปรับปรุงประสิทธิภาพในการเชื่อมโยงที่มีคุณสมบัติแตกต่างกัน

— 539 Eddy

2

ฉันคิดว่าคุณอาจเห่าที่ผิดต้นไม้ เมื่อใดก็ตามที่ฉันมีปัญหาเกี่ยวกับ MTU ผิดพลาดการจราจรจะหยุดก่อน 192KB ฉันคิดว่ามันเกี่ยวข้องกับบางอย่างในหน้าต่าง "ในแพ็คเก็ตเที่ยวบิน" ไม่ว่าจะเป็นหน้าต่าง TCP หรือบัฟเฟอร์บางส่วนในอัปลิงค์ดาวเทียม

ทำการจับแพ็คเก็ตแบบยาว ๆ อย่างแน่นอน (ทั้ง 'ภายใน' และ 'นอก' ของ VPN) และดูว่าคุณได้รับข้อมูลทั้งหมดACKหรือไม่

— ฮาเวียร์
แหล่งที่มา