Имеется машина с 3-мя сетевыми интерфейсами. 1-й внутренный (10.x.x.x), 2-й и 3-й внешние (линки на разных провов). Мне нужно написать программу, которая будет делить исходящий трафик между 2 каналами. Под никсы пишу 1 раз, поэтому не знаю за что браться. Пишу на с++ в Qt. Как мне получить доступ к сетевым интерфейсам? Придется на уровне драйвера делать, или можно без них обойтись?
А по какому принципу трафик будет делиться? Если там статические правила, до не надо ничего писать -- iptables и всё. Если динамические -- уломать апстримов поднять BGP или RIP или что там ещё у них есть.
Весьма странная тема для диплома. Потому как единственный правильный способ - BGP, для чего надо иметь AS и сетку к ней не меньше /24 (а это достаточно дорогое удовольствие, чтоб быть реализованным для единственного компа, а не для огромной организации с кучей компов), и единственно, что потребуется программного - это реализация протокола BGP на компе, что будет очередным велосипедом. Проще взять какую-нибудь Zebra или что там посовременнее есть. Другие протоколы, типа RIP/OSPF/EIGRP и подобные вообще не катят - они только для внутрених дел одного провайдера или в крайнем случае для провайдерских "междусобойчиков" без анонсирования в инете. Другие способы (без BGP, AS и сети /24) - кривые костыли: 1. Разруливание на уровне соединений, устанавливаемых от имени того или иного интерфейса. Упрощенный способ - перекидывание дефаулт-маршрута в зависимости от загрузки на интерфейсах, соединения будут устанавливаться от того имени, через кого в данный момент смотрит дефаулт, и по входящему трафику будут продолжать работать уже независимо от дефаулта (исходящий всегда будет следовать за дефаултом при отсутствии специфик-маршрутов). Способ может оказаться неработающим, поскольку некоторые провайдеры режут пакеты с чужими сорс-адресами. 2. Более правильно - поддержание постоянно меняющейся большой таблицы специфик-маршрутов к дестинейшнам активных на данный момент соединений. В любом случае балансинг трафика будет малоэффективен при небольшом количестве соединений, поскольку каждое отдельное соединение будет устанавливаться от имени того или иного ip-адреса и не может быть переброшено во время своего существования. 3. Установка туннелей через разных провайдеров к некоторому узлу, находящемуся в надежной точке инета или имеющему надежность за счет BGP. Этот способ позволяет балансить более точно, на уровне отдельных пакетов путем поднятия RIP/OSPF/EIGRP с пер-пакет балансингом внутри туннелей, но требует наличия такого узла, предоставляющего для вашего компа туннельную функциональность. Опять же, программирование в данном случае - это изобретение велосипеда.
Блин, не заметил Все вышенаписанное конечно же было про полный балансинг. Если же речь только об исходящем трафике - то читайте таблицу текущих соединений и рулите специфик маршруты. Если провайдеры не режут чужие сорсы - то вообще можно просто сделать два дефаулта с одинаковыми метриками и задача автоматом решается даже на уровне отдельных пакетов.
Вот привожу кусочек записки 2.1.2 Назначение и цели создания системы Целью проекта является обеспечение рационального использования двух каналов в сеть Интернет с возможностью автоматического резервирования. В системе должны быть реализованы следующие основные функции: 1) распределение трафика по типу; 2) распределение нагрузки по подсетям; 3) пропорциональная балансировка трафика между несколькими внешними интерфейсами; 4) резервирование сетевых каналов. В результате внедрения данной системы должны быть решены следующие задачи: 1) снижение стоимости сетевого трафика; 2) снижение нагрузки на каждый из каналов как следствие балансировки нагрузки между ними; 3) повышение уровня надежности и отказоустойчивости сети; 4) снижение себестоимости готового продукта за счет бесплатного программного обеспечения на этапе разработки и эксплуатации. То биш, идет речь о доступе нашей подсети к глобальной сети посредством 2 каналов. У меня только мысли о этаком NAT сервере с возможностью выбирать внешний канал для работы.
