Blog

Перфектният load balance – EdgeMax V1.6 на Ubiquiti

Тази статия е провокирана от господин Динко Милев от ComTech Bulgaria по повод няколкото дискусии които водихме има ли все пак рационално решение за внедряване на load balance в по малките мрежи.

Edge-MAX

конфигуриране на IP адрес

Нека започнем от там, че перфектен load balance няма но пък има няколко трикчета който ще ни помогнат да направим почти незабележимо балансирането на Интернет свързаност за клиентите ни. За пример ще използвам класически случай на нашия LAN и два WAN1 и WAN2 доставчика на Интернет. За по просто и двата доставчика ще ни дават ип адрес с dhcp а нашата локална мрежа ще е 192.168.1.1/24.

set interfaces ethernet eth0 address 192.168.1.1/24
set interfaces ethernet eth0 description LAN
 
set interfaces ethernet eth1 address dhcp
set interfaces ethernet eth1 description WAN1
set interfaces ethernet eth1 dhcp-options name-server no-update
 
set interfaces ethernet eth2 address dhcp
set interfaces ethernet eth2 description WAN2
set interfaces ethernet eth2 dhcp-options name-server no-update

конфигуриране на DNS

Когато правим load balance или failover не е добра идея да ползваме DNS сървърите на доставчиците си на Интернет защото при сриването и, нашият рутер ще продължава да пита DNS сървър до който няма достъп. Поради тази причина на двата интерфейса добавям опцията “name-server no-update” а на самият рутер добавям свободните DNS сървъри на google 8.8.4.4 и 8.8.8.8 които трябват да се виждат винаги и при двата доставчика без значение кой е отпаднал по някаква причина.

set system name-server 8.8.4.4
set system name-server 8.8.8.8

конфигуриране на cache DNS

След като конфигурирахме DNS сървъри за нашия рутер сега трябва да направим същото и за нашите клиенти. Кеширането на записите на имена в EdgeRouter става с dnsmasq. Опцията “listen-on eth0” показва на кой интефейс ще отговаря на клиенти демона в случая eth0 което е нашия LAN а опцията “system” dnsmasq да приеме настройките за DNS на самият рутер от секцията “system name-server” където преди малко описахме 8.8.4.4 и 8.8.8.8

set service dns forwarding listen-on eth0
set service dns forwarding system

конфигуриране на NAT

Тук ще създадем NAT за двата доставчика на външните ни интерфейси eth1 и eth2 защото използваме private мрежа 192.168.1.0/24 която е на eth0.

set service nat rule 6001 outbound-interface eth1
set service nat rule 6001 type masquerade
set service nat rule 6002 outbound-interface eth2
set service nat rule 6002 type masquerade

конфигуриране на DHCP

Описваме в DHCP мрежата на нашия LAN eth0.

set service dhcp-server shared-network-name POOL1 subnet 192.168.1.0/24 default-router 192.168.1.1
set service dhcp-server shared-network-name POOL1 subnet 192.168.1.0/24 dns-server 192.168.1.1
set service dhcp-server shared-network-name POOL1 subnet 192.168.1.0/24 start 192.168.1.101 stop 192.168.1.150

Проверка на конфигурацията до тук

Преди да пристъпим към самият load balance трябва да се убедим че, нашият рутер е вдигнал ип адресите на доставчиците ни на интернет и е готов за работа.

какви адреси е вдигнал нашият рутер:

ubnt@ERL# run show interfaces 
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface    IP Address                        S/L  Description                 
---------    ----------                        ---  -----------                 
eth0         192.168.1.1/24                    u/u  LAN                         
eth1         85.118.95.35/27                   u/u  WAN1                        
eth2         10.125.3.2/24                     u/u  WAN2                        
lo           127.0.0.1/8                       u/u                              
             ::1/128                          
[edit]

какви маршрути е вдигнал нашият рутер:

ubnt@ERL# run show ip route 
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route
 
S>* 0.0.0.0/0 [210/0] via 85.118.95.33, eth1
  *                   via 10.125.3.1, eth2
C>* 10.125.3.0/24 is directly connected, eth2
C>* 85.118.95.32/27 is directly connected, eth1
C>* 127.0.0.0/8 is directly connected, lo
C>* 192.168.1.0/24 is directly connected, eth0
[edit]

До тук всичко е наред, и на двата WAN сме вдигнали ип адрес и имаме два маршрута по подразбиране с дестинация 0.0.0.0/0. Сега ни остава същинската част а имено load balance на WAN1 и WAN2 в комбинация с failover.

Wan Load Balance

Във firewall modify (което на практика е iptables mangle) създаваме група WLB която ще обслужва нашият load balance. Въпросното правило го прикачваме към скрипта lb-group който ще конфигурираме по долу и го кръщаваме BALANCE защото на практика то ще балансира нашия трафик между двата ни доставчика на Интернет.

set firewall modify WLB rule 100 action modify
set firewall modify WLB rule 100 modify lb-group BALANCE

