การเชื่อมต่อ OpenVPN ซ้ำซ้อนพร้อมการกำหนดเส้นทาง Linux ขั้นสูงผ่านเครือข่ายที่ไม่น่าเชื่อถือ

ขณะนี้ฉันอาศัยอยู่ในประเทศที่บล็อกเว็บไซต์จำนวนมากและมีการเชื่อมต่อเครือข่ายที่ไม่น่าเชื่อถือกับโลกภายนอก ฉันมีจุดปลาย OpenVPN สองจุด (เช่น: vpn1 และ vpn2) บนเซิร์ฟเวอร์ Linux ที่ฉันใช้เพื่อหลีกเลี่ยงไฟร์วอลล์ ฉันสามารถเข้าถึงเซิร์ฟเวอร์เหล่านี้ได้อย่างสมบูรณ์ ใช้งานได้ดียกเว้นการสูญเสียแพ็กเกจสูงในการเชื่อมต่อ VPN ของฉัน การสูญเสียแพ็กเก็ตนี้แตกต่างกันไประหว่าง 1% ถึง 30% ขึ้นอยู่กับเวลาและดูเหมือนว่าจะมีความสัมพันธ์ต่ำซึ่งโดยส่วนใหญ่แล้วดูเหมือนว่าจะสุ่ม

ฉันกำลังคิดเกี่ยวกับการตั้งค่าเราเตอร์ที่บ้าน (บน Linux) ที่รักษาการเชื่อมต่อ OpenVPN ไปยังจุดปลายทั้งสองและส่งแพ็กเก็ตทั้งหมดสองครั้งไปยังจุดปลายทั้งสอง vpn2 จะส่งแพ็คเก็ตทั้งหมดจากที่บ้านไปที่ vpn1 Return trafic จะส่งทั้งโดยตรงจาก vpn1 ถึงบ้านและผ่าน vpn2

       +------------+
       |    home    |
       +------------+
        |          |
        | OpenVPN  |
        |  links   |
        |          |
     ~~~~~~~~~~~~~~~~~~ unreliable connection
        |          |
+----------+   +----------+
|   vpn1   |---|   vpn2   |
+----------+   +----------+
        |
       +------------+
       | HTTP proxy |
       +------------+
             |
         (internet)

เพื่อความชัดเจน: แพ็คเก็ตทั้งหมดระหว่างโฮมและพร็อกซี HTTP จะถูกทำซ้ำและส่งผ่านเส้นทางที่แตกต่างกันเพื่อเพิ่มโอกาสที่หนึ่งในนั้นจะมาถึง หากทั้งคู่มาถึงตัวที่สองตัวแรกจะถูกกำจัดอย่างเงียบ ๆ

การใช้แบนด์วิดท์ไม่เป็นปัญหาทั้งในด้านบ้านและฝั่งปลายทาง vpn1 และ vpn2 อยู่ใกล้กัน (3ms ping) และมีการเชื่อมต่อที่เชื่อถือได้

ตัวชี้ใด ๆ เกี่ยวกับวิธีการนี้สามารถทำได้โดยใช้นโยบายการกำหนดเส้นทางขั้นสูงที่มีอยู่ใน Linux

ใช้โครงสร้างพื้นฐานการเชื่อมที่ด้านข้าง 'home' และ 'vpn1' และใช้การตั้งค่า mode = 3 ซึ่งกระจายการรับส่งข้อมูลบนอินเทอร์เฟซทั้งหมดที่อยู่ในบอนด์

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีกำหนดค่าการเชื่อมให้ดูคู่มือที่ยอดเยี่ยมที่http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.37.y.git;a=blob;f = เอกสาร / เครือข่าย / bonding.txt; H = 5dc638791d975116bf1a1e590fdfc44a6ae5c33c; HB = HEAD

ฉันใช้คำตอบที่มีให้โดย @ user48116 และใช้งานได้อย่างมีเสน่ห์ การตั้งค่าเป็นเรื่องง่ายมาก!

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

ขั้นแรกตรวจสอบให้แน่ใจว่าคุณมีเคอร์เนล 2.6 พร้อมการสนับสนุนการเชื่อมโยง (ค่าเริ่มต้นในการแจกแจงที่ทันสมัยทั้งหมด) และคุณติดตั้ง ifenslave

ถัดไปวางสิ่งนี้ลงใน /etc/rc.local ของคุณหรือที่อื่น ๆ ที่คุณต้องการ แต่ให้แน่ใจว่ามันทำงานก่อนที่จะเปิด openvpn (เพราะมันจะพยายามผูกมัดกับ bond0):

ลูกค้า:

modprobe bonding mode=broadcast
ifconfig bond0 10.10.0.2 netmask 255.255.255.0 up

คุณสามารถเพิ่มการกำหนดเส้นทางบางอย่างถ้าจำเป็นที่นี่ตรวจสอบให้แน่ใจว่าคุณได้กำหนดเส้นทางที่เหมาะสมทั้งหมดจากอีกด้านหนึ่งด้วย

