Резервиране на Интернет чрез втори доставчик (Failover)
Тази тема се каня да я направя от много време, не защото е сложна, а защото е сравнително рядък случай. Тук не става на въпрос да обединим два интернет доставчика за по-голяма скорост, а за отказоустойчивост на системата. Примерно изчезне интернета от главния доставчик и автоматично да се превключим на втория. За да стане по-интересна задачата ще покажа на по-късен етап единия доставчик да е през 4G модем на някакъв GSM оператор. Да уточним заданието: - имаме основен доставчик на Интернет - имаме резервен доставчик на Интернет - стандартно ако няма проблеми работим през основния доставчик - при проблем с основния автоматично се превключваме на резервния - време за превключване 10 секунди
За да се изпълни горната задача можем да ползваме два варианта. - Използване на помощния инструмент Netwatch - Използване на опцията `check-gateway Първия начин е по-прегледен и по-лесен за разбиране, затова ще започнем с него. Както споменах по-горе ще засегнем и темата 4G от доставчика на Интернет.
Резервиране чрез Netwatch
Предимства ● Автоматизация и гъвкавост: За разлика от простите заявки, Netwatch ви позволява да изпълнявате персонализирани конзолни команди. Това ви позволява да създавате сложни скриптове, например за промяна на маршрути, рестартиране на услуги или изпращане на известия. ● Гъвкава конфигурация: Всеки запис в Netwatch ви позволява да укажете IP адрес, интервал на ping и конзолен скрипт за изпълнение. Това позволява фина настройка на мониторинга за различни възли и сценарии. ● Проактивен отговор: Вместо пасивно наблюдение, Netwatch позволява проактивен отговор на повреди. Системата може автоматично да предприеме действия, когато даден възел стане недостъпен или, обратно, се върне в работно състояние, минимизирайки времето за престой. Недостатъци ● Фалшиви положителни резултати: Временните мрежови проблеми (като например високо натоварване) могат да доведат до генериране на фалшиви положителни резултати от Netwatch, което ще доведе до ненужно превключване към резервен възел и ще доведе до краткосрочен прекъсване на основната мрежа. ● Закъснение при превключване: Превключването към резервен възел не се случва мигновено. Има забавяне, свързано с времето, необходимо за откриване на повредата, вземане на решение и изпълнение на превключването. Това може да доведе до краткотрайна липса на услугата. ● Сложност на конфигурацията: Настройването и управлението на Netwatch в сложни и големи мрежи може да бъде трудоемко и да изисква обширни мрежови познания. Неправилната конфигурация може да доведе до неочаквани повреди или намалена производителност. ● Проблеми със синхронизацията: Когато използвате Netwatch заедно с други механизми (като например DHCP failover), могат да възникнат проблеми със синхронизацията на данни между основния и резервния възел. Това може да причини грешки в разпределението на IP адреси или други мрежови настройки. ● Зависимост от устройство: Netwatch е част от специфично мрежово устройство (напр. рутер или комутатор) и може да не функционира правилно, ако това устройство не е налично или не работи. В този случай, превключването при срив може да се провали. ● Ограничена функционалност: Netwatch обикновено е ограничен до проверка на наличността на устройства и извършване на прости действия, като рестартиране или превключване към резервен възел. Може да не е подходящ за сложни сценарии за превключване при срив, които изискват по-дълбока интеграция с други системи. Започваме с настройките на интерфейси eth1, eth2 и eth3 на рутера Mikrotik.
/ip address add address=10.0.0.2/24 interface=ether1 network=10.0.0.0 add address=172.16.0.2/24 interface=ether2 network=172.16.0.0 add address=192.168.0.1/24 interface=ether3 network=192.168.0.0
И чрез WinBox.
Дефинираме трите интерфейса:
Свързахме рутера към двата доставчика на Интернет, но само до шлюзовете по подразбиране. Освен това дефинирахме интерфейса който ще гледа към нашата вътрешна мрежа (ether3). За да излезем в Интернет трябва да дефинираме маршрути по подразбиране за двата доставчика. Особено обърнете внимание на приоритета и коментара на маршрутите.
/ip route add comment=ISP1 distance=1 gateway=10.0.0.1 add comment=ISP2 distance=2 gateway=172.16.0.1
Създадохме два пътя по подразбиране. Единия е до ISP1 (първия доставчик на Интернет), а другия е до ISP2 (втория доставчик). Отново обърнете внимание на параметъра Distance:. Колкото числото е по-малко толкова пътя е по-важен. Грубо казано малкото число е с приоритет и пътя по подразбиране на рутера ще е този който има по-малка стойност. Също важно нещо за по-късен етап е коментара към пътищата. Дефинирали сме единия път да е с коментар ISP1, а другия да е ISP2 Можем да проверим дали излизаме в Интернет през двата доставчика.
/tool traceroute address=8.8.8.8 interface=ether1 # ADDRESS LOSS SENT LAST AVG BEST WORST 1 10.0.0.1 0% 16 1.5ms 1.6 1.2 2.8 2 192.168.11.1 0% 16 2.6ms 2.7 2.3 4.6 3 185.163.246.1 0% 16 7.7ms 7.6 7 8.3 4 78.128.4.3 0% 16 8ms 7.2 6.4 9.7 5 185.1.30.10 0% 16 11.6ms 11.8 10.7 15.3 6 74.125.243.37 0% 16 10.9ms 11.3 10.8 11.9 7 142.251.246.235 0% 16 11.5ms 11.6 10.9 12.1 8 8.8.8.8 0% 16 11.6ms 11.4 10.6 11.8 -- [Q quit|D dump|C-z pause]
Достигаме 8.8.8.8 през шлюза 10.0.0.1 който е на интерфейс ether1. Сега същото упражнение да го изпълним за втория шлюз (към втория доставчик).
/tool traceroute address=8.8.8.8 interface=ether2 # ADDRESS LOSS SENT LAST AVG BEST WORST 1 100% 3 timeout 2 100% 3 timeout 3 100% 3 timeout 4 100% 3 timeout 5 100% 2 timeout
Нямаме достъп до Интернет през втория шлюз. Това е така защото Distance = 2 и това е по-маловажен път по подразбиране. За да стане активен трябва първия шлюз да се забрани. На по късен етап това условие ще го ползваме. Сега да създадем NAT на вътрешната мрежа за да може да излезе към Интернет.
/ip firewall nat add action=masquerade chain=srcnat out-interface=ether1 add action=masquerade chain=srcnat out-interface=ether2
И сега ако направим тест през компютъра VPC.
VPCS> ping 8.8.8.8 84 bytes from 8.8.8.8 icmp_seq=1 ttl=118 time=15.758 ms 84 bytes from 8.8.8.8 icmp_seq=2 ttl=118 time=14.429 ms 84 bytes from 8.8.8.8 icmp_seq=3 ttl=118 time=12.626 ms 84 bytes from 8.8.8.8 icmp_seq=4 ttl=118 time=13.170 ms
Да проверим през кой маршрут преминаваме:
VPCS> trace 109.160.80.230 trace to 109.160.80.230, 8 hops max, press Ctrl+C to stop 1 192.168.0.1 1.144 ms 0.811 ms 0.752 ms 2 10.0.0.1 3.118 ms 2.279 ms 1.982 ms 3 192.168.11.1 4.168 ms 3.191 ms 3.329 ms 4 185.163.246.1 8.706 ms 7.766 ms 9.876 ms 5 *109.160.80.230 12.206 ms (ICMP type:3, code:3, Destination port unreachable)
Ползваме маршрута през първия доставчик на Интернет. Както казахме той е с Distance = 1 и е с по-висок приоритет. За да минем през втория доставчик то маршрута по подразбиране трябва да се забрани от първия доставчик. За да се изпълнят горните команди клиентския компютър трябва да има дефиниран IP адрес и шлюз по подразбиране. Стигаме до същината на задачата. Как да направим така, че когато отпадне първия доставчик, автоматично да се пренасочим към втория. За целта: 1. Винаги следим някакво публично IP (примерно 8.8.4.4, DNS-a на Google). 2. Ползваме помощен инструмент на Mikrotik наречен Netwatch. Това са двете необходими условия за да се изпълни задачата. През основния доставчик постоянно да следим досъпа до IP а адрес:8.8.4.4
/ip route add distance=1 dst-address=8.8.4.4/32 gateway=10.0.0.1
Така винаги ще достъпваме 8.8.4.4 през шлюза 10.0.0.1 За да сме сигурни, че ще го виждаме само през основния доставчик трябва да го забраним да се достъпва през резервния.
/ip firewall filter add chain=output dst-address=8.8.4.4 out-interface=ether2 action=drop
Сега вече постоянно ще следим IP 8.8.4.4 през основния доставчик на Интернет (ISP1). Следващата задача е да дефинираме някакви правила при отпадане на връзката до 8.8.4.4 и при възстановяване. За целта ще ползваме помощна програма Netwatch.
/tool netwatch add host=8.8.4.4 interval=10s
Сега вече през 10 секунди следим дали имаме достъп до IP: 8.8.4.4 Следваща стъпка е при отпадане на основния доставчик да се превключим на допълнителния. За целта следим IP: 8.8.4.4 и когато го достъпваме то състоянието на задачата в Netwatch е със статус up. Когато пък не можем да го достъпим то статуса става down. Използвайки тази особеност ще направим правил при състояние UP и състояние DOWN. Да видим когато го достъпваме през основния доставчик какво е състоянието:
/tool netwatch print Flags: X - disabled # HOST TIMEOUT INTERVAL STATUS 0 8.8.4.4 1s 10s up
Сега да имитираме повреда в доставката на Интернет през първия доставчик. Просто махаме кабела свързващ ни с първия доставчик (ISP1). Проверяваме наново в Netwatch състоянието на задачата.
/tool netwatch print Flags: X - disabled # HOST TIMEOUT INTERVAL STATUS 0 8.8.4.4 1s 10s down
Ако върнем връзката към ISP1 то статуса на задачата ще стане UP. Задачата която нататък трябва да изпълним е да използваме статусите на задачата. - при статус down трябва да забраним шлюза по подразбиране до ISP1 - при статус up трябва да активираме пак шлюза до ISP1 За по-нагледно ще го покажа първо през WinBox, а след това и през конзолата.
И самата задача в подробности:
А сега в терминала. За начало да определим номера на правилото в Netwatch.
/tool netwatch print Flags: X - disabled # HOST TIMEOUT INTERVAL STATUS 0 8.8.4.4 1s 10s up
Номера е 0. След това добавяме правилата за UP и DOWN за номер 0.
/tool netwatch set numbers=0 down-script="/ip route set [find comment=\"ISP1\"] disabled=yes\r\ \n/ip route set [find comment=\"ISP2\"] disabled=no" host=8.8.4.4 \ interval=10s up-script="/ip route set [find comment=\"ISP1\"] disabled=no\ \r\ \n/ip route set [find comment=\"ISP2\"] disabled=yes"
Наново да проверим като отключим връзката към ISP1.
Виждаме, че маршрута по подразбиране към ISP1 е деактивиран, защото правилото в Netwatch е със статус down. Сега да се прехвърлим към клиентския коммпютър VPC и от там да проверим маршрута до 109.160.80.230
VPCS> trace 109.160.80.230 trace to 109.160.80.230, 8 hops max, press Ctrl+C to stop 1 192.168.0.1 0.986 ms 0.716 ms 0.678 ms 2 172.16.0.1 3.828 ms 1.951 ms 1.818 ms 3 192.168.11.1 4.096 ms 2.772 ms 3.025 ms 4 185.163.246.1 8.252 ms 8.487 ms 8.136 ms 5 *109.160.80.230 12.439 ms (ICMP type:3, code:3, Destination port unreachable)
Шлюза към основния доставчик (ISP1) не е активен затова преминаваме през втория (ISP2) с шлюз по подразбиране 172.16.0.1 Ако върнем връзката към първия доставчик то и шлюза 10.0.0.1 ще се върне и той ще е основния през който ще се работи. Да върнем връзката и да проверим наново маршрута:
VPCS> trace 109.160.80.230 trace to 109.160.80.230, 8 hops max, press Ctrl+C to stop 1 192.168.0.1 0.779 ms 0.617 ms 0.572 ms 2 10.0.0.1 2.635 ms 1.761 ms 1.718 ms 3 192.168.11.1 3.227 ms 2.717 ms 2.683 ms 4 185.163.246.1 8.004 ms 8.077 ms 8.059 ms 5 *109.160.80.230 12.181 ms (ICMP type:3, code:3, Destination port unreachable)
Наново работим през основния маршрут. Всички работи прекрасно, обаче има нещо което леко дразни. Превключването между двата доставчика става сравнително бавно. Освен тези 10 секунди които сме сложили за проверка на IP: 8.8.4.4 има още едно забавяне произхождащо от наличието на стари връзки със стари маршрути. Можем да ги проверим като наново се прехвърлим на микротика и от конзолата напишем:
/ip firewall connection print Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, F - fasttrack, s - srcnat, d - dstnat # PR.. SRC-ADDRESS DST-ADDRESS TCP-STATE 0 S C icmp 10.0.0.2 8.8.4.4 1 C udp 192.168.11.111:62216 255.255.255.255:20561 2 C udp 192.168.11.1:67 255.255.255.255:68 3 C udp 0.0.0.0:68 255.255.255.255:67 4 C udp 192.168.11.111:65347 255.255.255.255:20561 5 S C s icmp 192.168.0.2 8.8.8.8 6 S C s icmp 192.168.0.2 8.8.8.8 7 S C s icmp 192.168.0.2 8.8.8.8 8 S C s icmp 192.168.0.2 8.8.8.8
Или да проверим през Winbox:
И да се върнем на проблема и неговото решение. Най-разумния начин е да се забърше всичко което е запомнено. Това се постига чрез командите:
/ip firewall connection tracking set enabled=no /ip firewall connection tracking set enabled=yes
Да ги допълним в задачата на Netwatch.
/tool netwatch print Flags: X - disabled # HOST TIMEOUT INTERVAL STATUS 0 8.8.4.4 1s 10s up /tool netwatch set numbers=0 down-script="/ip route set [find comment=\"ISP1\"] disabled=yes\r\ \n/ip route set [find comment=\"ISP2\"] disabled=no\r\ \n/ip firewall connection tracking set enabled=no\r\ \n/ip firewall connection tracking set enabled=yes" host=8.8.4.4 \ interval=10s up-script="/ip route set [find comment=\"ISP1\"] disabled=no\ \r\ \n/ip route set [find comment=\"ISP2\"] disabled=yes\r\ \n/ip firewall connection tracking set enabled=no\r\ \n/ip firewall connection tracking set enabled=yes"
Да проверим през Winbox.
Готово всичко работи както трябва. Последния проблем с кеширането на маршрутите също е решен.
Връзка чрез 4G модем
Ако едната или двете връзки към Интернет доставчиците се извършва чрез 4G модем, трябва да нямат дефинирани шлюзове по подразбиране. Другото нещо на което трябва да се наблегне това е в рутиращата таблица Distance да се предифинира ако съществува. Между другото същото се отнася при изграждане на връзки чрез PPPoE, DHCP, VPN и още каквото се сетите. За да се ориентирате какво представлява модема и връзката 4G, няколко снимки с физическа връзка.
Надявам се, че придобихте представа за физическата връзка. Сега да видим през Winbox какво получихме.
Забележете, автоматично се създаде интерфейс lte1. Това е 4G модема. С него автоматично идват IP адрес, маршрути дефинирани от модема. Да проверим:
Автоматично получихме IP адрес.
Автоматично получихме и динамични маршрути. Забележете шлюза по подразбиране е с Distance = 2. Няколко пояснения: 1. Имаме автоматичен шлюз по подразбиране. 2. На шлюза Distance = 2. 3. В нашия случай ако ще ползваме връзката като втори доставчик на Интернет, то нищо няма да променяме, защото Distance = 2. 4. Ако обаче примерно искате да ползвате този доставчик като трети или още по-назад като резерва то трябва шлюза по подразбиране да се забрани от самия модем. По принцип динамичния шлюз по подразбиране не можете да го забраните или изтриете през Mikrotik-a.
Връзка чрез PPPoE
Също много често използвана връзка към доставчика на Интернет.
Избираме PPPoE Client.
Обърнете внимание на кой интерфейс ще се изгради PPPoE връзката. В моя случай е на интерфейс ether2.
Тук важните неща са: - User: име на потребителя (дава се от доставчика на Интернет), - Password: парола на потребителя (дава се от доставчика на Интернет), - забранете ползването на Use Peer DNS, - забранете получаването на шлюз по подразбиране. Така ще получите връзка с доставчика на Интернет но шлюза по подразбиране ще го дефинирате отделно както бе показано в статията по-нагоре.
Връзка чрез DHCP
Аналогично с PPPoE Client и тук се изгражда връзка без да се дефинира шлюз по подразбиране.
Създаваме DHCP клиент на интерфейс ether2. Не ползваме автоматично получаване на DNS, NTP сървъри, както и маршрут по подразбиране. Така на по-късен етап ще се дефинират в зависимост от това дали връзката ще е основна или резервна.
Вариант 2. Резервиране чрез Check-Gateway
Предимства ● Автоматично превключване: Механизмът автоматично деактивира маршрута към недостъпния шлюз и превключва трафика към алтернативен, осигурявайки непрекъснатост на мрежата. ● Толерантност към грешки: Позволява ви да създадете резервиране на канали, което е важно за критично важни услуги. ● Леснота на внедряване: В малки мрежи, където администраторът контролира маршрутите, настройката check-gatewayе проста и ясна. ● Пестене на ресурси: check-gateway не изисква допълнителни процесорни ресурси и памет за работа, за разлика от някои други динамични протоколи. ● Надеждност: В сравнение с ръчното превключване, check-gateway работи по-надеждно, тъй като не изисква човешка намеса. Недостатъци ● Трудност на настройката: - Нестандартният и сложен интерфейс на RouterOS прави настройката трудна дори за опитни професионалисти. - Необходимо е задълбочено разбиране на мрежовите технологии, за да се използват ефективно. ● Уязвимости и сигурност: - Неправилната конфигурация може да направи устройството ви уязвимо и да го превърне в източник на мрежова заплаха. - Изисква много внимателна и правилна конфигурация, за да се предпази от злонамерен софтуер. ● Липса на интуиция: За разлика от по-простите устройства, Mikrotik предоставя много гъвкави, но не винаги интуитивни инструменти. ● Време за превключване: Превключването може да отнеме от 20 до 30 секунди, което може да е неприемливо за приложения със строги изисквания за латентност . ● Неефективност при трептящи канали: Механизмът не работи при периодични загуби на пакети, когато основният шлюз остава достъпен, но е нестабилен. За да работи правилно този метод наново ще трябва да се деактивират динамичните маршрути по подразбиране, получени примерно по PPPoE, DHCP и т.н. За справка може да погледнете малко по-нагоре в статията. Ще показвам командите само през конзола за да не става статията прекалено дълга.
Настройка на мрежовите интерфейси
Настройваме IP адреси към двата доставчика на Интернет и към локалната мрежа.
/ip address add address=10.0.0.2/24 interface=ether1 network=10.0.0.0 add address=172.16.0.2/24 interface=ether2 network=172.16.0.0 add address=192.168.0.1/24 interface=ether3 network=192.168.0.0
Крием всичко, което излиза от локалната мрежа, зад NAT
/ip firewall nat add src-address=192.168.0.0/24 action=masquerade chain=srcnat
Резервиране при използване на рекурсивно маршрутизиране
Предишният метод има един сериозен недостатък: той проверява наличността на шлюза на доставчика, но не проверява за достъп до интернет зад този шлюз. Може да се окажете в ситуация, в която няма интернет връзка, но превключването към резервен канал не се е случило. За да избегнете това, проверете наличността на външни, високодостъпни възли, а не шлюза на доставчика. Един метод за това се нарича рекурсивно маршрутизиране, което разгледахме подробно в отделна статия, така че тук просто ще покажем последователността на настройка, без да навлизаме в подробности. Първо, избираме два високодостъпни възела, в нашия случай това ще бъдат 8.8.8.8 и 9.9.9.9 , и ще регистрираме маршрут към всеки от тях през шлюзовете на първия и втория доставчик.
/ip route add dst-address=8.8.8.8/32 gateway=10.0.0.1 scope=10 add dst-address=9.9.9.9/32 gateway=172.16.0.1 scope=10
Обърнете внимание на стойността на Scope, в нашия случай scope=10; ако я оставите на стойността по подразбиране 30, рекурсивното маршрутизиране няма да работи! Scope - парамbетър на рекурсивната маршрутизация, който определя обхвата на маршрут при търсене на път в мрежа. Target Scope - Определя областта за търсене на маршрути. Търсенето спира, ако намереният маршрут има scope повече от target-scope. Примери за стойности по подразбиране: Статичен маршрут : scope=30, target-scope=10. Свързан маршрут : scope=10, target-scope=10. Динамични маршрути (OSPF, RIP) : scope=20, target-scope= 10 И една картинка със стойности на scope
Сега нека добавим рекурсивни маршрути за всеки доставчик със следните настройки: Dst. Address е оставен на стойността по подразбиране 0.0.0.0/0 , Gateway е 8.8.8.8 (високодостъпен възел за първия доставчик), Check Gateway - ping - указва проверката за наличност на шлюза, Distance е 1. За втория доставчик всичко е същото, но Gateway е 9.9.9.9 , а Distance е 2 .
/ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=1 check-gateway=ping /ip route add dst-address=0.0.0.0/0 gateway=9.9.9.9 distance=2 check-gateway=ping
Няма да навлизаме в подробности как работи това сега. Общата идея е, че рекурсивните маршрути в крайна сметка работят през действителните шлюзове на доставчиците, но проверяват наличността на високодостъпен възел зад него, а не шлюза на доставчика. Ако връзката се загуби, маршрутът се деактивира и следващият, по-дълъг маршрут поема контрола. Когато първият доставчик бъде възстановен, превключването ще се извърши автоматично. Накрая всички команди в сгъстен вид:
# Настройка на интерфейса и IP адреси към доставчиците на Интернет: /ip address add address=10.0.0.2/24 interface=ether1 /ip address add address=172.16.0.2/24 interface=ether2 # Настройка на интерфейса и IP адреса към вътрешната мрежа: /ip address add 192.168.0.1/24 interface=ether3 # Ще скрием всичко, което излиза от локалната мрежа, зад NAT: /ip firewall nat add src-address=192.168.0.0/24 action=masquerade chain=srcnat ###Осигуряване на превключване при срив с по-задълбочен анализ на канала### #Използвайки параметъра scope, ние определяме рекурсивни пътища до възли 8.8.8.8 и 9.9.9.9 /ip route add dst-address=8.8.8.8 gateway=10.0.0.1 scope=10 /ip route add dst-address=9.9.9.9 gateway=172.16.0.1 scope=10 # задайте 2 шлюза по подразбиране през възли, чиито пътища са зададени рекурсивно /ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=1 check-gateway=ping /ip route add dst-address=0.0.0.0/0 gateway=8.8.4.4 distance=2 check-gateway=ping