Плаваючий резервний маршрут 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, інакше зворотний трафік приходить із неочікуваної адреси й натрапляє на стан міжмережевого екрана, що більше не збігається. Наявні сеанси обірвуться навіть коли нові з'єднання працюють, тому внесіть це до критеріїв приймання замість обіцянки збереження передавання.

Тримайте адміністративний доступ поза тестованим шляхом. Якщо єдиний вхід у вас через основний маршрут, тест перемикання замкне вас зовні пристрою, що поводиться неправильно.

Виконайте послідовність приймання

Три тести покривають більшу частину: фізична втрата основного маршруту, тиха відмова пересилання з іще піднятим інтерфейсом і відновлення основного маршруту. Для кожного зафіксуйте джерело й наступний стрибок зонда, активний маршрут призначення та свіжий дозволений обмін застосунку в обидва боки.

Тихий випадок — той, що розділяє проєкти. Якщо резерв там не перехоплює, ви побудували монітор каналу, а не монітор шляху. Вирішіть, чи це прийнятно, і запишіть обмеження там, де черговий інженер його прочитає. Другий під'єднаний тунель сам по собі не є завершеною резервною політикою.