MikroTik, load balancing, ECMP, recursive failover, port source route
Никога не съм бил привърженик на load balancing но истината е, че по някой път се налага. Обикновенно това се случва в домашни условия или в малък офис. Решението да имаш два независими един от друг доставчика на Интернет винаги е било по добро от един на бизнес тарифа защото въпроса обикновенно освен до добра свързаност към глобалната мрежа опира и до отказоусточивост. Естествено това което ще покажа тук не е идеално решение защото според мен в load balancing такова няма, но е база в която ако се пипне тук там може да задоволи малък брой потребители.
конфигуриране на DNS
Като начало трябва да добавим DNS сървъри които са независими и от двата ни доставчика на Интернет защото ако падне някой от тях или ще ни се влоши връзката или въобще няма да имаме Интернет. В случая ще използваме сървърите на open dns като вече доказали се с надежност.
/ip dns set allow-remote-requests=yes servers=208.67.222.222,208.67.220.220 |
маркиране на изходящия трафик с routing mark
Тъй като за load balancing ще използваме ECMP което не е най интелигентното решение но за сметка на това пък е много просто трябва да маркираме част от изходящия трафик. Трафик който трябва да сме сигурни, че излиза през единия ни доставчик за да нямаме проблем с протоколи като www,ssl,mail,voip,ssh и др които изискват аутентикация или пък следят източника на пакети. Разбира се в тези правила може да се добавят и портове на игри или други приложения ако е нужно това.
/ip firewall mangle add action=mark-routing chain=prerouting dst-port=20-23,25,80-81,110,143,443,465,585,587 new-routing-mark=SRC-ROUTE1 protocol=tcp add action=mark-routing chain=prerouting dst-port=993,995,2222,2526,4444,5060-5061,8080,8291 new-routing-mark=SRC-ROUTE1 protocol=tcp add action=mark-routing chain=prerouting dst-port=5060-5061,10000-20000 new-routing-mark=SRC-ROUTE1 protocol=udp |
конфигуриране на NAT
Стандартно трябва да маскираме и двата ни доставчика на Интернет.
/ip firewall nat add action=masquerade chain=srcnat out-interface=ether1 add action=masquerade chain=srcnat out-interface=ether2 |
конфигуриране на load balancing
Часта с routinga идва малко сложна поради което ще и обърна малко по сериозно внимание защото освен ECMP ще използваме и recursive failover както и на самият load balancing така и на изходящия трафик който маркирахме да минава само през единия доставчик. Идеята вече я споменах ОТКАЗОУСТОЧИВОСТ. При правилна конфигурация ако падне единия доставчик свързаноста ще се изгуби за 10-20 секунди което е в рамките на търпимото.
/ip route add distance=1 dst-address=8.8.4.4/32 gateway=10.125.3.1 scope=10 add distance=1 dst-address=8.8.8.8/32 gateway=85.118.95.33 scope=10 add check-gateway=ping distance=1 gateway=8.8.4.4,8.8.8.8 |
В първите два реда рутираме двата хоста на google през двата ни доставчика за да знае рутера ни къде се намират те. Респективно 8.8.8.8 през първия и 8.8.4.4 през втория ни доставчик. В третия ред правим три неща едновременно:
1. с gateway=8.8.4.4,8.8.8.8 създаваме load balancing с политика ECMP.
3. тъй като маршрута по подразбиране gateway е 8.8.4.4,8.8.8.8 а не на доставчиците ние създадохме recursive route
2. с check-gateway=ping следим дали ще падне някой от хостовете на google които на практика вече са нашите маршрути по подразбиране.
Допълнително подсигуряване с маршрут по подразбиране
Какво ще стане обаче ако по някаква причина изгубим достъп и до двата хоста на google ? Ясно е, че Интернет ще има след рутера а ние не, защото ще ни паднат маршрутите по подразбиране. Затова трябва да се подсигурим с още един такъв с по висока метрика distance=2 който ще се активира само ако паднат google хостовете които са с метрика distance=1.
/ip route add distance=2 gateway=85.118.95.33 |
failover на маркирания трафик
/ip route add check-gateway=ping distance=1 gateway=8.8.8.8 routing-mark=SRC-ROUTE1 add check-gateway=ping distance=2 gateway=8.8.4.4 routing-mark=SRC-ROUTE1 add distance=3 gateway=85.118.95.33 routing-mark=SRC-ROUTE1 |
Последното което трябва да направим е същото но с маркирания изходящ трафик който конфигурирахме в ip firewall mangle с routing-mark=SRC-ROUTE1. Тук трябва да следим само метриките, първия ред е маршрут на изходящия трафик по подразбиране, втория ще се активира ако падне първия а третия ако паднат двата google хоста. По този начин имаме failover не само на load balancing но и на маркирания трафик.
Тест на конфигурацията
На срииншота по долу виждаме зона 1 bridge което е LAN мрежата на рутера а в зона 2 трафика който преминава и през двата ни доставчика ether1 и ether2.
по тънки настройки
Може би някой ще зададе въпроса какво ще стане ако единия доставчик предлага два пъти по голяма скорост от другия ?. В ECMP има решение за този казус, нарича се тежест (weight). В реда с маршрута по подразбиране трябва да повторим два пъти gateway по този начин.
/ip route add check-gateway=ping distance=1 gateway=8.8.4.4,8.8.4.4,8.8.8.8 |
В случая през доствчик 2 с маршрут 8.8.4.4 ще преминават два пъти повече пакети от 8.8.8.8 като това няма да засяга маркирания трафик.
тест от страна на потребителя
При изходящ порт 80 винаги трябва да излизам с адреса на първия доставчик.
traceroute към dir.bg
traceroute към mail.bg
още маршрути от рутера
Тъй като споменах, че ECMP е малко “прост” в случай, че отвън искам да достъпя рутера ще се появи проблем от рода на постоянно появяване и изчезване. Това е така защото той разпределя пакетите според тежеста която сме му задали. За да гарантирам, че определен хост в случая 85.118.95.126 ще го вижда безпроблемно в Интернет ще създам още един маршрут.
ip route add dst-address=85.118.95.126 gateway=85.118.95.33 |
конфигурирне на DMZ
Често попадаме в ситуация в която имаме нужда от пренасочване на портове или от DMZ. Видеонаблюдения, локален сървър който искаме да достъпваме от Интернет и др. ИП адреса който ще използвам от локалната мрежа ще е 192.168.1.42 рутирайки го към доставчик 1 същия през който маркирахме изходящия трафик.
/ip firewall mangle add action=mark-routing chain=prerouting new-routing-mark=SRC-ROUTE1 src-address=192.168.1.42 |
Мисля, че е важно да добавя, че изходящия трафик на адреса 192.168.1.42 винаги ще излиза през първия доставчик и за да e достъпен той например на порт 10000 от интернет трябва да добавим правило в NAT.
/ip firewall nat add chain=dstnat in-interface=ether1 protocol=tcp dst-port=10000 action=dst-nat to-addresses=192.168.1.42 to-ports=10000 |
Много полезна статия. Имам един въпрос.
Статията започва с това, че не сте привърженик на load balancing. Кое е за предпочитане ако все пак разполагаме с два доставчика? Става въпрос за офис с около 20 компютъра. Оставам с впечатление, че и failover не е за предпочитане. Благодаря предварително.
Специално за Load Balancing, нищо му няма, просто е по специфичен. За ~20-на компютъра – да, за всеки един можеш да добавиш някакво правило за нуждите му (написано е вече горе https, ssh, smtps и други). Ако работното ти място е зад рутера още по добре макар, че диагностиката също е по трудна. Но ако си на отдалечено място и ти се обадят по тела да ти кажат, че нещо не работи трябва да си малко “шаман” за да оправиш нещата.
Failover е много по интуитивен ако нещо не работи, знаеш , че всичките пакети трябва да минат от тук, а не от тук и търсиш проблема на едно място за разлика от Load Balancing в който icmp (пинг) върви през първия доставчик а a https през втория и човека по тела ти казва, че не отваря сайтове и ти не си там на неговото PC но имаш достъп до рутера който не те устройва защото в Load Balancing е създал рутираща таблица да препраща пакети от клиента и тя не важи за самия рутер. Нарочно дадох точно този пример защото това е най често срещаната грешка в Load Balancing (това което вижда клиента и това което вижда рутера е нормално да не е едно и също).
Общо взето не е въпрос на вкус (харесва ? – не харесва ?) а въпрос на правилно решение което преобладава към – по малко клиенти Load Balancing / повече клиенти Fajlover.
Много благодаря за отговора. Категорично след Вашия коментар ще използвам Failover, тъй като аз съм извън офиса на въпросната фирма и ще действам отдаличено, което както казахте ще е малко по-трудоемко. При Failover обаче се натъквам на следния проблем: Когато физически паде интерфейса микротика превключва на другия доставчик, но ако спре връзката някаде преди нашия рутер не ще да отрази загубата на интернет. Това как се решава и решава ли се? Благодаря предварително.
И за този проблем има решение, преди да копираш правилата обаче ги огледай добре какво точно трябва да се промени при теб:
https://itservice-bg.net/failover-v-mikrotik-bez-izplnyavane-na-skript/
Тоест всичко досега се е чупило при мен само заради тъпия https. Благодарение на тази статия заработи нормално един офис с десетина компютъра и още толкова телефони зад него с балансиране на трафика. Найстина полезно !
А може ли да се замени вместо статичен IP адрес за WAN1/2 да се ползва само ether1, ether2. Т.е. доставчиците ни дават публични динамични адреси.
примерно:
/ip route
add distance=1 dst-address=8.8.4.4/32 gateway=ether1 scope=10
add distance=1 dst-address=8.8.8.8/32 gateway=ether2 scope=10
add check-gateway=ping distance=1 gateway=8.8.4.4,8.8.8.8
и т.н.