ipipou: เป็นมากกว่าอุโมงค์ที่ไม่ได้เข้ารหัส

เรากำลังพูดอะไรกับพระเจ้าแห่ง IPv6?

ถูกต้องแล้ว เราจะพูดแบบเดียวกันกับเทพเจ้าแห่งการเข้ารหัสในวันนี้

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

มีโปรโตคอล N tunneling สำหรับทุกรสนิยมและทุกสี:

• มีสไตล์ ทันสมัย ​​อ่อนเยาว์ WireGuard
• มัลติฟังก์ชั่น เช่น มีดสวิส, OpenVPN และ SSH
• GRE เก่าและไม่ชั่วร้าย
• IPIP ที่ง่ายที่สุด รวดเร็ว และไม่มีการเข้ารหัสโดยสมบูรณ์
• การพัฒนาอย่างแข็งขัน เจนีวา
• อื่น ๆ อีกมากมาย

แต่ฉันเป็นโปรแกรมเมอร์ ดังนั้นฉันจะเพิ่ม N เพียงเศษเสี้ยวเดียว และปล่อยให้การพัฒนาโปรโตคอลจริงเป็นหน้าที่ของนักพัฒนา Kommersant

ในครรภ์อันหนึ่ง โครงการสิ่งที่ฉันกำลังทำตอนนี้คือเข้าถึงโฮสต์ที่อยู่เบื้องหลัง NAT จากภายนอก การใช้โปรโตคอลที่มีการเข้ารหัสสำหรับผู้ใหญ่สำหรับสิ่งนี้ ฉันไม่สามารถสั่นคลอนความรู้สึกที่ว่ามันเหมือนกับการยิงนกกระจอกออกจากปืนใหญ่ เพราะ อุโมงค์ส่วนใหญ่ใช้เพื่อเจาะรูใน NAT-e เท่านั้น การรับส่งข้อมูลภายในมักจะถูกเข้ารหัสเช่นกัน แต่ยังคงจมอยู่ใน HTTPS

ในขณะที่ค้นคว้าโปรโตคอลการขุดอุโมงค์ต่างๆ ความสนใจของผู้ชอบความสมบูรณ์แบบภายในใจของฉันถูกดึงไปที่ IPIP ซ้ำแล้วซ้ำอีกเนื่องจากมีค่าใช้จ่ายน้อยที่สุด แต่มีข้อเสียที่สำคัญครึ่งหนึ่งสำหรับงานของฉัน:

• มันต้องมี IP สาธารณะทั้งสองด้าน
• และไม่มีการรับรองความถูกต้องสำหรับคุณ

ดังนั้นผู้สมบูรณ์แบบจึงถูกผลักกลับเข้าไปในมุมมืดของกะโหลกศีรษะหรือที่ใดก็ตามที่เขานั่งอยู่ตรงนั้น

และแล้ววันหนึ่งขณะอ่านบทความเรื่อง อุโมงค์ที่รองรับโดยกำเนิด ใน Linux ฉันเจอ FOU (Foo-over-UDP) เช่น อะไรก็ตาม ห่อด้วย UDP จนถึงขณะนี้รองรับเฉพาะ IPIP และ GUE (การห่อหุ้ม UDP ทั่วไป) เท่านั้น

“นี่คือกระสุนเงิน! IPIP ธรรมดาๆ ก็เพียงพอแล้วสำหรับฉัน” - ฉันคิด.

อันที่จริงกระสุนกลับไม่ใช่สีเงินทั้งหมด การห่อหุ้มใน UDP แก้ปัญหาแรก - คุณสามารถเชื่อมต่อกับไคลเอนต์ที่อยู่เบื้องหลัง NAT จากภายนอกโดยใช้การเชื่อมต่อที่กำหนดไว้ล่วงหน้า แต่นี่คือครึ่งหนึ่งของข้อเสียเปรียบถัดไปของ IPIP ที่บานสะพรั่งในมุมมองใหม่ - ทุกคนจากเครือข่ายส่วนตัวสามารถซ่อนตัวอยู่เบื้องหลังสิ่งที่มองเห็นได้ IP สาธารณะและพอร์ตไคลเอนต์ (ใน IPIP แท้ปัญหานี้ไม่มีอยู่)

