Các kết nối OpenVPN dự phòng với định tuyến Linux nâng cao qua mạng không đáng tin cậy


9

Tôi hiện đang sống ở một quốc gia chặn nhiều trang web và có kết nối mạng không đáng tin cậy với thế giới bên ngoài. Tôi có hai điểm cuối OpenVPN (giả sử: vpn1 và vpn2) trên các máy chủ Linux mà tôi sử dụng để phá vỡ tường lửa. Tôi có toàn quyền truy cập vào các máy chủ này. Điều này hoạt động khá tốt, ngoại trừ việc mất gói cao trên các kết nối VPN của tôi. Mất gói này thay đổi từ 1% đến 30% tùy theo thời gian và dường như có mối tương quan thấp, hầu hết thời gian có vẻ ngẫu nhiên.

Tôi đang suy nghĩ về việc thiết lập bộ định tuyến gia đình (cũng trên Linux) duy trì các kết nối OpenVPN đến cả hai điểm cuối và gửi tất cả các gói hai lần, đến cả hai điểm cuối. vpn2 sẽ gửi tất cả các gói từ nhà đến vpn1. Trả lại các đề tài sẽ được gửi cả trực tiếp từ vpn1 đến nhà, và cũng thông qua vpn2.

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

Để rõ ràng: tất cả các gói giữa nhà và proxy HTTP sẽ được sao chép và gửi qua các đường dẫn khác nhau, để tăng cơ hội một trong số chúng sẽ đến. Nếu cả hai đến, thứ hai đầu tiên có thể được loại bỏ âm thầm.

Việc sử dụng băng thông không phải là một vấn đề, cả ở phía nhà và điểm cuối. vpn1 và vpn2 gần nhau (ping 3ms) và có kết nối đáng tin cậy.

Bất kỳ con trỏ nào về cách có thể đạt được điều này bằng cách sử dụng các chính sách định tuyến nâng cao có sẵn trong Linux?

Câu trả lời:


8

Sử dụng cơ sở hạ tầng liên kết ở phía 'nhà' và 'vpn1' và đặc biệt với cài đặt mode = 3 để phát lưu lượng truy cập trên tất cả các giao diện thuộc về một liên kết.

Để biết thêm thông tin về cách định cấu hình liên kết, hãy xem hướng dẫn tuyệt vời tại http://git.kernel.org/?p=linux/kernel/git/urdy/linux-2.6.37.y.git;a=blob;f = Tài liệu / mạng / bonding.txt; h = 5dc638791d975116bf1a1e590fdfc44a6ae5c33c; hb = HEAD


Tôi đã thử nghiệm thiết lập này và nó hoạt động tuyệt vời. Mất gói được giảm từ khoảng 5% xuống 0,0-0,1% với kết nối dự phòng cho chỉ một máy chủ!
konrad

7

Tôi đã sử dụng câu trả lời được cung cấp bởi @ user48116 và nó hoạt động như một bùa mê. Việc thiết lập thực sự khá dễ dàng!

LƯU Ý : Tôi đã triển khai điều này với hai kết nối đến chỉ một máy chủ, vì điều này đã giải quyết được vấn đề cho tôi. Nếu bạn muốn thử thiết lập với hai máy chủ, cách dễ nhất có lẽ là sử dụng chuyển tiếp cổng để chuyển tiếp cổng UDP từ máy chủ thứ hai sang máy chủ thứ nhất và sử dụng cùng một công thức như được mô tả ở đây. Tôi đã không kiểm tra điều này bản thân mình mặc dù.

Trước tiên, hãy đảm bảo bạn có kernel 2.6 với hỗ trợ liên kết (mặc định trong tất cả các bản phân phối hiện đại) và bạn đã cài đặt ifenslave.

Tiếp theo, đặt cái này vào /etc/rc.local hoặc bất kỳ nơi nào bạn thích, nhưng hãy chắc chắn rằng nó chạy trước khi openvpn được bắt đầu (bởi vì nó sẽ cố gắng liên kết với bond0):

Khách hàng:

modprobe bonding mode=broadcast
ifconfig bond0 10.10.0.2 netmask 255.255.255.0 up

Bạn có thể thêm một số định tuyến nếu cần ở đây, đảm bảo rằng bạn cũng thực hiện tất cả các định tuyến thích hợp từ phía bên kia.

route add -net 10.7.0.0/24 gw 10.10.0.1

Người phục vụ:

modprobe bonding mode=broadcast
ifconfig bond0 10.10.0.1 netmask 255.255.255.0 up

Tạo tập lệnh /etc/openvpn/tap-up.sh (và đừng quên đánh dấu tập lệnh thực thi bằng 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"

Tiếp theo, thêm một Bridge0a.conf và Bridge0b.conf vào / etc / openvpn / cùng với một khóa được chia sẻ. Các tệp giống nhau cho a và b, ngoại trừ một cổng khác (ví dụ: sử dụng 3002 cho b). Thay thế 11.22.33.44 bằng IP công cộng của máy chủ của bạn.

Khách hàng:

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

Người phục vụ:

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

Đừng quên chỉnh sửa / etc / defaults / openvpn để đảm bảo cấu hình VPN mới của bạn được bắt đầu. Khởi động lại máy của bạn, hoặc tải RC.local và khởi động lại openvpn bằng tay.

Bây giờ bạn đã sẵn sàng để kiểm tra thiết lập của bạn:

# 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

Nếu mọi thứ đều ổn và dòng này tốt, bạn sẽ thấy bốn câu trả lời cho mỗi gói ICMP: các gói của bạn được sao chép ở phía cục bộ và trả lời cho hai gói này được sao chép lại ở phía xa. Đây không phải là vấn đề đối với các kết nối TCP, vì TCP sẽ đơn giản bỏ qua tất cả các bản sao.

Đây là một vấn đề đối với các gói UDP, vì nó tùy thuộc vào phần mềm để xử lý các bản sao. Ví dụ: một truy vấn DNS sẽ mang lại bốn câu trả lời thay vì hai câu trả lời dự kiến ​​(và sử dụng bốn lần băng thông bình thường cho phản hồi thay vì hai lần):

# 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)

Chúc may mắn!

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.