Перемикання VPN: коли зворотний шлях залишається в старому тунелі

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

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

Запишіть маршрути обох майданчиків до тесту

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

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

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

Спостерігайте запити й відповіді на кожній фазі

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

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

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

Керуйте станом сесії, коли змінюється шлюз

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

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

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

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

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

Тримайте адміністрування шлюзу доступним через шлях відновлення, щоб сам тест не замкнув вас зовні. Записуйте фази, спостережувані шляхи й час відновлення; саме цей запис робить наступне перемикання передбачуваним. Нотатки strongSwan про пересилання корисні, коли кінцеві точки — хости Linux.