Перенесення однієї підмережі в новий тунель VPN без простою
Перенесіть увесь шлях однієї підмережі: маршрут, селектори, правила доступу, зворотний трафік і відкат. Спершу підніміть тунель, потім перемкніть вузько.
Підніміть новий тунель, перенесіть одну підмережу, і ця підмережа тепер періодично збоїть, хоча все інше цілком гаразд. Напівперенесені VPN збоять саме так, бо тунель ніколи не був складною частиною. Шлях охоплює також те, який маршрут перемагає, які селектори збігаються, що дозволяють правила доступу, як повертаються відповіді та будь-яке перетворення, яке застосовував старий дизайн. Перенесіть лише тунель — і ви не перенесли нічого з цього.
Тунель — легка половина шляху
Періодичні збої після часткового перенесення зазвичай означають, що обидва шляхи ймовірні. Одні потоки обирають новий тунель, інші лишаються на старому, і пристрій, що пам'ятає стан, бачить відповідь, яка надходить шляхом, якого запит ніколи не використовував. Два шляхи не безпечніші за один автоматично; це дві речі, які можуть розходитися. Дивіться звіти про коливання, а не лічильники тунелю, бо лічильники виглядатимуть здоровими весь час.
Корисне перше питання — не який тунель кращий. А які потоки сьогодні обирають який шлях і чи отримують запит і відповідь однакову відповідь.
Збудуйте пункт призначення, перш ніж надавати йому перевагу
Переконайтеся, що партнери сумісні й новий тунель несе задуманий діапазон адрес. Додайте пересилання та дозволи служб, які йому потрібні, поки він ще неприоритетний шлях, щоб саме перемикання змінювало лише вибір і нічого більше.
Запитайте віддалений майданчик, як він повертатиме трафік. Якщо відповіді все ще виходять через старий тунель, новий локальний маршрут створює асиметрію або не проходить фільтр, що пам'ятає стан. Перетворення теж входить у дизайн з тієї ж причини: змінена адреса джерела змінює й зворотний шлях.
Перемкніть вузько й знайте дорогу назад
Назвіть точну підмережу та підтримуваний платформою механізм, який надає перевагу її новому маршруту чи селектору. Визначення на основі політик не завжди поводяться як метрики маршрутів, тож прочитайте правила перекривних політик у вашій реалізації, перш ніж припускати, що перемагає точніший збіг.
Переносьте одну підмережу, а не один майданчик. Тримайте керування на шляху, якого не торкаєтеся, і запишіть відкат до того, як щось застосуєте: який маршрут чи політика повертається, хто це робить і як вони лишаються на зв'язку, доки це роблять.
Асиметрія та застарілий стан
Міжмережеві екрани й пристрої NAT пам'ятають інтерфейс, який використовував потік. Коли запит і відповідь ідуть різними тунелями, пристрій може відкинути відповідь, хоча кожен шлях працює сам по собі. Перевіряйте потоком, який відкриєте після зміни, бо встановлена сесія може годинами далі використовувати старий шлях.
Якщо спостережувана адреса джерела змістилася, знайдіть кожну політику, яка називає стару. Перенесення, що тихо змінює джерело, ламає правила, які ніхто не відніс до дизайну VPN.
Доведіть обидві відповіді, потім відкличте стару політику
Зі звичайного хоста в перенесеній підмережі дістаньтеся потрібної служби та перевірте спостережуване джерело й інтерфейс відповіді. Потім перевірте мережу, яка має лишитися на старому тунелі, бо перенесення завершене лише тоді, коли обидві відповіді правильні. Другий тест — той, який люди пропускають, і саме він ловить селектор ширший за задум.
Відкликайте застарілу політику лише тоді, коли від неї не залежить жодна залишкова підмережа, і запишіть підсумковий маршрут з його власником в описі селекторів. Завершення — це не новий тунель, що звітує про підйом, а кожна мережа, що йде своїм задуманим шляхом.