Смена провайдера без перенумерации адресов VPN площадки

Филиал меняет интернет-провайдера, а файловый сервер сохраняет свой адрес. Такой результат обычен для маршрутизируемого 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

Держите транспортные адреса в одном реестре, а адреса приложений в другом. Обновляйте только те записи, которые действительно переместились. Перенумерация внутренних зависимостей из-за смены внешнего адреса туннеля — работа, которой можно избежать.