เพื่อแก้ไขปัญหาครึ่งนี้ยูทิลิตี้จึงถือกำเนิดขึ้น อิปิปู. ใช้กลไกแบบโฮมเมดสำหรับการตรวจสอบสิทธิ์โฮสต์ระยะไกล โดยไม่รบกวนการทำงานของเคอร์เนล FOU ซึ่งจะประมวลผลแพ็กเก็ตในพื้นที่เคอร์เนลอย่างรวดเร็วและมีประสิทธิภาพ

เราไม่ต้องการสคริปต์ของคุณ!

ตกลง หากคุณทราบพอร์ตสาธารณะและ IP ของไคลเอนต์ (เช่น ทุกคนที่อยู่เบื้องหลังไม่ได้ไปไหน NAT จะพยายามแมปพอร์ต 1-in-1) คุณสามารถสร้างอุโมงค์ IPIP-over-FOU ด้วย ทำตามคำสั่งโดยไม่มีสคริปต์ใดๆ

บนเซิร์ฟเวอร์:

# Подгрузить модуль ядра FOU
modprobe fou

# Создать IPIP туннель с инкапсуляцией в FOU.
# Модуль ipip подгрузится автоматически.
ip link add name ipipou0 type ipip 
    remote 198.51.100.2 local 203.0.113.1 
    encap fou encap-sport 10000 encap-dport 20001 
    mode ipip dev eth0

# Добавить порт на котором будет слушать FOU для этого туннеля
ip fou add port 10000 ipproto 4 local 203.0.113.1 dev eth0

# Назначить IP адрес туннелю
ip address add 172.28.0.0 peer 172.28.0.1 dev ipipou0

# Поднять туннель
ip link set ipipou0 up

บนไคลเอนต์:

modprobe fou

ip link add name ipipou1 type ipip 
    remote 203.0.113.1 local 192.168.0.2 
    encap fou encap-sport 10001 encap-dport 10000 encap-csum 
    mode ipip dev eth0

# Опции local, peer, peer_port, dev могут не поддерживаться старыми ядрами, можно их опустить.
# peer и peer_port используются для создания соединения сразу при создании FOU-listener-а.
ip fou add port 10001 ipproto 4 local 192.168.0.2 peer 203.0.113.1 peer_port 10000 dev eth0

ip address add 172.28.0.1 peer 172.28.0.0 dev ipipou1

ip link set ipipou1 up

ที่ไหน

• ipipou* — ชื่อของอินเทอร์เฟซเครือข่ายทันเนลท้องถิ่น
• 203.0.113.1 — เซิร์ฟเวอร์ IP สาธารณะ
• 198.51.100.2 — IP สาธารณะของลูกค้า
• 192.168.0.2 — IP ไคลเอ็นต์ที่กำหนดให้กับอินเทอร์เฟซ eth0
• 10001 — พอร์ตไคลเอ็นต์ท้องถิ่นสำหรับ FOU
• 20001 — พอร์ตไคลเอนต์สาธารณะสำหรับ FOU
• 10000 — พอร์ตเซิร์ฟเวอร์สาธารณะสำหรับ FOU
• encap-csum — ตัวเลือกในการเพิ่มการตรวจสอบ UDP ให้กับแพ็กเก็ต UDP ที่ห่อหุ้ม สามารถถูกแทนที่ด้วย noencap-csumไม่ต้องพูดถึง ความสมบูรณ์ถูกควบคุมโดยเลเยอร์การห่อหุ้มภายนอกแล้ว (ในขณะที่แพ็กเก็ตอยู่ภายในอุโมงค์)
• eth0 — อินเทอร์เฟซท้องถิ่นที่จะผูกอุโมงค์ ipip
• 172.28.0.1 — IP ของอินเทอร์เฟซช่องสัญญาณไคลเอนต์ (ส่วนตัว)
• 172.28.0.0 — อินเทอร์เฟซเซิร์ฟเวอร์อุโมงค์ IP (ส่วนตัว)

