Як досягти багатошарової маршрутизації на одному пакеті в Linux?

Linux Kernel перед 3.6 використовував кешування маршрутів, щоб робити багатошляхову маршрутизацію IPv4, що означало, що маршрутизація між двома окремими лініями / провайдерами була досить простою. З 3.6 алгоритм змінився на пакетний пакет, що означає, що для досягнення двох рядків / провайдерів потрібні деякі трюкові маркери / правила / правила iptables.

Однак якщо у вас було два рядки з тим самим провайдером, який міг би маршрутизувати один IP вниз по обох лініях на пакетній основі врівноважено / відмовно, тоді з 3.6 ви могли б легко досягти зв’язку ліній (на рівні IP) через маршрутизація пакета в обох напрямках.

З 4.4 ядро знову змінилося на балансування навантаження на основі потоку на основі хеша над адресами джерела та призначення.

На даний момент я працюю з ядром 4.4.36 і використовую багатосторонній маршрутизацію через підключення PPPoE. Мій трафік нижче від інтернет-провайдера маршрутизується через дві окремі лінії на основі пакета (один IP-маршрут спрямований вниз по обох лініях). Це дає мені швидкість завантаження швидше, ніж швидкість одного окремого рядка. Майже швидкість обох ліній, що додаються разом. Він працює дуже добре, відео Skype, VoIP (UDP), YouTube і т.д.

Через те, що я маю такий хороший досвід вниз за течією, я хочу спробувати його вгору за течією, але мій трафік вище за потоком спрямовується відповідно до новішого алгоритму на основі потоку на обох пристроях ppp (які мають однакову IP-адресу). Це означає, що я не можу досягти швидкості завантаження, швидшої, ніж швидкість одного рядка.

Чи є спосіб налаштувати поточне ядро для використання алгоритму для пакету? Або якийсь інший метод досягнення маршрутизації по декількох каналах? Чи потрібно мені повернутися до старшого ядра (чого я не хочу робити з різних інших причин)?

Мій провайдер не підтримує багатопосилання ppp.

У випадку, якщо це доречно, я зараз запускаю Arch Linux ARMv7 на Raspberry Pi 3.

— bao7uo
джерело

Це дуже погана ідея. Балансування в пакеті на L2 (тобто MLPPP) включає достатню логіку, щоб зібрати пакети в порядку. Якщо це запустити через IP, це відкриє величезну можливість (якщо не майже впевненість) для доставки поза замовленням. Це спричинить величезну кількість проблем з повільними сеансами TCP, загалом зламаним UDP, проблемами з будь-яким видом потокової передачі в реальному часі і т. Д. Інша проблема полягає в тому, що навіть якщо ви надсилаєте пакети круглобільно до свого провайдера, абсолютно немає припущення, що вони будуть аналогічно врівноважувати вас.

— rnxrx

@rnxrx дякую за ваш коментар - відредагували питання, щоб надати додаткову інформацію. З мого запитання: "трафік нижче від поточного постачальника послуг проходить через дві окремі лінії на основі пакета". ISP надає панель управління - коли я вибираю один IP для маршрутизації по обох лініях, то вони направляють його на ідеально збалансований круглоліток на основі пакету. Працює добре, приблизно на 90% від загальної швидкості обох ліній, що додаються разом, і забезпечує миттєвий відмову. Скайп-відео, VOIP-дзвінки, YouTube, потокове передавання BBC тощо. Все чудово - Такий чудовий досвід за течією спонукає мене спробувати спробувати вище

— bao7uo