В скрипта load-balance със създадената вече група BALANCE описвам интерфейсите към доставчиците eth1 и eth2. С опцията “route-test type ping target” задавам хост 8.8.4.4 към който ако падне ping-а всичкия трафик ще се пренасочи към другия доставчик eth2, тоест това е нашият failover. С опцията “weight” избирам тежеста (натоварването) в проценти колко трафик трябва да се консумира към въпросния доставчик спрямо другия. Ако си представим 100% трафик – 40% ще излизат през WAN1 и 60% през WAN2.

set load-balance group BALANCE interface eth1 route-test type ping target 8.8.4.4
set load-balance group BALANCE interface eth1 weight 40
set load-balance group BALANCE interface eth2 route-test type ping target 8.8.8.8
set load-balance group BALANCE interface eth2 weight 60

За да влязат правилата в сила трябва да “закачим” WLB към eth0 защото това е нашият LAN

set interfaces ethernet eth0 firewall in modify WLB

Въпреки че, изглежда че, изпълнихме нашата мисия с балансиране на натоварването всъщност практиката ще покаже че, ние не решихме проблема за нашите клиенти а го създадохме. Най простият пример който мога да дам е следният:
Когато клиент зад load balance се регистрира в сайт през https в един момент сесията създадена през първия доставчик може да излезе през втория и тогава в този случай връзката ще се счупи защото https следи източника. Представете си ако това е Интернет банкиране или SSH сесия колко неприятено се получава. Именно поради това ще създадем втора група FAILOVER в която ще опишем известните ни портове с който може да се случи това и ще ги насочим само към единия доставчик.

За да не създавам излишни правила в firewall ще създам група защото firewall я вижда като едно правило а и след това ще бъде по удобно да се добавят и изтриват портове в нея.

set firewall group port-group WLB-PORT port 20-23
set firewall group port-group WLB-PORT port 25
set firewall group port-group WLB-PORT port 80-81
set firewall group port-group WLB-PORT port 110
set firewall group port-group WLB-PORT port 143
set firewall group port-group WLB-PORT port 443
set firewall group port-group WLB-PORT port 465
set firewall group port-group WLB-PORT port 587
set firewall group port-group WLB-PORT port 993
set firewall group port-group WLB-PORT port 2526
set firewall group port-group WLB-PORT port 4444
set firewall group port-group WLB-PORT port 5060-5061
set firewall group port-group WLB-PORT port 8080
set firewall group port-group WLB-PORT port 8291
set firewall group port-group WLB-PORT port 10000-20000

Във firewall modify ще опиша групата като WLB-PORT едновремено и за tcp и за udp протокола за да не създавам две групи.

set firewall modify WLB rule 10 action modify
set firewall modify WLB rule 10 destination group port-group WLB-PORT
set firewall modify WLB rule 10 modify lb-group FAILOVER
set firewall modify WLB rule 10 protocol tcp_udp

В самият скрипт load-balance групата FAILOVER която е аналогична на BALANCE за eth2 ще добавя опцията “failover-only”. Така създадохме група от портове към които изходящия трафик ще излиза само през eth1 и падне ли той автоматично ще потече през eth2.

set load-balance group FAILOVER interface eth1 route-test type ping target 8.8.4.4
set load-balance group FAILOVER interface eth2 failover-only
set load-balance group FAILOVER interface eth2 route-test type ping target 8.8.8.8

С риск да стана банален нека все пак да обобщя. На eth0 имаме мрежа 192.168.1.0/24 където са нашите клиенти. На eth1 и eth2 имаме два доставчика на Интернет. За всички трафика се балансира с тежест 40% за eth1 и 60% за eth2. Създадохме група от портове за да осигурим безпроблемна работа на клиентите с опеделени услуги от рода на SSH,MAIL,HTTPS,VOIP и други който ще преминават само през доставчика на eth1.

Но какво ще стане ако определен хост зад рутера трябва да предостави някаква услуга като например web, ftp или ssh сървър ? Нищо ! Дори и с описването на DNAT връзката ще се счупи защото ще влезе през единия WAN и ще излезе през другия. И на този проблем има решение също с групата FAILOVER но разликата е че, при портовете конфигурирахме destination а в случая ще опишем source адреси който ще излизат пак само през eth1 (на практика това си е чист policy routing)

Тук ще създам група от адреси но може да е и група от мрежи в firewall group

set firewall group address-group WLB-ADDRESS address 192.168.1.98
set firewall group address-group WLB-ADDRESS address 192.168.1.99
set firewall group address-group WLB-ADDRESS address 192.168.1.100
set firewall group address-group WLB-ADDRESS address 192.168.1.101

lb-group пак е FAILOVER

set firewall modify WLB rule 20 action modify
set firewall modify WLB rule 20 source group address-group WLB-ADDRESS
set firewall modify WLB rule 20 modify lb-group FAILOVER