ตราบใดที่การเชื่อมต่อ UDP ยังคงใช้งานได้ ทันเนลก็จะยังใช้งานได้ แต่หากพัง คุณจะโชคดี - หาก IP ของไคลเอ็นต์: พอร์ตยังคงเหมือนเดิม - มันจะใช้งานได้ หากมีการเปลี่ยนแปลง - มันจะพัง

วิธีที่ง่ายที่สุดในการคืนทุกอย่างกลับคือการยกเลิกการโหลดโมดูลเคอร์เนล: modprobe -r fou ipip

แม้ว่าไม่จำเป็นต้องมีการตรวจสอบสิทธิ์ แต่ IP สาธารณะและพอร์ตของไคลเอ็นต์อาจไม่เป็นที่รู้จักเสมอไป และมักจะคาดเดาไม่ได้หรือแปรผันได้ (ขึ้นอยู่กับประเภท NAT) หากคุณละเว้น encap-dport ทางฝั่งเซิร์ฟเวอร์ ทันเนลจะไม่ทำงาน มันไม่ฉลาดพอที่จะรับพอร์ตการเชื่อมต่อระยะไกล ในกรณีนี้ ipipou ก็สามารถช่วยได้เช่นกัน หรือ WireGuard และโปรแกรมอื่นๆ ที่คล้ายกันก็สามารถช่วยคุณได้

มันทำงานอย่างไร

ไคลเอนต์ (ซึ่งโดยปกติจะอยู่เบื้องหลัง NAT) จะเปิดทันเนล (ดังตัวอย่างด้านบน) และส่งแพ็กเก็ตการรับรองความถูกต้องไปยังเซิร์ฟเวอร์เพื่อกำหนดค่าทันเนลที่ด้านข้าง ขึ้นอยู่กับการตั้งค่า นี่อาจเป็นแพ็กเก็ตว่าง (เพื่อให้เซิร์ฟเวอร์สามารถมองเห็น IP สาธารณะ: พอร์ตการเชื่อมต่อ) หรือข้อมูลที่เซิร์ฟเวอร์สามารถระบุไคลเอ็นต์ได้ ข้อมูลอาจเป็นข้อความรหัสผ่านธรรมดาในรูปแบบข้อความที่ชัดเจน (มีความคล้ายคลึงกับ HTTP Basic Auth) หรือข้อมูลที่ออกแบบเป็นพิเศษที่เซ็นชื่อด้วยคีย์ส่วนตัว (คล้ายกับ HTTP Digest Auth เท่านั้นที่แข็งแกร่งกว่า ดูฟังก์ชัน client_auth ในรหัส)

บนเซิร์ฟเวอร์ (ฝั่งที่มี IP สาธารณะ) เมื่อ ipipou เริ่มทำงาน มันจะสร้างตัวจัดการคิว nfqueue และกำหนดค่า netfilter เพื่อให้แพ็กเก็ตที่จำเป็นถูกส่งไปในที่ที่ควรอยู่: แพ็กเก็ตที่เริ่มต้นการเชื่อมต่อกับคิว nfqueue และ [เกือบ] ที่เหลือทั้งหมดตรงไปที่ผู้ฟัง FOU

สำหรับผู้ที่ไม่ทราบ nfqueue (หรือ NetfilterQueue) เป็นสิ่งพิเศษสำหรับมือสมัครเล่นที่ไม่รู้วิธีพัฒนาโมดูลเคอร์เนล ซึ่งการใช้ netfilter (nftables/iptables) ช่วยให้คุณสามารถเปลี่ยนเส้นทางแพ็กเก็ตเครือข่ายไปยังพื้นที่ผู้ใช้และประมวลผลที่นั่นโดยใช้ วิธีดั้งเดิมที่มีอยู่: แก้ไข (เป็นทางเลือก ) และส่งคืนให้กับเคอร์เนลหรือทิ้งไป

