Плаващият резервен VPN маршрут не поема: контролен списък за превключване

Плаващите статични маршрути чакат допустимост, а не спиране на пакетите. Шест подредени проверки на пътя на сондата, праговете и връщането при VPN резерв.

Плаващият ви VPN маршрут е конфигуриран, разстоянието на резервния е по-голямо от това на основния, а нищо никога не се премества. Или се премества, а после се връща обратно минути по-късно, докато безжичната връзка все още е прекъсната. И в двата случая нещо различно от повредата, която ви интересува, решава допустимостта на маршрута.

Изпълнете тези проверки по ред. Всяка има условие за спиране и провалена проверка не може да бъде спасена от следващите. Примерите използват синтаксис на RouterOS, защото разстоянието, достъпността на шлюза и рекурсивният следващ хоп са видими в конфигурацията там, но редът важи за всеки рутер с проследявани статични маршрути.

Назовете повредата, която резервът трябва да покрие

„Основният е спрян“ са четири различни наблюдения. Радио, което губи своя партньор, интерфейс, който губи носителя си, отдалечен шлюз, който спира да отговаря, и приложение, което спира да работи, изглеждат различно от мястото на рутера. Запишете за кое от тях е проектът, преди някой да промени стойност на разстоянието.

След това проверете независимостта. Ако външният транспорт на VPN минава по същия безжичен път или през достъпна връзка със същия възходящ канал, резервът не е втори домейн на отказ и ще бъде спрян точно когато ви трябва. Изтеглете основния кабел на хартия: ако транспортът на тунела умира заедно с него, плаващият маршрут покрива само конфигурационни грешки, а не прекъсвания.

Спрете да искате от разстоянието да открива нещо

По-голямото разстояние прави маршрута по-малко предпочитан. Това е цялата работа. Докато основният статичен маршрут остава допустим, плаващият маршрут остава неактивен и това е правилно поведение, а не дефект. Повредата става видима само когато основният бъде оттеглен или маркиран като недостъпен.

За статичните маршрути това изисква явен тракер:

/ip route
add dst-address=10.20.0.0/24 gateway=192.0.2.1 distance=1 check-gateway=ping
add dst-address=10.20.0.0/24 gateway=wg-backup distance=10

Прочетете какво тества това: следващия хоп, а не дестинацията. Радио, което все още отговаря от своята страна, но е счупено при препращане нататък, поддържа основния маршрут активен. Това е тихият случай и разстоянието плюс проверка на шлюза няма да го хванат. Ако този случай е важен, откриването трябва да идва от нещо, което наблюдава далечната страна: съседство на маршрутизиращ протокол или сонда, чийто път и правило за резултат сте дефинирали сами.

Проследете накъде отиват собствените пакети на сондата

Сондата за здраве също има маршрут. Щом трафикът на данни се премести към VPN, неограничена сонда към същия отдалечен адрес може да го последва, да успее и да бъде прочетена като доказателство, че основният се е възстановил. Трафикът се връща по счупен път и цикълът се повтаря.

Закответе сондата към пътя, който трябва да съди. В RouterOS обичайният начин е маршрут до хост към целта за мониторинг през основния шлюз, с обхват, достатъчно малък, че никой друг маршрут да не може да го резолвира, което е точно това, което изгражда примерът за рекурсивно превключване в ръководството на RouterOS. Потвърдете го в живата таблица с активен резерв, а не от коментара в конфигурацията:

/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop

Определете какво означава резултатът от сондата, преди да добавяте цели

Една цел, която отхвърля ICMP или влиза в поддръжка, изглежда точно като отказ на пътя, а три цели без правило ви дават просто три мнения. Решете правилото първо, после го приложете: например основният се брои за спрян, когато две от три цели се провалят за два последователни интервала, записано в наръчника, където следващият човек ще го намери.

Задайте прагове за отказ и възстановяване, така че един загубен пакет да не мести обекта. Хистерезисът струва малко време за откриване и връща стабилност. Изберете интервала от това колко дълго е допустимо прекъсване, а не от това колко бързо може да работи сондата, и дръжте връщането по-бавно от превключването, за да трябва основният да се докаже, преди да получи трафик обратно.

Проверете обратния път и историята на сесиите

Превключване, което работи само навън, е половината от проекта. Отдалеченият обект се нуждае от маршрут обратно към вашия диапазон на източника през VPN, иначе обратният трафик пристига от неочакван адрес и попада на състояние на защитната стена, което вече не съвпада. Съществуващите сесии ще се счупят дори когато новите връзки работят, затова сложете това в критериите за приемане, вместо да обещавате запазване на трансфера.

Дръжте административния достъп извън тествания път. Ако единственият ви вход е през основния, тест за превключване ще ви заключи извън устройството, което се държи неправилно.

Изпълнете последователността за приемане

Три теста покриват по-голямата част: физическа загуба на основния, тих отказ при препращане с все още вдигнат интерфейс и възстановяване на основния. За всеки запишете източника и следващия хоп на сондата, активния маршрут до дестинацията и свеж разрешен обмен на приложение в двете посоки.

Тихият случай е този, който разделя проектите. Ако резервът не поеме там, сте изградили монитор на връзката, а не монитор на пътя. Решете дали това е приемливо и запишете ограничението там, където дежурният инженер ще го прочете. Втори свързан тунел сам по себе си не е завършена резервна политика.

Подобни статии