Продължение на:
Конфигуриране на Edge Router Lite на Ubiquiti Networks
Производител:
Ubiquiti Networks, Inc.
Вносители в България:
http://www.vesuviustreamline.com/
http://www.lancombg.com/
http://www.reloadbg.com/
http://www.alink4.com/
Форуми:
http://community.ubnt.com/t5/EdgeMAX/bd-p/EdgeMAX
В текущата версия 1.4 на EdgeOS има нова функционалност Wan Load Balance. За разлика от по голямата част от конкурентите си в тази дисциплина Ubiquiti са създали доста прост на вид но пък функционален интерфейс. Load Balance е обсъждана тема много пъти, проблема винаги е бил връзките, от кой wan ще излязат към определена дестинация. От една страна протоколи като https държат на всяка цена да сте с несменяем адрес в процеса на сесиите защото за каква афтентикация иначе говорим. От друга няма как по време на онлайн игра или достъп до база данни било то складов или счетоводен софтуер да създавате връзки от два различни интернет доставчици. Това което мен ме впечатли е найстина опростената конфигурация макар и в терминала тя се свежда до няколко реда. Както и факта, че скрипта сам открива default gateway на wan интерфейсите дори и те да са dhcp клиенти, може да се окаже тежеста на връзките (броя на връзките в проценти към кой gateway да отиват повече), броя пакети които след като се изгубят пада gateway и се route следващия. Още по хубавото е, че това може въобще да не се конфигурира и скрипта приема подразбиращите се настройки.
Нашата конфигурация:
локалната ни мрежа: 192.168.10.0/24
доставчик 1 – address: 93.155.130.20 gate: 93.155.130.17
доставчик 2 – address: 85.118.95.10 gate: 85.118.95.9
Пак повтарям, че не е задължително да имаме конфигурирани статични ип адреси към доставчиците, скрипта ги открива сам ако това са dhcp клиентски интерфейси.
Конфигуриране на ип адреси:
set interfaces ethernet eth0 address 192.168.10.1/24 set interfaces ethernet eth1 address 93.155.130.20/29 set interfaces ethernet eth2 vif 72 address 85.118.95.10/30 |
Конфигуриране на default gateway и на двата доставчика (ако има приети от dhcp не е нужно)
set protocols static route 0.0.0.0/0 next-hop 85.118.95.9 set protocols static route 0.0.0.0/0 next-hop 93.155.130.17 |
Конфигуриране на DNS сървъри и маскирането им
set system name-server 8.8.8.8 set system name-server 8.8.4.4 set service dns forwarding listen-on eth0 set service dns forwarding system |
Конфигуриране на DHCP сървър в локалната мрежа към клиентите ни
set service dhcp-server shared-network-name DHCPD subnet 192.168.10.0/24 default-router 192.168.10.1 set service dhcp-server shared-network-name DHCPD subnet 192.168.10.0/24 dns-server 192.168.10.1 set service dhcp-server shared-network-name DHCPD subnet 192.168.10.0/24 start 192.168.10.10 stop 192.168.10.50 |
Конфигуриране на NAT към двата доставчика
set service nat rule 5999 outbound-interface eth1 set service nat rule 5999 type masquerade set service nat rule 6000 outbound-interface eth2.72 set service nat rule 6000 type masquerade |
Конфигуриране на firewal WLB group (това всъщност са mangle правила които ще маркират идващите пакети от клиентите)
set firewall modify WLB rule 10 action modify set firewall modify WLB rule 10 modify lb-group LB-LAN |
Свързване на firewal WLB group към интерфейс eth0 (load balance трябва да знае от кой интерфейс идват пакетите)
set interfaces ethernet eth0 firewall in modify WLB |
Конфигуриране на самия Load Balance (двата интерфейса към доставчиците)
set load-balance group LB-LAN interface eth1 set load-balance group LB-LAN interface eth2.72 |
Проверка status. Това инфо всъщност е доста добре замислено защото с един поглед разбираш каква е конфигурацията, има ли паднал gateway, с каква тежест “weight” проценти излизат пакетите и вървят ли въобще пакети през интерфейсите.
ubnt@R2# run show load-balance status Group LB-LAN interface : eth1 carrier : up status : active gateway : 93.155.130.17 weight : 50 flows WAN Out : 159 WAN In : 0 Local Out : 414 interface : eth2.72 carrier : up status : active gateway : 85.118.95.9 weight : 50 flows WAN Out : 149 WAN In : 0 Local Out : 408 |
Проверка watchdog. Така наречения “пазач” ни показва състоянието не само сега но и в минало време, ако е имало паднал gateway той ще ни покаже кога е станало това и кога се е вдигнал както и колко пакети е изпратил, колко не е получил въпреки че не е сменял маршрута. Последната на пръв поглед посредствена информация се оказа доста сериозен мониторинг при мен защото разбрах, че в пиков час през единия gateway се губят пакети (впоследствие промених тежеста на gateway 60/40 и имаше положителен ефект)
ubnt@R2# run show load-balance watchdog Group LB-LAN eth1 status: Running pings: 174 fails: 2 run fails: 0/3 route drops: 0 ping gateway: ping.ubnt.com - REACHABLE eth2.72 status: Running pings: 174 fails: 5 run fails: 0/3 route drops: 0 ping gateway: ping.ubnt.com - REACHABLE |
Ето и самият конфигурационен файл:
config
Това са основните правила за конфигуриране на load balance в EdgeRouter Lite. Тъй като ping.ubnt.com ми се стори далече за тест на gateway аз промених дестинацията с по близка dir.bg за първия и abv.bg за втория доставчик:
set load-balance group LB-LAN interface eth1 route-test type ping target 194.145.63.12 set load-balance group LB-LAN interface eth2.72 route-test type ping target 194.153.145.104 |
След което се промениха резултатите в load balance watchdog
ubnt@R2# run show load-balance watchdog Group LB-LAN eth1 status: Running pings: 3 fails: 0 run fails: 0/3 route drops: 0 ping gateway: 194.145.63.12 - REACHABLE eth2.72 status: Running pings: 3 fails: 0 run fails: 0/3 route drops: 0 ping gateway: 194.153.145.104 - REACHABLE |
Опцията Failover
Имаме една приятна изненада, скрипта подържа и опцията failover. Често се случва да имаме основен доставчик и втори който да не ползваме. В този вариант при падането на първия скрипта автоматично ще пренасочи трафика към втория без да има нужда да местим кабели или да сменяме gateway ръчно. В текущата ни дотук конфигурация трябва да добавим само failover-only към интерфейса eth2.72 на втория ни доставчик.
set load-balance group LB-LAN interface eth2.72 failover-only |
По подразбиране проверката се извършва на всеки 10 секунди. Сега ще имитираме срив на първия ни доставчик за да видим какво ще ни покаже load balance status:
ubnt@R2# run show load-balance status Group LB-LAN interface : eth1 carrier : down status : failover gateway : 93.155.130.17 weight : 0 flows WAN Out : 76 WAN In : 0 Local Out : 65 interface : eth2.72 carrier : up status : failover gateway : 85.118.95.9 weight : 100 flows WAN Out : 2 WAN In : 0 Local Out : 33 |
Явно е, че eth1 на първия доставчик е down а eth2.72 на втория доставчик е up.
Нека си върнем първия доставчик и видим какво ще ни покаже load balance watchdog
ubnt@R2# run show load-balance watchdog Group LB-LAN eth1 status: Running pings: 1 fails: 0 run fails: 0/3 route drops: 1 ping gateway: 194.145.63.12 - REACHABLE last route drop : Sun Jan 26 01:29:40 2014 last route recover: Sun Jan 26 01:32:32 2014 eth2.72 status: Running failover-only mode pings: 55 fails: 0 run fails: 0/3 route drops: 0 ping gateway: 194.153.145.104 - REACHABLE |
Ето я и информацията в минало време кога е имало срив на мрежата в първия доставчик и кога се е въстановила.
Опцията Policy Based Routing в комбинация с Failover
Имаме още една приятна изненада, скрипта подържа и опцията Policy Based Routing в комбинация с Failover. Тук малко темата отива във висшия пилотаж на рутирането и става малко сложна конфигурация но приятния интерфейс ще облекчи това. Топологията на нашата мрежа ще се разшири до:
локална мрежа асоциирана към доставчик 1: 192.168.10.0/24
доставчик 1 – address: 93.155.130.20 gate: 93.155.130.17
локална мрежа асоциирана към доставчик 2: 192.168.20.0/24
доставчик 2 – address: 85.118.95.10 gate: 85.118.95.9
Тъй като ще използвам досегашната ни конфигурация първо ще създам втората ни локална мрежа 192.168.20.0/24 на интерфейса eth0
set interfaces ethernet eth0 address 192.168.20.1/24 |
Ще изтрия динамичното раздаване на адреси от dhcp сървъра защото вече ще имаме две локални мрежи и ще създам статично такова:
ubnt@R2# delete service dhcp-server shared-network-name DHCPD subnet 192.168.10.0/24 start [edit] ubnt@R2# set service dhcp-server shared-network-name DHCPD subnet 192.168.10.0/24 static-mapping sami ip-address 192.168.10.10 [edit] ubnt@R2# set service dhcp-server shared-network-name DHCPD subnet 192.168.10.0/24 static-mapping sami mac-address 00:22:fb:5d:21:8e [edit] ubnt@R2# commit [ service dhcp-server ] Stopping DHCP server daemon... Starting DHCP server daemon... [edit] ubnt@R2# save Saving configuration to '/config/config.boot'... Done [edit] |
Сега ще асоциирам мрежа 192.168.10.0/24 към доставчик 1 към вече създадената група WLB с правило 10
set firewall modify WLB rule 10 source address 192.168.10.0/24 |
И ще създам нова група в firewal LB-LAN-2 за новата ни мрежа 192.168.20.0/24 към доставчик 2 с правило 20
set firewall modify WLB rule 20 action modify set firewall modify WLB rule 20 modify lb-group LB-LAN-2 set firewall modify WLB rule 20 source address 192.168.20.0/24 |
Групата LB-LAN-2 ще я добавя в самия скрипт. Предполагам прави впечатление, че тук опцията failover е на интерфейса eth1 защото това е втората ни конфигурирана мрежа и първият ни доставик ще е резервен.
set load-balance group LB-LAN-2 interface eth1 failover-only set load-balance group LB-LAN-2 interface eth1 route-test type ping target 194.145.63.12 set load-balance group LB-LAN-2 interface eth2.72 route-test type ping target 194.153.145.104 |
Така, общо взето това е, но преди да видим резултатите от load balance status и watchdog все пак искам да преговорим пак самата конфигурация по секции:
ип адреси:
ubnt@R2# show interfaces ethernet eth0 { address 192.168.10.1/24 address 192.168.20.1/24 duplex auto firewall { in { modify WLB } } speed auto } ethernet eth1 { address 93.155.130.20/29 duplex auto speed auto } ethernet eth2 { duplex auto speed auto vif 72 { address 85.118.95.10/30 } } loopback lo { } [edit] |
Правила за WLB в firewal
ubnt@R2# show firewall modify modify WLB { rule 10 { action modify modify { lb-group LB-LAN } source { address 192.168.10.0/24 } } rule 20 { action modify modify { lb-group LB-LAN-2 } source { address 192.168.20.0/24 } } } [edit] |
Правила в самия WLB за двете локални мрежи. Мисля, че тук най ясно се вижда, че имаме създадени две групи LB-LAN за мрежа 192.168.10.0/24 към доставчик 1 с излизащи пакети през eth1 и резервен eth2.72 интерфейс и LB-LAN-2 за мрежа 192.168.20.0/24 в обратния вариант интерфейси eth2.72 основен и eth1 резервен. Всяка група си работи самостоятелно, тоест може да се конфигурира по различен начин, кое да пингва, през колко време да пингва и след колко изгубени пакети да смени маршрута по подразбиране,
ubnt@R2# show load-balance group LB-LAN { interface eth1 { route-test { type { ping { target 194.145.63.12 } } } } interface eth2.72 { failover-only route-test { type { ping { target 194.153.145.104 } } } } } group LB-LAN-2 { interface eth1 { failover-only route-test { type { ping { target 194.145.63.12 } } } } interface eth2.72 { route-test { type { ping { target 194.153.145.104 } } } } } [edit] |
И накрая да проверим състояните на нашата конфигурация с Policy Based Routing в комбинация с failover първо с load balance status:
ubnt@R2# run show load-balance status Group LB-LAN interface : eth1 carrier : up status : active gateway : 93.155.130.17 weight : 100 flows WAN Out : 430 WAN In : 0 Local Out : 279 interface : eth2.72 carrier : up status : failover gateway : 85.118.95.9 weight : 0 flows WAN Out : 0 WAN In : 0 Local Out : 222 Group LB-LAN-2 interface : eth1 carrier : up status : failover gateway : 93.155.130.17 weight : 0 flows WAN Out : 0 WAN In : 0 Local Out : 222 interface : eth2.72 carrier : up status : active gateway : 85.118.95.9 weight : 100 flows WAN Out : 0 WAN In : 0 Local Out : 222 [edit] |
И после с load balance watchdog
ubnt@R2# run show load-balance watchdog Group LB-LAN eth1 status: Running pings: 436 fails: 0 run fails: 0/3 route drops: 1 ping gateway: 194.145.63.12 - REACHABLE last route drop : Sun Jan 26 01:29:40 2014 last route recover: Sun Jan 26 01:32:32 2014 eth2.72 status: Running failover-only mode pings: 489 fails: 0 run fails: 0/3 route drops: 0 ping gateway: 194.153.145.104 - REACHABLE Group LB-LAN-2 eth1 status: Running failover-only mode pings: 113 fails: 0 run fails: 0/3 route drops: 0 ping gateway: 194.145.63.12 - REACHABLE eth2.72 status: Running pings: 113 fails: 0 run fails: 0/3 route drops: 0 ping gateway: 194.153.145.104 - REACHABLE [edit] |
Някак си приятно е да знаеш, че администрираш две мрежи на един рутер с два доставчика на Интернет и двете са защитени от срив. Така пазиш здравето на клиентите си спестявайки драмата с “падането на нета” а и твоят сън ще е по здрав 🙂
конфигурацията с Policy Based Routing в комбинация с failover
policy-config
Забележка:
Има една тънкост която не трябва да се пропуска. Тъй като на двете мрежи дестинациите са към различни доставчици на Интернет нормално е те да не се виждат като съседи на един интерфейс а през доставчиците. За да избегнем момента в който компютри на съседни бюра в един сиуч обменят файл през Интернет можем да добавим следните правила които на практика добавят двете локални мрежи в главната (main) таблица на рутера. По този начин компютрите на двете съседни бюра ще обменят файла през рутера и няма да излиза в Интернет.
set firewall group network-group LAN network 192.168.10.0/24 set firewall group network-group LAN network 192.168.20.0/24 set firewall modify WLB rule 5 action modify set firewall modify WLB rule 5 destination group network-group LAN set firewall modify WLB rule 5 modify table main |
Policy Based Routing for destination port
Скрипта поддържа още една възможност която всъщност аз реално ползвам. След като имаме конфигуриран wan load balance и той работи за всички клиенти може да се получи така, че един или група от клиенти ще искат да минават само през единия доставчик или да ползват определни портове през него. В моя случай аз искам tcp портове 22,80,443 и 8080 да излизат винаги само от първия доставчик и естествено при срив да се пренасочват към втория. За целта ще създам още една група в firewal която ще нарека LB-PORT. Забележете, че втория ред с опцията destination port ако не се изпълни, целия трафик от ип адрес 192.168.10.10 ще излиза само през първия доставчик но тъй като аз искам само тези портове съм го описал по този начин.
set firewall modify WLB rule 6 action modify set firewall modify WLB rule 6 destination port 22,80,443,8080 set firewall modify WLB rule 6 modify lb-group LB-PORT set firewall modify WLB rule 6 protocol tcp set firewall modify WLB rule 6 source address 192.168.10.10 |
После ще добавя групата в самия load balance
set load-balance group LB-PORT interface eth1 set load-balance group LB-PORT interface eth2.72 failover-only |
Това последното “Policy Based Routing for destination port” някак си си го вмъкнал като опция а то си е задължително. Без да е насочен дестинейшън порт на 443 към банката връзката си се чупи задължително …
Така е, наистина, но исках да е последователно, този който чете да стигне стъпка по стъпка до пълната конфигурация а не да я изплюя наведнъж. Като гледам явно си запознат, ако искаш може да споделиш опит или да дадеш пример с някаква реална конфигурация … 🙂
Всичко работи перфектно вече месец, незнам защо ми излизат 20-30 процеса defunct в ps axf …
В един офис съм го направил като файловър, работи си добре, обаче като падне първия гейт се чупи днс-а, къде ли не ръчках няма оправяне. Сега му сложих дори 1.6 алфа, същата ралта. Ако имаш идея удари едно рамо.
Да така е – като падне единия доставчик и му пада днс а ти си с DHCP client, но има решение в което и аз малко се заиграх. Забележи опцията в интерфейс: dhcp-options name-server no-update – така ДХЦП клиента не взима днс от доставчика. Тоес днс трябва да е независим от двата доставчика и да вижда и от двамата едновременно. Ще ти дам пример с днс-те на google.
Oписваш ръчно днс в систем а в сървис го добавяш че, е от систем.
Ето готов вариант:
name-server no-update – е няма от къде да знам за тази опция а го бях мисли,сякак, дори да си напиша скрипт на баш който да трие и да създава пак днс-те – – – благодаря 🙂
При мен този вариант работи вече две години без никакъв проблем, уникално е как с няколко реда се постига такъв ефект. Преди пробвах с какво ли не. Въобще не съжалявам, че след като прочетох тази статия рискувах и си купих рутера. Сега има едни Edgerouter X – прекалено малки и смешни ми изглеждат, дали и те имат пълната функционалност на edgemax-a ?