Перевод OpenVPN с TAP на TUN: порядок миграции, который работает

Замена dev tap на dev tun меняет то, что передаёт туннель, а не только его название. Интерфейс TAP передаёт кадры Ethernet мосту, поэтому клиенты ведут себя так, будто подключены к офисному коммутатору. Интерфейс TUN передаёт IP-пакеты, поэтому клиентам нужны маршруты, а удалённой стороне нужен обратный путь. Клиенты, план адресов и обратный маршрут LAN должны переехать вместе с этим изменением.

Миграция — это переделка сети с присоединённым туннелем, и приведённый ниже порядок сохраняет её обратимой.

Составьте перечень того, что действительно зависит от Ethernet

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

Этот перечень одновременно является списком приёмки. Каждая запись, которую нельзя перенести, становится документированным исключением или причиной оставить небольшой сегмент TAP только для этой нагрузки.

Постройте план адресов и обратных маршрутов

Выберите префикс клиентов, который не пересекается с LAN, старым диапазоном моста или любой сетью, до которой клиент уже дотягивается. Серверу с топологией подсети нужен фрагмент вида dev tun, topology subnet и server 10.78.0.0 255.255.255.0, но это фрагмент, а не работающий профиль. Сохраните вокруг него утверждённую политику TLS, идентификации, транспорта и доступа и используйте префикс, который вы проверили как свободный.

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

Проверьте на отдельном слушателе

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

Включите проверку переподключения и обратного трафика. Завершившееся рукопожатие ничего не говорит о том, может ли ответить удалённая сторона.

Перемещайте клиентов группами с откатом

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

Группы также дают место, где можно обнаружить приложение, о котором никто не упомянул, пока старый путь ещё существует для сравнения.

Выводите мост только после приёмки

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

Миграция завершена, когда маршрутизируемая модель доступа работает для перечня, а не когда интерфейс TAP исчезает из вывода ip link.