สำหรับภาษาโปรแกรมบางภาษามีข้อผูกมัดสำหรับการทำงานกับ nfqueue สำหรับการทุบตีไม่มีเลย (ไม่น่าแปลกใจ) ฉันต้องใช้ python: ipipou ใช้ Netfilterคิว.

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

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

เนื่องจาก ipipou ประมวลผลเฉพาะแพ็กเก็ตแรกจากการเชื่อมต่อ (และแพ็กเก็ตที่จัดการรั่วไหลเข้าสู่คิวก่อนที่จะสร้างการเชื่อมต่อ) ประสิทธิภาพแทบไม่ได้รับผลกระทบเลย

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

IPIP-over-FOU ปกติมีปัญหาอีกประการหนึ่งเมื่อทำงานกับ NAT - เป็นไปไม่ได้ที่จะสร้างอุโมงค์ IPIP สองอันที่ห่อหุ้มใน UDP ด้วย IP เดียวกันเนื่องจากโมดูล FOU และ IPIP ค่อนข้างแยกจากกัน เหล่านั้น. ไคลเอนต์คู่หนึ่งที่อยู่ด้านหลัง IP สาธารณะเดียวกันจะไม่สามารถเชื่อมต่อกับเซิร์ฟเวอร์เดียวกันในเวลาเดียวกันได้ด้วยวิธีนี้ ต่อไปในอนาคต, บางทีก็จะแก้ไขได้ในระดับเคอร์เนลแต่อันนี้ก็ไม่แน่นอน ในระหว่างนี้ NAT สามารถแก้ไขปัญหา NAT ได้ - หากเกิดขึ้นที่ที่อยู่ IP คู่หนึ่งถูกครอบครองโดยอุโมงค์อื่นแล้ว ipipou จะทำ NAT จากสาธารณะไปเป็น IP ส่วนตัวทางเลือก voila! - คุณสามารถสร้างอุโมงค์ได้จนกว่าพอร์ตจะหมด

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

หากใครมีแนวคิดในการแก้ไขปัญหานี้โดยปล่อยให้การรับส่งข้อมูลจำนวนมากเป็นแกนหลัก อย่าลังเลที่จะแสดงความคิดเห็น

อย่างไรก็ตาม การห่อหุ้มใน UDP ได้พิสูจน์ตัวเองแล้วเป็นอย่างดี เมื่อเปรียบเทียบกับการห่อหุ้มบน IP จะมีความเสถียรมากกว่าและมักจะเร็วกว่ามาก แม้ว่าจะมีโอเวอร์เฮดเพิ่มเติมของส่วนหัว UDP ก็ตาม นี่เป็นเพราะความจริงที่ว่าโฮสต์ส่วนใหญ่บนอินเทอร์เน็ตทำงานได้ดีกับโปรโตคอลยอดนิยมสามตัวเท่านั้น: TCP, UDP, ICMP ชิ้นส่วนที่จับต้องได้สามารถละทิ้งสิ่งอื่นทั้งหมดไปโดยสิ้นเชิง หรือดำเนินการให้ช้าลง เนื่องจากได้รับการปรับให้เหมาะสมสำหรับทั้งสามสิ่งนี้เท่านั้น

ตัวอย่างเช่น นี่คือเหตุผลว่าทำไม QUICK ซึ่งใช้ HTTP/3 จึงถูกสร้างขึ้นบน UDP และไม่ได้อยู่ด้านบนของ IP

พูดมามากพอแล้ว ก็ถึงเวลาดูว่ามันทำงานอย่างไรใน "โลกแห่งความเป็นจริง"

การต่อสู้

