☰

Конфигурация двух интернет-провайдеров и многопутевого шлюза

tag-icon • tag-icon debian routing
Конфигурация двух интернет-провайдеров и многопутевого шлюза

У меня два разных провайдера. Я хочу настроить балансировку нагрузки, которая будет распределять пакеты между этими провайдерами. Я знаю, что это можно сделать с помощью разных таблиц маршрутизации, но я хотел использовать что-то под названием «многопутевой шлюз».

Я настроил оба интерфейса в /etc/network/interfacesфайле. Оба соединения работают отдельно. Я заменил шлюзы по умолчанию на тот, что ниже:

# ip route add default \
    nexthop via 192.168.1.1 dev bond0 weight 1 \
    nexthop via 10.143.105.17 dev wwan0 weight 1

Я добавил цели маскировки в iptablesоба интерфейса:

iptables -t nat -A POSTROUTING -o wwan0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o bond0 -j MASQUERADE

Также я включил (частично) фильтрацию обратного пути через sysctl:

net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2

Эта настройка работает. Пакеты (соединения) отправляются через оба интерфейса. Есть только одна проблема, которую я не понимаю.

Когда я хочу проверить свой IP-адрес, используя следующие команды:

$ curl text.whatisyourip.org
$ curl eko.one.pl/host.php

IP-адрес в обоих случаях разный, что означает, что механизм работает хорошо. Также я вижу, как он работает в wireshark. Но когда я пытаюсь отправить, например, несколько запросов на первый из доменов выше, я всегда получаю в ответ один и тот же IP-адрес. Так что похоже, что пакеты, предназначенные для определенного IP-адреса, всегда проходят через один и тот же интерфейс. Мне просто интересно, почему. Есть ли какой-либо механизм, который запоминает IP-адреса назначения предыдущих запросов и заставляет следующие запросы на те же адреса проходить через тот же интерфейс?

решение1

Мне удалось решить эту проблему. Вэта ссылкавы можете прочитать следующее:

IPv4: многопутевая маршрутизация на основе хэша. Когда кэш маршрутизации был удален в версии 3.6, многопутевой алгоритм IPv4 изменился с более или менее ориентированного на пункт назначения на квазислучайное попакетное планирование. Это увеличило риск неупорядоченных пакетов и сделало невозможным использование многопутевой маршрутизации вместе с anycast-сервисами. В этом выпуске реализация многопутевой маршрутизации заменена на балансировку нагрузки на основе потока, основанную на хэше по адресам источника и назначения merge commit

Так что даже несмотря на то, что кэш был удален в ядре 3.6, запросы все еще кэшируются. Теперь исходный и целевой адреса имеют значение. Вот почему пакеты всегда проходят через один и тот же интерфейс.

Связанный контент