Mover OpenVPN de TAP a TUN: un orden de migración que funciona

Cambiar dev tap por dev tun cambia lo que transporta el túnel, no solo cómo se llama. Una interfaz TAP entrega tramas Ethernet a un puente, así que los clientes se comportan como si estuvieran enchufados al conmutador de la oficina. Una interfaz TUN transporta paquetes IP, así que los clientes necesitan rutas y el otro extremo necesita un camino de vuelta. Los clientes, el plan de direcciones y la ruta de vuelta de la LAN tienen que moverse con ese cambio.

La migración es un rediseño de red con un túnel añadido, y el orden de abajo lo mantiene reversible.

Inventaríe qué depende realmente de Ethernet

Enumere las aplicaciones, no los hosts. Determine si cada una usa servicios TCP o UDP enrutados, descubrimiento por difusión, DHCP de la LAN de la oficina, un protocolo Ethernet que no sea IP o la suposición de que ambos extremos están en la misma subred. El acceso IP corriente sobrevive a un diseño enrutado. Un protocolo que necesita tramas Ethernet en bruto no, y ninguna cantidad de enrutamiento lo hará funcionar. Las aplicaciones que dependen del descubrimiento necesitan un mecanismo de reemplazo decidido antes del cambio, no durante.

Ese inventario es también la lista de aceptación. Cada entrada que no pueda migrar se convierte en una excepción documentada o en una razón para mantener vivo un segmento TAP pequeño solo para esa carga.

Construya el plan de direcciones y rutas de vuelta

Elija un prefijo de clientes que no se solape con la LAN, el rango antiguo del puente ni ninguna red a la que un cliente ya llegue.dev tun, topology subnet y server 10.78.0.0 255.255.255.0, pero eso es un fragmento, no un perfil que funcione. Mantenga alrededor la política aprobada de TLS, identidad, transporte y acceso, y use un prefijo que haya verificado como libre.

Después anote los destinos a los que deben llegar los clientes y quién proporciona el camino de vuelta. El servidor necesita el reenvío activado y un camino permitido hacia delante. Los enrutadores de la LAN necesitan una ruta de vuelta al prefijo nuevo, o el diseño necesita traducción de origen con el coste de visibilidad que eso implica. Una ruta enviada a la configuración del cliente configura al cliente, no el camino de respuesta de la LAN.

Pruebe en un escucha separado

Levante el servicio nuevo junto al viejo, en su propio puerto y su propio rango de direcciones, en lugar de sustituir el único punto de entrada que funciona. Emita perfiles de prueba por el proceso de inscripción existente para que nadie rehaga la CA por una migración. Conecte un cliente representativo con solo el camino de prueba activo y luego compare las direcciones asignadas, el DNS privado, las aplicaciones del inventario y los caminos que deben seguir bloqueados.

Incluya una prueba de reconexión y de tráfico de vuelta. Un apretón de manos que se completa no dice nada sobre si el otro extremo puede responder.

Mueva clientes en grupos con reversión

Migre en grupos lo bastante pequeños como para que un fallo sea una tarea de soporte y no una caída. Mantenga el servicio viejo en marcha y documentado hasta que pasen los flujos de trabajo reales de cada grupo, y escriba la reversión como un cambio al perfil anterior y no como una reconstrucción. Actualice las reglas de cortafuegos basadas en direcciones, la monitorización y cualquier acceso iniciado por el servidor para el prefijo nuevo a medida que cada grupo se mueve.

Los grupos también le dan un lugar donde descubrir la aplicación que nadie mencionó, mientras el camino viejo todavía existe para comparar.

Retire el puente solo después de la aceptación

Quitar el dispositivo TAP es el último paso, no el primero. Compruebe si el puente todavía lleva la dirección de gestión del servidor, un camino de monitorización o una carga no relacionada antes de borrar nada. Retire las dependencias de arranque, la pertenencia al puente y las reservas DHCP a través de sus propietarios, en ese orden, con una nota de lo que se ha eliminado.

La migración termina cuando el modelo de acceso enrutado funciona para el inventario, no cuando una interfaz TAP desaparece de la salida de ip link.