Преместување на 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.