Ага - зрозумів ... Отже, у вас є два унікальних IP-адреси (по одному на з'єднання) або вони спрямовуються до одного IP (або підмережі) на вашій стороні двома паралельними шляхами? Якщо ви використовуєте будь-який тип NAT, очевидно, що це важливо, щоб це відбулося до цього балансування. Як би там не було - ви подивилися на support.aa.net.uk/… ? Це використання розширень iptables, щоб в основному виконати те, що ви описуєте, і як таке повинно бути досить послідовним у досить сучасних версіях ядра.

— rnxrx

Дякую @rnxrx - так, я можу зробити будь-який варіант (два унікальних IP-адреси або один IP-адресу через паралельні шляхи). Я віддав перевагу одному варіанту IP, оскільки, здавалося, має більше сенсу.

— bao7uo

Добре, тому, маючи більше часу на дослідження цього, я знайшов спосіб зробити це за допомогою Linux TEQL (True Link Equalizer). Ось посилання, яке я вільно переслідував, але з деякими налаштуваннями.

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

Ось як я отримав це, працюючи над Arch Linux ARMv7 (Raspberry Pi 3)

Під час завантаження:

Для завантаження відповідного модуля ядра слід виконати наступну команду під час завантаження.

modprobe sch_teql

Наступні команди також запускаються під час завантаження, припускаючи, що ви бажаєте NAT з локальної мережі на 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

Зворотний трафік FORWARD знаходиться на ppp +, а MASQUERADE на розсилку на teql +, оскільки вихідний трафік виходить на teql, а зворотний трафік повертається на ppp.

Коли з'являються посилання ppp:

Якщо припустити, що посилання зрівноважені завантаженням є ppp, наступні команди, які слід виконати в сценарії в /etc/ppp/ip-up.d/сценарії.

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ваша IP-адреса, яка стоїть перед ISP. Додаткові загальнодоступні IP-адреси можуть бути призначені пристрою teql0, але їх не потрібно призначати пристроям ppp. У моїй установці два ppp-посилання поділяють один і той же IP (узгоджено pppoe тощо). Teql-посилання, призначене для цього вручну, як показано вище. Інтернет-провайдер повинен надсилати трафік для IP однаково по обох каналах.

Зворотний шлях ( rp_filter) встановлений у 2(вільний) як у вищезазначеному сценарії, так що зворотні пакети не скидаються через те, що вони повертаються на ppp-інтерфейси, а не teql0.

Я налаштував це таким чином, і він прекрасно працює. Дуже легко! Коли посилання виходять з ладу, відбувається безперебійне відмовлення. Коли вони підійдуть, вони просто знову починають працювати. Здається, немає втрати або затримки пакета, коли він не завершується, і жодного, коли він не повертається.

Також один із коментаторів запропонував нижченаведене посилання, яке використовує маршрутизацію політики, з iptables для позначення кожного іншого пакету тощо, але я спробую через кілька днів побачити, чи працює він краще, ніж вище, і надати відповідні відгуки тут.

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

— bao7uo
джерело

Я ніколи не пробував маршрутизацію політики, оскільки TEQL працював так добре. Якщо це не

— зламається

Я намагаюся змусити це працювати. У мене зв’язок працює, я можу використовувати інтерфейсний інтерфейс від маршрутизатора. Я не можу змусити NAT працювати, хоча трафік з моєї локальної мережі не знижується по зв’язаному посиланню :(

— andynormancx

якщо ви розмістите нове запитання про помилку сервера і посилаєтесь на нього з коментаря, я спробую розібратися для вас. включіть якомога більше інформації, наприклад, конфігурацію інтерфейсу / ip, таблицю маршрутизації, правила iptables тощо, якщо ви не можете вмістити всю інформацію тут у коментарях?

— bao7uo

PS. щойно помітив помилку в моїй конфігурації. він сказав, sysctl -w net.ipv4.ip_forwardале слід сказати, sysctl -w net.ipv4.ip_forward=1так що я виправив вище. Це, безумовно, не дозволить трафіку від локальної мережі знижуватися по зв’язаному каналу зв'язку.

— bao7uo

Я не думаю, що це зупинило його роботу для мене, у мене було включено переадресацію в sysctl. Зараз я намагаюся розібратися, чи очікується велика кількість пакетів, що не вийшли з ладу, які я бачу.

— andynormancx