मैंने @ user48116 द्वारा दिए गए उत्तर का उपयोग किया और यह एक आकर्षण की तरह काम करता है। सेटअप वास्तव में काफी आसान है!
नोट : मैंने इसे केवल एक ही सर्वर पर दो कनेक्शनों के साथ लागू किया, क्योंकि इससे मेरे लिए समस्या पहले से ही हल हो गई थी। यदि आप दो सर्वरों के साथ एक सेटअप का प्रयास करना चाहते हैं, तो सबसे आसान तरीका संभवत: दूसरे सर्वर से पहले यूडीपी पोर्ट को अग्रेषित करने के लिए पोर्ट अग्रेषण का उपयोग करना है, और यहां बताए अनुसार एक ही नुस्खा का उपयोग करना है। मैंने हालांकि खुद इसका परीक्षण नहीं किया है।
सबसे पहले, सुनिश्चित करें कि आपके पास बंधन समर्थन के साथ 2.6 कर्नेल है (सभी आधुनिक वितरणों में डिफ़ॉल्ट) और आपके पास ifenslave स्थापित है।
इसके बाद, इसे अपने /etc/rc.local या किसी अन्य स्थान पर रखें जिसे आप पसंद करते हैं, लेकिन यह सुनिश्चित करें कि यह ओपनवपन शुरू होने से पहले चलाया जाता है (क्योंकि यह बंधन 0 से बांधने की कोशिश करेगा):
ग्राहक:
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 / को एक साथ जोड़ें। फाइलें एक और बी के लिए समान हैं, एक अलग बंदरगाह को छोड़कर (उदाहरण के लिए, b के लिए 3002 का उपयोग करें)। अपने सर्वर के सार्वजनिक IP द्वारा 11.22.33.44 बदलें।
ग्राहक:
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
यह सुनिश्चित करने के लिए कि आपके नए वीपीएन कॉन्फ़िगरेशन शुरू किए गए हैं, संपादन / आदि / चूक / ओपनवैप करना न भूलें। आप मशीनों को रिबूट करें, या rc.local लोड करें और मैन्युअल रूप से ओपनवैप को पुनरारंभ करें।
अब आप अपने सेटअप का परीक्षण करने के लिए तैयार हैं:
# 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 पैकेज के लिए चार उत्तर दिखाई देंगे : आपके पैकेजों को स्थानीय पक्ष पर डुप्लिकेट किया गया है, और इन दो पैकेजों के उत्तरों को फिर से दूरस्थ रूप से दोहराया गया है। यह टीसीपी कनेक्शन के लिए एक मुद्दा नहीं होगा, क्योंकि टीसीपी केवल सभी डुप्लिकेट को अनदेखा करेगा।
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)
सौभाग्य!