Làm thế nào để đạt được định tuyến đa đường trên mỗi gói trên Linux?

Linux Kernel trước 3.6 đã sử dụng bộ nhớ đệm định tuyến để thực hiện định tuyến đa luồng IPv4, điều đó có nghĩa là định tuyến giữa hai dòng / ISP riêng biệt khá dễ dàng. Từ 3.6, thuật toán thay đổi thành mỗi gói, nghĩa là một số thủ thuật đánh dấu bảng / quy tắc / iptables được yêu cầu để đạt được hai dòng / ISP.

Tuy nhiên, nếu bạn có hai dòng với cùng một ISP, người có thể định tuyến một IP xuống cả hai dòng trên cơ sở mỗi gói theo kiểu cân bằng / chuyển đổi dự phòng, thì từ 3.6 bạn có thể dễ dàng đạt được liên kết dòng (ở cấp IP) vì định tuyến trên mỗi gói theo cả hai hướng.

Từ 4.4, hạt nhân lại thay đổi thành cân bằng tải dựa trên dòng chảy dựa trên hàm băm qua địa chỉ nguồn và đích.

Tôi hiện đang chạy Kernel 4.4.36 và đang sử dụng định tuyến đa đường qua các kết nối PPPoE. Lưu lượng truy cập hạ nguồn của tôi từ ISP được định tuyến qua hai dòng riêng biệt trên cơ sở mỗi gói (một IP được chuyển xuống cả hai dòng). Điều này mang lại cho tôi tốc độ tải xuống nhanh hơn tốc độ của một dòng riêng lẻ. Gần như tốc độ của cả hai dòng cộng lại. Nó hoạt động thực sự tốt, video Skype, VoIP (UDP), YouTube, vv tất cả đều hoạt động tuyệt vời.

Do có trải nghiệm xuôi dòng tốt như vậy, tôi muốn thử ngược dòng nhưng lưu lượng ngược dòng của tôi được định tuyến theo thuật toán dựa trên luồng mới hơn trên cả hai thiết bị ppp (có cùng địa chỉ IP). Điều này có nghĩa là tôi không thể đạt được tốc độ tải lên nhanh hơn tốc độ của một dòng.

Có cách nào để cấu hình Kernel hiện tại để sử dụng thuật toán cho mỗi gói không? Hoặc một số phương pháp khác để đạt được định tuyến đa đường cho mỗi gói? Tôi có cần hoàn nguyên về một kernel cũ hơn (mà tôi không muốn làm vì nhiều lý do khác)?

ISP của tôi không hỗ trợ ppp đa liên kết.

Trong trường hợp có liên quan, tôi hiện đang chạy Arch Linux ARMv7 trên Raspberry Pi 3.

Ok, vì vậy sau khi có nhiều thời gian hơn để điều tra điều này, tôi đã tìm ra cách để làm điều đó bằng cách sử dụng Linux TEQL (Bộ cân bằng liên kết thực). Đây là một liên kết tôi lỏng lẻo theo dõi, nhưng với một số điều chỉnh.

http://lartc.org/howto/lartc.loadshare.html

Đây là cách tôi làm cho nó hoạt động trên Arch Linux ARMv7 (Raspberry Pi 3)

Khi khởi động:

Lệnh sau nên được chạy khi khởi động để tải mô-đun Kernel thích hợp.

modprobe sch_teql

Các lệnh sau cũng để chạy khi khởi động giả sử bạn muốn NAT từ mạng cục bộ trên eth0.

sysctl -w net.ipv4.ip_forward=1
iptables -A INPUT -i ppp+ -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i ppp+ -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A POSTROUTING -t nat -o teql+ -j MASQUERADE

Lưu lượng truy cập FORWARD là trên ppp + và POSTROUTING MASQUERADE trên teql + vì lưu lượng đi ra ngoài trên teql và lưu lượng truy cập trở lại trên ppp.

Khi liên kết ppp xuất hiện:

Giả sử các liên kết được cân bằng tải là ppp, các lệnh sau sẽ được chạy trong một tập lệnh trong một /etc/ppp/ip-up.d/tập lệnh.

sysctl -w net.ipv4.conf.ppp1.rp_filter=2
sysctl -w net.ipv4.conf.ppp2.rp_filter=2
tc qdisc add dev ppp1 root teql0
tc qdisc add dev ppp2 root teql0
ip address add 1.1.1.1/32 dev teql0
# you can add additional public IP addresses teql0 if you need to
ip link set teql0 up
ip route replace default scope global dev teql0

1.1.1.1Địa chỉ IP công cộng phải đối mặt với ISP của bạn ở đâu . IP công cộng bổ sung có thể được gán cho thiết bị teql0, nhưng không cần phải gán cho thiết bị ppp. Trong thiết lập của tôi, hai liên kết ppp chia sẻ cùng một IP (được thương lượng bởi pppoe, v.v.) Liên kết teql được gán thủ công như được hiển thị ở trên. ISP cần gửi lưu lượng truy cập cho IP bằng nhau cả hai liên kết.

Đường dẫn ngược ( rp_filter) được đặt thành 2(lỏng) cả trong tập lệnh ở trên để các gói trả về không bị loại bỏ do chúng quay trở lại trên các giao diện ppp thay vì teql0.

Tôi đã thiết lập nó theo cách đó, và nó hoạt động hoàn hảo. Rất dễ! Khi các liên kết thất bại, có chuyển đổi dự phòng liền mạch. Khi họ đi lên, họ chỉ bắt đầu làm việc trở lại. Có vẻ như không có mất gói hoặc chậm trễ khi nó thất bại, và không có gì khi nó sao lưu.

Ngoài ra, một trong những người bình luận đề xuất liên kết dưới đây sử dụng định tuyến chính sách, với iptables để đánh dấu mọi gói khác, v.v. nhưng tôi sẽ thử trong vài ngày để xem liệu nó có hoạt động tốt hơn so với ở trên không và cung cấp phản hồi phù hợp ở đây.

http://support.aa.net.uk/Router_-_Linux_upload_boinating_USE_policy_routing