Что миграция на VPN должна сохранить от выделенной линии

Выделенные линии легко описать и трудно заменить, потому что контракт охватывал больше, чем кабель. Она несла передачу, план адресов, ожидание задержки и соглашение о поддержке, и туннель, который её заменяет, наследует все четыре, записал их кто-то или нет. Миграции проваливаются, когда команда копирует конфигурацию маршрутизации и называет остальное эксплуатационной проблемой. Начните с требований, затем докажите каждое на новом пути до отключения старого.

Превратите линию в список свойств

Первый вопрос — что старая услуга действительно передала: маршрутизируемый канал с небольшой подсетью или сегмент уровня 2, общий для площадок. Это различие решает, сможет ли IP-туннель вообще его воспроизвести, потому что туннель переносит пакеты между двумя адресами и не переносит обнаружение через широковещание или произвольные EtherTypes. Линия, которая представлялась портом коммутатора, — это другая миграция, чем линия с /30.

Запишите префиксы площадок, адреса шлюзов, приложения, которые встраивают адреса в собственную конфигурацию, и префиксы, которые где-то ещё в среде пересекаются. План адресов, переживающий миграцию, — это результат проектирования, а не допущение. Эти четыре списка позже станут и критериями приёмки, поэтому держите их там, где тестировщики смогут их прочитать.

Направьте новый путь в обе стороны

Поднятый туннель — это только половина пути. Удалённой стороне нужен маршрут обратно к каждому локальному префиксу, а локальная сторона должна предпочитать туннель для этих префиксов, не похищая трафик, который всё ещё должен уходить через интернет. Асимметричная пересылка — обычный симптом того, что одна из этих половин сделана правильно. Проверьте таблицу удалённой стороны так же тщательно, как свою, потому что обратный путь — это тот, который никто не настроил.

ip route get 10.20.0.10

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

Переключитесь с откатом, который вы уже проверили

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

Заранее решите, какие доказательства разрешают переключение и какое условие запускает откат. Откат, требующий починить новый VPN через отказавшее соединение, — это не откат. Сформулируйте триггер как измеримое условие, а не как ощущение в комнате.

Примите с тем трафиком, который линия действительно несла

Ping доказывает доступность и мало что ещё. Проверьте разрешение имён, длительные сессии, отклонённые потоки и размеры пакетов, которые старый путь обрабатывал без фрагментации. MTU — это место, где туннели чаще всего отличаются от линии, потому что инкапсуляция расходует байты, которые приложение считало доступными. Измерьте наибольшую полезную нагрузку, проходящую без фрагментации в обе стороны, а не только к серверу.

ping -M do -s 1400 -c 3 10.20.0.10

Если нагрузка в 1400 байт проходит, а 1472 нет, максимум пути меньше, чем ожидают приложения, и вы нашли настоящую регрессию, а не косметическую. Сравните результат с требованиями, записанными на первом шаге, и выведите линию из эксплуатации только когда владельцы этих приложений примут измерение. Именно эта подпись превращает успешный тест в принятую миграцию.