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

Замяната на dev tap с dev tun променя какво носи тунелът, не само името му. Интерфейсът TAP предава Ethernet кадри към мост, така че клиентите се държат все едно са включени в офисния комутатор. Интерфейсът TUN носи IP пакети, затова на клиентите са нужни маршрути, а на отсрещната страна — път обратно. Клиентите, адресният план и обратният маршрут на локалната мрежа трябва да се преместят с тази промяна.

Миграцията е препроектиране на мрежата с прикачен тунел и редът по-долу я запазва обратима.

Направете опис на това, което наистина зависи от Ethernet

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

Този опис е и списъкът за приемане. Всеки запис, който не можете да мигрирате, става документирано изключение или причина да запазите малък TAP сегмент жив само за тази нагрузка.

Изградете план за адресите и обратните маршрути

Изберете клиентски префикс, който не се застъпва с локалната мрежа, стария диапазон на моста или мрежа, до която клиент вече достига.dev tun, topology subnet и server 10.78.0.0 255.255.255.0, но това е фрагмент, а не работещ профил. Запазете около него одобрената политика за TLS, идентичност, транспорт и достъп и използвайте префикс, който сте проверили като свободен.

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

Пилот на отделен слушател

Вдигнете новата услуга до старата на собствен порт и собствен диапазон от адреси, вместо да заменяте единствената работеща входна точка. Издавайте пилотни профили през съществуващия процес на записване, за да не пресъздава никой CA заради миграция. Свържете един представителен клиент само с активен пилотен път, после сравнете зададените адреси, частния DNS, приложенията от описа и пътищата, които трябва да останат блокирани.

Включете тест за повторно свързване и за обратен трафик. Завършено ръкостискане не казва нищо за това дали отсрещната страна може да отговори.

Местете клиентите на групи с план за връщане

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

Групите дават и място да откриете приложението, което никой не спомена, докато старият път още съществува за сравнение.

Оттеглете моста само след приемане

Премахването на устройството TAP е последната стъпка, не първата. Проверете дали мостът още носи адреса за управление на сървъра, път за мониторинг или несвързана нагрузка, преди да изтриете каквото и да е. Оттеглете зависимостите при стартиране, членството в моста и DHCP резервациите чрез собствениците им, в този ред, със бележка какво е премахнато.

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