Переведення 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.