Важно е да се знае че, адресите които използваме в локалната ни мрежа на eth0 са частни (private) зад NAT но няма никакъв проблем те да са публични и дори да заделим за част от клиентите си такива те ще ги обслужват без проблем с трафик който преминава само през eth1 интерфейса.

Конфигурационния файл на рутера

boot file: config.boot

command file: command

firewall rule: wlb-firewall

Мониторинг

ERL има приличен интрумент за мониторинг на load balance

Мониторинг на конфигурацията

ubnt@ERL# run show load-balance status 
Group BALANCE
  interface   : eth1
  carrier     : up
  status      : active
  gateway     : 85.118.95.33
  weight      : 40
  flows
      WAN Out : 11046
      WAN In  : 0
    Local Out : 10350
 
  interface   : eth2
  carrier     : up
  status      : active
  gateway     : 10.125.3.1
  weight      : 60
  flows
      WAN Out : 16828
      WAN In  : 0
    Local Out : 12028
 
Group FAILOVER
  interface   : eth1
  carrier     : up
  status      : active
  gateway     : 85.118.95.33
  weight      : 100
  flows
      WAN Out : 13034
      WAN In  : 0
    Local Out : 6468
 
  interface   : eth2
  carrier     : up
  status      : failover
  gateway     : 10.125.3.1
  weight      : 0
  flows
      WAN Out : 45
      WAN In  : 0
    Local Out : 6455
 
[edit]

Мониторинг на свързаноста

ubnt@ERL# run show load-balance watchdog 
Group BALANCE
  eth1
  status: Running 
  pings: 3243
  fails: 6
  run fails: 0/3
  route drops: 1
  ping gateway: 8.8.4.4 - REACHABLE
  last route drop   : Sun Aug 24 11:59:36 2014
  last route recover: Sun Aug 24 12:00:19 2014
 
  eth2
  status: Running 
  pings: 3236
  fails: 0
  run fails: 0/3
  route drops: 1
  ping gateway: 8.8.8.8 - REACHABLE
  last route drop   : Sun Aug 24 11:59:35 2014
  last route recover: Sun Aug 24 12:00:18 2014
 
Group FAILOVER
  eth1
  status: Running 
  pings: 3243
  fails: 10
  run fails: 0/3
  route drops: 1
  ping gateway: 8.8.4.4 - REACHABLE
  last route drop   : Sun Aug 24 11:59:38 2014
  last route recover: Sun Aug 24 12:00:21 2014
 
  eth2
  status: Running 
  failover-only mode
  pings: 3236
  fails: 0
  run fails: 0/3
  route drops: 1
  ping gateway: 8.8.8.8 - REACHABLE
  last route drop   : Sun Aug 24 11:59:37 2014
  last route recover: Sun Aug 24 12:00:20 2014
 
[edit]

Мониторинг на скороста
erl-graph

port-forward

Тъй като ние създадохме група от адреси които са зад доставчика на WAN1 (192.168.1.98-101) можем да ги ползваме за сървърни услуги от рода на web и ftp:

set port-forward wan-interface eth1
set port-forward lan-interface eth0
 
set port-forward rule 10 forward-to address 192.168.1.98
set port-forward rule 10 forward-to port 80
set port-forward rule 10 original-port 80
set port-forward rule 10 protocol tcp
 
set port-forward rule 20 forward-to address 192.168.1.101
set port-forward rule 20 forward-to port 21
set port-forward rule 20 original-port 21
set port-forward rule 20 protocol tcp

В общи линии в рамките на 50-на реда команди ние постигнахме:

1. load balance с различна тежест на трафика на два доставчика комбиниран с failover.
2. policy routing на изходящия трафик през единия доставчик на група портове който не могат да се балансират комбиниран с failover
3. policy routing на група адреси асосиирани само към единия доставчик комбиниран с failover
4. port forwarding от единия доставчик към вътрешни адреси за услуги от рода на web, ftp и др.

До тук ние постигнахме най често задаваните въпроси и решенията им относно load balance с EdgeMax който незнам защо все още е подценяван на пазара.

Tags: , ,

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

This Post Has 4 Comments

  1. Plamen Dimov November 12, 2015

    Здравейте,
    дотук всичко добре, а как ще стане ако искам да има и втора лан мрежа

  2. Самуил Арсов November 13, 2015

    Няма проблем да създадеш друга лан мрежа, ще работи и тя.

  3. chain June 4, 2016

    Здравейте.
    имам едни ubnt edge router sfp и търся някой да ми го настрои. естествено ще си платя за услугата.
    ако сте заинтересувам моля пишете на е-мейла.

  4. Николай April 12, 2017

    Супер! Даже и работи 🙂
    Но при тази конфигурация и свързване на vpn клиент, той няма да получи шлюз и съответно заявките му към Интернет ще бъдат безразборно разхвърляни между двата ISP (проблем, коментиран и във форума на ubnt)
    https://community.ubnt.com/t5/EdgeMAX/Edgerouter-X-PPTP-server-with-load-balacing/td-p/1540018