У VyOS есть замечательная функция балансировки нагрузки между несколькими провайдерами. Очень хорошо кастомизируется под ситуацию.
В официальной документации довольно неплохо описаны основные возможности. Я в свою очередь немного расскажу о своём опыте и о правилах балансировки, которые вам точно понадобятся.
Проверка интерфейсов
Что бы занести интерфейсы провайдеров в балансинг, нужно использовать команду
set load-balancing wan interface-health $interface
Пример конфигурации интерфейсов с двумя провайдерами
10.10.1.1 — шлюз первого провайдера, 10.10.2.1 — шлюз второго провайдера.
set load-balancing wan 'flush-connections'
set load-balancing wan interface-health eth1 failure-count '2'
set load-balancing wan interface-health eth1 nexthop '10.10.1.1'
set load-balancing wan interface-health eth1 success-count '1'
set load-balancing wan interface-health eth1 test 10 resp-time '3'
set load-balancing wan interface-health eth1 test 10 target '8.8.8.8'
set load-balancing wan interface-health eth1 test 10 type 'ping'
set load-balancing wan interface-health eth1 test 20 resp-time '3'
set load-balancing wan interface-health eth1 test 20 target '8.8.4.4'
set load-balancing wan interface-health eth1 test 20 type 'ping'
set load-balancing wan interface-health eth1 test 30 resp-time '3'
set load-balancing wan interface-health eth1 test 30 target '173.245.58.51'
set load-balancing wan interface-health eth1 test 30 type 'ping'
set load-balancing wan interface-health eth2 failure-count '2'
set load-balancing wan interface-health eth2 nexthop '10.10.2.1'
set load-balancing wan interface-health eth2 success-count '1'
set load-balancing wan interface-health eth2 test 10 resp-time '3'
set load-balancing wan interface-health eth2 test 10 target '8.8.8.8'
set load-balancing wan interface-health eth2 test 10 type 'ping'
set load-balancing wan interface-health eth2 test 20 resp-time '3'
set load-balancing wan interface-health eth2 test 20 target '8.8.4.4'
set load-balancing wan interface-health eth2 test 20 type 'ping'
set load-balancing wan interface-health eth2 test 30 resp-time '3'
set load-balancing wan interface-health eth2 test 30 target '173.245.58.51'
set load-balancing wan interface-health eth2 test 30 type 'ping'
В первой же строчки конфигурации нас ждёт засада. flush-connections означает что если один из интерфейсов упадёт, то все активные соединения будут сброшены, для того, чтобы перестроить маршрут. Это очень ощущается при ssh соединениях. При обрыве одного провайдера, у вас будут падать ssh сессии, а потом ещё при подъеме. Поэтому к настройке мониторинга интерфейса надо подходить с умом. Потому что без этой настройки всё будет работать неочень.
Параметр failure-count — это количество попыток теста, после которых интерфейс деактивируется. А success-count это количество успешных попыток теста для активации деактивированого интерфейса. nexthop — шлюз провайдера.
Дальше описываются правила проверки, у вас оно может быть хоть одно, хоть 10. Проверка может быть двух типов icmp и tcp. Про tcp не могу сказать ничего, ибо не использовал. Собственно параметр type описывает тип проверки, resp-time — время за которое должен быть получен ответ в секундах. target — цель проверки, ip адрес ресурса.
Как вообще работает проверка?
Проверка идёт по возрастанию, в моём примере сначала проверяется 1ое правило. Пингуется 8.8.8.8 и только если оно перестанет отвечать, проверка переходит к следующему правилу. И только если все три правила не проходят проверку, в соответствии с заданными параметрами, — интерфейс деактивируется. Состояние текущих проверок можно глянуть командой
show wan-load-balance
Выглядит вот так:
Interface: eth1
Status: active
Last Status Change: Wed May 23 12:22:22 2018
+Test: ping Target: 8.8.8.8
Test: ping Target: 8.8.4.4
Test: ping Target: 173.245.58.51
Last Interface Success: 0s
Last Interface Failure: 6d22h2m43s
# Interface Failure(s): 0
Interface: eth2
Status: active
Last Status Change: Wed May 23 12:22:22 2018
+Test: ping Target: 8.8.8.8
Test: ping Target: 8.8.4.4
Test: ping Target: 173.245.58.51
Last Interface Success: 0s
Last Interface Failure: n/a
# Interface Failure(s): 0
8.8.8.8 и 8.8.4.4 я поставил для примера, вообще не рекомендую их использовать, потому что это слишком отказоустойчивый сервис. Этот гугловый сервер может стоять у вашего провайдера, а навернется магистраль и для проверки всё будет ОК, а интернетов нормальных не будет. Поэтому лучше всего использовать ваши внутренние корпоративные сервисы и какой-нибудь левый отказоустойчивый сервис. Например 173.245.58.51 — это ntp cloudflare (находится только в США), как минимум, он даёт страховку на случай того, если ваши серваки стоящие в проверке навернутся.
Почему я так ратую за адреса? В моей практике были случаи, когда у балансинга стояла проверка серверов, находящихся в России, а обрывалась магистраль у провайдера до США. Поэтому подумайте хорошо, какие лучше адреса и в каком порядке использовать. Ну и проверьте чтоб они не блокировались.
Правила балансировки
Для работы балансера нужно как минимум одно правило
set load-balancing wan rule 500 description 'main load-balancing'
set load-balancing wan rule 500 inbound-interface 'eth0'
set load-balancing wan rule 500 interface eth1 weight '1'
set load-balancing wan rule 500 interface eth2 weight '1'
set load-balancing wan rule 500 protocol 'all'
inbound-interface — интерфейс локальной сети, где находятся клиенты
interface— под этим параметром вносим интерфейсы, между которыми должна работать балансировка и его вес
С protocol и description и так всё ясно.
Это общее правило, которое затрагивает всех клиентов, подключенных к шлюзу. Трафик балансируется равномерно между ними. Если у вас, например, один провайдер 50 мбит\с, а другой 100 мбит\с, то поставьте веса к примеру 1 и 2 или 50 и 100, чтобы нагрузка распределялась равномерно.
Так же есть возможность сделать режим failover
set load-balancing wan rule 500 failover
Веса тут будут служить для failover’a приоритетом. У кого вес больше — тот и работает. Если интерфейс с большим весом падает, то переходит на второй. Возможно у вас один из провайдеров очень медленный (3g или 4g например) или просто плохо работает и вы не можете с этим ничего поделать, а деваться некуда. Тогда failover в основном правиле очень даже кстати.
Но, если у вас всё-таки балансировка то, как показывает практика, одним правилом не обойдешься.
Начнем с того, что VoIP не умеет работать с балансировкой. Вынесем подсеть с телефонами в отдельное правило
set load-balancing wan rule 5 description 'VoIP traffic'
set load-balancing wan rule 5 'failover'
set load-balancing wan rule 5 inbound-interface 'eth0'
set load-balancing wan rule 5 interface eth1 weight '1'
set load-balancing wan rule 5 interface eth2 weight '100'
set load-balancing wan rule 5 protocol 'all'
set load-balancing wan rule 5 source address '172.16.1.0/24'
Тут используем параметр source address, все кто из подсети 172.16.1.0/24 будут ходить только через одного провайдера.
Так же есть сервисы, которые не могут работать с двумя разными IP в одной сессии. Например, PPTP серверы, некоторые банковские сервисы, LDAP Account Manager и.т.д
set load-balancing wan rule 10 description 'One IP service'
set load-balancing wan rule 10 destination address '0.0.0.0'
set load-balancing wan rule 10 'failover'
set load-balancing wan rule 10 inbound-interface 'eth0'
set load-balancing wan rule 10 interface eth1 weight '100'
set load-balancing wan rule 10 interface eth2 weight '1'
set load-balancing wan rule 10 protocol 'all'
Тут используем параметр destination address, которому задаём ip адрес сервиса.
В общем, настраивать можно по-разному. Помните, что главное правило должно стоять в самом конце, иначе остальные правила работать не будут.
Ещё на заметку, шлюз провайдера настраивается не только по команде set load-balancing, но и в маршрутах
set protocols static route 0.0.0.0/0 next-hop '10.10.1.1'
set protocols static route 0.0.0.0/0 next-hop '10.10.2.1'
Мой телеграм-канал .