ใช้เพื่อจำลองโลกแห่งความจริง iperf3. ในแง่ของระดับความใกล้ชิดกับความเป็นจริง นี่เกือบจะเหมือนกับการจำลองโลกแห่งความเป็นจริงใน Minecraft แต่ตอนนี้ก็คงจะเป็นเช่นนั้น

ผู้เข้าร่วมการแข่งขัน:

• อ้างอิงช่องหลัก
• ฮีโร่ของบทความนี้คือ ipipou
• OpenVPN พร้อมการรับรองความถูกต้อง แต่ไม่มีการเข้ารหัส
• OpenVPN ในโหมดรวมทุกอย่าง
• WireGuard ที่ไม่มี PresharedKey โดยมี MTU=1440 (ตั้งแต่ IPv4 เท่านั้น)

ข้อมูลทางเทคนิคสำหรับ geeks
เมตริกใช้คำสั่งต่อไปนี้:

บนไคลเอนต์:

UDP

CPULOG=NAME.udp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -c SERVER_IP -4 -t 60 -f m -i 10 -B LOCAL_IP -P 2 -u -b 12M; tail -1 "$CPULOG"
# Где "-b 12M" это пропускная способность основного канала, делённая на число потоков "-P", чтобы лишние пакеты не плодить и не портить производительность.

TCP

CPULOG=NAME.tcp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -c SERVER_IP -4 -t 60 -f m -i 10 -B LOCAL_IP -P 2; tail -1 "$CPULOG"

เวลาแฝงของ ICMP

ping -c 10 SERVER_IP | tail -1

บนเซิร์ฟเวอร์ (ทำงานพร้อมกันกับไคลเอนต์):

UDP

CPULOG=NAME.udp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -s -i 10 -f m -1; tail -1 "$CPULOG"

TCP

CPULOG=NAME.tcp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -s -i 10 -f m -1; tail -1 "$CPULOG"

การกำหนดค่าอุโมงค์

อิปิปู
เซิร์ฟเวอร์
/etc/ipipou/server.conf:

server
number 0
fou-dev eth0
fou-local-port 10000
tunl-ip 172.28.0.0
auth-remote-pubkey-b64 eQYNhD/Xwl6Zaq+z3QXDzNI77x8CEKqY1n5kt9bKeEI=
auth-secret topsecret
auth-lifetime 3600
reply-on-auth-ok
verb 3

systemctl start ipipou@server

ลูกค้า
/etc/ipipou/client.conf:

client
number 0
fou-local @eth0
fou-remote SERVER_IP:10000
tunl-ip 172.28.0.1
# pubkey of auth-key-b64: eQYNhD/Xwl6Zaq+z3QXDzNI77x8CEKqY1n5kt9bKeEI=
auth-key-b64 RuBZkT23na2Q4QH1xfmZCfRgSgPt5s362UPAFbecTso=
auth-secret topsecret
keepalive 27
verb 3

systemctl start ipipou@client

openvpn (ไม่มีการเข้ารหัส พร้อมการรับรองความถูกต้อง)
เซิร์ฟเวอร์

openvpn --genkey --secret ovpn.key  # Затем надо передать ovpn.key клиенту
openvpn --dev tun1 --local SERVER_IP --port 2000 --ifconfig 172.16.17.1 172.16.17.2 --cipher none --auth SHA1 --ncp-disable --secret ovpn.key

ลูกค้า

openvpn --dev tun1 --local LOCAL_IP --remote SERVER_IP --port 2000 --ifconfig 172.16.17.2 172.16.17.1 --cipher none --auth SHA1 --ncp-disable --secret ovpn.key

openvpn (พร้อมการเข้ารหัส, การรับรองความถูกต้อง, ผ่าน UDP, ทุกอย่างตามที่คาดไว้)
กำหนดค่าโดยใช้ openvpn-จัดการ

ลวดป้องกัน
เซิร์ฟเวอร์
/etc/wireguard/server.conf:

