Премештање OpenVPN-а са TAP на TUN: редослед миграције који функционише

Замена dev tap са dev tun мења шта тунел преноси, не само како се зове. TAP интерфејс предаје Ethernet оквире мосту, па се клијенти понашају као да су прикључени на канцеларијски свич. TUN интерфејс преноси IP пакете, па клијентима требају руте, а другој страни треба пут назад. Клијенти, план адреса и повратна рута LAN-а морају се преселити заједно с том променом.

Миграција је редизајн мреже са придруженим тунелом, а редослед испод чини је реверзибилном.

Попишите шта заиста зависи од Ethernet-а

Наведите апликације, не хостове. Утврдите да ли свака користи рутиране TCP или UDP услуге, откривање путем broadcast-а, 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, апликације са пописа и путеве који треба да остану блокирани.

Укључите тест поновног повезивања и повратног саобраћаја. Руковање које се заврши ништа не говори о томе може ли друга страна да одговори.

Премештајте клијенте у групама с враћањем

Мигрирајте у групама довољно малим да квар буде задатак подршке, а не прекид. Држите стару услугу у раду и документовану док стварни радни токови сваке групе не прођу, а враћање запишите као прелазак на претходни профил, а не као поновну изградњу. Како се свака група премешта, ажурирајте правила firewall-а заснована на адресама, надзор и сваки приступ који иницира сервер за нови префикс.

Групе вам дају и место да откријете апликацију коју нико није споменуо, док стари пут још постоји за поређење.

Повуците мост тек после прихватања

Уклањање TAP уређаја је последњи корак, а не први. Проверите да ли мост још преноси адресу управљања сервера, пут надзора или неповезано радно оптерећење пре него што било шта обришете. Повуците зависности покретања, чланство у мосту и DHCP резервације кроз њихове власнике, тим редом, с напоменом шта је уклоњено.

Миграција је завршена када рутирани модел приступа ради за попис, а не када TAP интерфејс нестане из излаза ip link.