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

Два плани адрес, що рухаються незалежно

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

Зміна провайдера зачіпає зовнішній план. Сама по собі вона не вимагає змінювати внутрішній.

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

Зовнішній тунель несе внутрішню розмову

У тунелі шлюз-шлюз зовнішній заголовок IP адресує два шлюзи. Внутрішній заголовок і далі називає фактичні кінцеві точки застосунку. Опис шлюз-шлюз у RFC 7296 розглядає це як звичайну маршрутизацію, що доставляє трафік через кінцеві точки тунелю.

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

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

Перехід до провайдера все ще має контрольний список

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

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

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

Що не зберігається: публічне джерело й сеанси

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

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

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

Перевірте перехід чотирма перевірками

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

На шлюзі Linux ці три покривають середину цього списку:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

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

Схожі статті