[Interface]
Address=172.31.192.1/18
ListenPort=51820
PrivateKey=aMAG31yjt85zsVC5hn5jMskuFdF8C/LFSRYnhRGSKUQ=
MTU=1440

[Peer]
PublicKey=LyhhEIjVQPVmr/sJNdSRqTjxibsfDZ15sDuhvAQ3hVM=
AllowedIPs=172.31.192.2/32

systemctl start wg-quick@server

ลูกค้า
/etc/wireguard/client.conf:

[Interface]
Address=172.31.192.2/18
PrivateKey=uCluH7q2Hip5lLRSsVHc38nGKUGpZIUwGO/7k+6Ye3I=
MTU=1440

[Peer]
PublicKey=DjJRmGvhl6DWuSf1fldxNRBvqa701c0Sc7OpRr4gPXk=
AllowedIPs=172.31.192.1/32
Endpoint=SERVER_IP:51820

systemctl start wg-quick@client

ผลการวิจัย

ป้ายน่าเกลียดอับชื้น
โหลด CPU ของเซิร์ฟเวอร์ไม่ได้บ่งชี้มากนัก เนื่องจาก... มีบริการอื่นๆ อีกมากมายที่ทำงานอยู่ที่นั่น ซึ่งบางครั้งอาจกินทรัพยากรมากเกินไป:

proto bandwidth[Mbps] CPU_idle_client[%] CPU_idle_server[%]
# 20 Mbps канал с микрокомпьютера (4 core) до VPS (1 core) через Атлантику
# pure
UDP 20.4      99.80 93.34
TCP 19.2      99.67 96.68
ICMP latency min/avg/max/mdev = 198.838/198.997/199.360/0.372 ms
# ipipou
UDP 19.8      98.45 99.47
TCP 18.8      99.56 96.75
ICMP latency min/avg/max/mdev = 199.562/208.919/220.222/7.905 ms
# openvpn0 (auth only, no encryption)
UDP 19.3      99.89 72.90
TCP 16.1      95.95 88.46
ICMP latency min/avg/max/mdev = 191.631/193.538/198.724/2.520 ms
# openvpn (full encryption, auth, etc)
UDP 19.6      99.75 72.35
TCP 17.0      94.47 87.99
ICMP latency min/avg/max/mdev = 202.168/202.377/202.900/0.451 ms
# wireguard
UDP 19.3      91.60 94.78
TCP 17.2      96.76 92.87
ICMP latency min/avg/max/mdev = 217.925/223.601/230.696/3.266 ms

## около-1Gbps канал между VPS Европы и США (1 core)
# pure
UDP 729      73.40 39.93
TCP 363      96.95 90.40
ICMP latency min/avg/max/mdev = 106.867/106.994/107.126/0.066 ms
# ipipou
UDP 714      63.10 23.53
TCP 431      95.65 64.56
ICMP latency min/avg/max/mdev = 107.444/107.523/107.648/0.058 ms
# openvpn0 (auth only, no encryption)
UDP 193      17.51  1.62
TCP  12      95.45 92.80
ICMP latency min/avg/max/mdev = 107.191/107.334/107.559/0.116 ms
# wireguard
UDP 629      22.26  2.62
TCP 198      77.40 55.98
ICMP latency min/avg/max/mdev = 107.616/107.788/108.038/0.128 ms

ช่อง 20 Mbps

ช่องต่อ 1 Gbps ในแง่ดี

ในทุกกรณี ipipou มีประสิทธิภาพใกล้เคียงกับช่องสัญญาณฐานค่อนข้างมาก ซึ่งเยี่ยมมาก!

อุโมงค์ openvpn ที่ไม่ได้เข้ารหัสมีพฤติกรรมค่อนข้างแปลกในทั้งสองกรณี

หากใครจะทดสอบก็จะได้รับฟังความคิดเห็นที่น่าสนใจ

ขอให้ IPv6 และ NetPrickle อยู่กับเรา!

ที่มา: will.com