Статичні маршрути чи протокол маршрутизації через VPN між майданчиками?

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

Три умови вирішують

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

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

Третя готовність до другого рівня керування. Протокол маршрутизації додає сесії, автентифікацію, фільтри й політику вибору, і кожне з цього потребує моніторингу та процесу змін. Це постійні експлуатаційні витрати, а не разове завдання з налаштування.

Таблиця під третім абзацом це коротка версія, а три розділи після неї пояснюють, чому кожен рядок стоїть там, де стоїть. Прочитайте рядки проти своєї кількості майданчиків перед вибором, бо рішення, яке ігнорує експлуатаційні витрати, це лише половина рішення.

Скільки насправді коштує статична маршрутизація

Статичний маршрут має бути правильним з обох боків тунелю. Додавання підмережі означає правку віддаленого шлюзу, локального шлюзу й зазвичай зворотного шляху, а забути будь-який із них означає однобічну відмову, яка виглядає як помилка застосунку. Команда застосунку бачить тайм-аути, а команда мережі бачить маршрут, який існує й виглядає здоровим. Жодна з команд не помиляється, і саме тому цю відмову так довго вдається локалізувати.

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

Запишіть метод відстеження поруч із кожним маршрутом, позначте, які відмови він покриває, і тримайте список разом із конфігурацією тунелю. Інакше наступний збій виявить користувач, а не мережа, і це завжди дорожче виявлення.

Скільки насправді коштує динамічна маршрутизація

Протокол оголошує нові префікси, відкликає недосяжні й висловлює перевагу між шляхами. Це справді корисно, коли кільком майданчикам або резервним тунелям інакше знадобилися б узгоджені правки за кожної зміни. Це також причина, чому протокол може здивувати вас у найгірший момент. Кожна з цих дій це зміна стану, якої ви особисто не робили.

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

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

Керуйте тим, що сесія маршрутизації може говорити

Визначте дозволений список префіксів для кожного партнера й застосовуйте його на вході, бо вихідний фільтр не може завадити партнеру надіслати вам маршрут за замовчуванням. Маршрути за замовчуванням і агрегати це дорогі помилки саме тут: вони можуть тихо замінити незв'язані шляхи одним вивченим записом, який виглядає законним. Відхиляйте їх явно, якщо проєкт справді їх не хоче.

Запишіть майданчик-власника поруч із кожною мережею до підняття першої сесії, бо це зіставлення є джерелом списку фільтрів, а не прикрасою документації. Без нього той, хто править фільтр, мусить угадувати, який майданчик має оголошувати префікс.

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

Тунельні інтерфейси на основі маршрутів спрощують подання динамічної маршрутизації, бо тунель стає інтерфейсом із маршрутами замість політики, що зіставляє селектори. Це не знімає питання про область партнера: селектори IPsec усе ще мають дозволяти трафік, який ви збираєтеся маршрутизувати.

Перевіряйте шлях відмови, а не щасливий шлях

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

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

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