route add -net 10.7.0.0/24 gw 10.10.0.1

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

modprobe bonding mode=broadcast
ifconfig bond0 10.10.0.1 netmask 255.255.255.0 up

สร้างสคริปต์ /etc/openvpn/tap-up.sh (และอย่าลืมทำเครื่องหมายให้เรียกใช้ด้วย chmod a + x tap-up.sh):

#!/bin/sh
# called as: cmd tap_dev tap_mtu link_mtu ifconfig_local_ip ifconfig_netmask [ init | restart ]
ifenslave bond0 "$1"

ถัดไปเพิ่ม bridge0a.conf และ bridge0b.conf ให้กับ / etc / openvpn / พร้อมกับรหัสแชร์ ไฟล์จะเหมือนกันสำหรับ a และ b ยกเว้นสำหรับพอร์ตอื่น (ตัวอย่างเช่นใช้ 3002 สำหรับ b) แทนที่ 11.22.33.44 ด้วย IP สาธารณะของเซิร์ฟเวอร์ของคุณ

ลูกค้า:

remote 11.22.33.44
dev tap
port 3001
rport 3001
secret bridge.key
comp-lzo
verb 4
nobind
persist-tun
persist-key
script-security 2
up /etc/openvpn/tap-up.sh

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

local 11.22.33.44
dev tap
port 3001
lport 3001
secret bridge.key
comp-lzo
verb 4
script-security 2
up /etc/openvpn/tap-up.sh

อย่าลืมแก้ไข / etc / defaults / openvpn เพื่อให้แน่ใจว่าการกำหนดค่า VPN ใหม่ของคุณเริ่มต้นแล้ว รีบูทเครื่องหรือโหลด rc.local และรีสตาร์ท openvpn ด้วยตนเอง

ตอนนี้คุณพร้อมที่จะทดสอบการตั้งค่าของคุณ:

# ping 10.10.0.1
PING 10.10.0.1 (10.10.0.1) 56(84) bytes of data.
64 bytes from 10.10.0.1: icmp_req=1 ttl=64 time=50.4 ms
64 bytes from 10.10.0.1: icmp_req=1 ttl=64 time=51.1 ms (DUP!)
64 bytes from 10.10.0.1: icmp_req=1 ttl=64 time=51.1 ms (DUP!)
64 bytes from 10.10.0.1: icmp_req=1 ttl=64 time=51.1 ms (DUP!)
64 bytes from 10.10.0.1: icmp_req=2 ttl=64 time=52.0 ms
64 bytes from 10.10.0.1: icmp_req=2 ttl=64 time=52.2 ms (DUP!)
64 bytes from 10.10.0.1: icmp_req=2 ttl=64 time=53.0 ms (DUP!)
64 bytes from 10.10.0.1: icmp_req=2 ttl=64 time=53.1 ms (DUP!)
--- 10.10.0.1 ping statistics ---
2 packets transmitted, 2 received, +6 duplicates, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 50.428/51.786/53.160/0.955 ms

หากทุกอย่างเป็นไปด้วยดีและเส้นดีคุณจะเห็นสี่คำตอบสำหรับทุกแพ็คเกจ ICMP: แพคเกจของคุณจะถูกทำซ้ำที่ฝั่งท้องถิ่น สิ่งนี้จะไม่เป็นปัญหาสำหรับการเชื่อมต่อ TCP เนื่องจาก TCP จะเพิกเฉยต่อการทำซ้ำทั้งหมด

นี่เป็นปัญหาสำหรับแพ็คเก็ต UDP เนื่องจากมันขึ้นอยู่กับซอฟต์แวร์ในการจัดการรายการที่ซ้ำกัน ตัวอย่างเช่นแบบสอบถาม DNS จะให้การตอบกลับสี่ครั้งแทนที่จะเป็นสองคำตอบที่คาดไว้ (และใช้แบนด์วิดท์ปกติสี่เท่าสำหรับการตอบสนองแทนสองครั้ง):

# tcpdump -i bond0 -n port 53
listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:30:39.870740 IP 10.10.0.2.59330 > 10.7.0.1.53: 59577+ A? serverfault.com. (33)
13:30:40.174281 IP 10.7.0.1.53 > 10.10.0.2.59330: 59577 1/0/0 A 64.34.119.12 (49)
13:30:40.174471 IP 10.7.0.1.53 > 10.10.0.2.59330: 59577 1/0/0 A 64.34.119.12 (49)
13:30:40.186664 IP 10.7.0.1.53 > 10.10.0.2.59330: 59577 1/0/0 A 64.34.119.12 (49)
13:30:40.187030 IP 10.7.0.1.53 > 10.10.0.2.59330: 59577 1/0/0 A 64.34.119.12 (49)

โชคดี!