Дано: две квартиры, два разных провайдера, две домашние локальные сети, загрузка обеих сетей неравномерная, между сетями есть мост. Каким образом можно максимизировать траффик наружу, задействовав обе сети? При этом нужно сохранить приоритет траффика каждой сети отдельно. Грубо говоря, хочется сделать так, чтобы можно было загрузить неспользованную пропускную способность второй сети, но никоим образом не мешать собственному траффику этой сети. Почитал про QoS, traffic shaping, но пока непонятно, как сделать так, чтобы пакеты первой сети не терялись, если вторая сеть загружена и не пропускает их.
В общем виде задача неподъёмно сложная.
Я даже приблизительно боюсь описывать возможные приближения к решению, все они требуют высококвалифицированных админов, специально настроенных раутеров на выходе, динамической маршрутизации внутри... и всё равно будет только очень частичная эффективность.
Коробочного решения не ищите — максимум их умений это из одного раутера перебросить часть трафика по фиксированным критериям, или весь при пропадании аплинка (которое они ещё и далеко не всегда детектят).
Но в общем нужно:
1) Свои раутеры (условно, коробочки с Linux, куда можно заливать свой софт), связанные линком. NAT на каждом для обеих сетей.
2) Свой протокол общения раутеров, который говорит "у меня сейчас есть свободный ресурс на аплинке" (и учти, что "сейчас" не значит, что через полминуты его не будет). Штатного такого не знаю, они все требуют реальных анонсов от таких аплинков.
3) Connection tracking в них для применяемых протоколов (минимум для TCP и UDP), который позволяет делать свои хуки для новых соединений.
4) QoS на выходе согласно источнику пакетов, который собирает статистику загрузок и потерь.
5) Код, решающий для этих новых соединений, куда их отправлять, согласно загрузке сети.
6) Вероятно, код, который по conntrack-таблице рубит чужие соединения при перегрузке (чтобы на следующий заход они пытались вырываться через свой родной раутер). Надо учитывать при этом загрузку не только на аплоад, но и на даунлоад.
Всё вместе тянет на аспирантский диплом или PhD диссер, если мерять эффективность в реальных условиях и сравнивать алгоритмы для (2), (5), (6).
ip route add default \
nexthop via 206.250.80.122 dev ppp0 weight 1 \
nexthop via 198.5.13.201 dev eth0 weight 1
This balances network sessions originating from the router, but does usually not work for forwarded (NAT-ed) sessions from the LAN. To accomplish the latter, the script uses a combination of ip routing tables for outgoing connections, the firewall mark (fwmark) mechanism to select tables, and the iptables "mangle" chain to randomly select which ISP to use for outgoing connections:
iptables -t mangle -A PREROUTING -i eth2 -m conntrack --ctstate NEW \
-m statistic --mode random --probability 1 -j MARK-ISP1
iptables -t mangle -A PREROUTING -i eth2 -m conntrack --ctstate NEW \
-m statistic --mode random --probability 0.5 -j MARK-ISP2
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, cppguard, Вы писали:
N>В общем виде задача неподъёмно сложная. N>Я даже приблизительно боюсь описывать возможные приближения к решению, все они требуют высококвалифицированных админов, специально настроенных раутеров на выходе, динамической маршрутизации внутри... и всё равно будет только очень частичная эффективность. N>Коробочного решения не ищите — максимум их умений это из одного раутера перебросить часть трафика по фиксированным критериям, или весь при пропадании аплинка (которое они ещё и далеко не всегда детектят).
N>Но в общем нужно: N>1) Свои раутеры (условно, коробочки с Linux, куда можно заливать свой софт), связанные линком. NAT на каждом для обеих сетей. N>2) Свой протокол общения раутеров, который говорит "у меня сейчас есть свободный ресурс на аплинке" (и учти, что "сейчас" не значит, что через полминуты его не будет). Штатного такого не знаю, они все требуют реальных анонсов от таких аплинков. N>3) Connection tracking в них для применяемых протоколов (минимум для TCP и UDP), который позволяет делать свои хуки для новых соединений. N>4) QoS на выходе согласно источнику пакетов, который собирает статистику загрузок и потерь. N>5) Код, решающий для этих новых соединений, куда их отправлять, согласно загрузке сети. N>6) Вероятно, код, который по conntrack-таблице рубит чужие соединения при перегрузке (чтобы на следующий заход они пытались вырываться через свой родной раутер). Надо учитывать при этом загрузку не только на аплоад, но и на даунлоад.
N>Всё вместе тянет на аспирантский диплом или PhD диссер, если мерять эффективность в реальных условиях и сравнивать алгоритмы для (2), (5), (6).
А если сделать так. Настраиваем обе сети на балансировку трафика с помощью друг друга. Далее в каждой сети настраиваем queueing discipline так, чтобы в первую очередь уходили свои пакеты, а потом уже пакеты соседней сети.
