Mover OpenVPN de TAP a TUN: unha orde de migración que funciona

Cambiar dev tap por dev tun cambia o que leva o túnel, non só como se chama. Unha interface TAP entrega tramas Ethernet a unha ponte, así que os clientes compórtanse coma se estivesen conectados ao conmutador da oficina. Unha interface TUN leva paquetes IP, así que os clientes necesitan rutas e o outro extremo necesita un camiño de volta. Os clientes, o plan de enderezos e a ruta de volta da LAN teñen que moverse con ese cambio.

A migración é un rediseño da rede cun túnel engadido, e a orde de abaixo mantena reversible.

Inventarie o que depende realmente de Ethernet

Enumere as aplicacións, non os servidores. Determine se cada unha usa servizos TCP ou UDP encamiñados, descubrimento por difusión, DHCP da LAN da oficina, un protocolo Ethernet que non sexa IP ou a suposición de que ambos os extremos están na mesma subrede. O acceso IP corrente sobrevive a un deseño encamiñado. Un protocolo que necesita tramas Ethernet en bruto non, e ningunha cantidade de encamiñamento o fará funcionar. As aplicacións que dependen do descubrimento necesitan un mecanismo de substitución decidido antes do cambio, non durante.

Ese inventario é tamén a lista de aceptación. Cada entrada que non poida migrar convértese nunha excepción documentada ou nunha razón para manter vivo un pequeno segmento TAP só para esa carga.

Construíde o plan de enderezos e rutas de volta

Escolla un prefixo de clientes que non se solape coa LAN, o rango antigo da ponte nin ningunha rede á que un cliente xa chegue.dev tun, topology subnet e server 10.78.0.0 255.255.255.0, pero iso é un fragmento, non un perfil que funcione. Manteña arredor a política aprobada de TLS, identidade, transporte e acceso, e use un prefixo que verificase como libre.

Despois anote os destinos aos que deben chegar os clientes e quen proporciona o camiño de volta. O servidor necesita o reenvío activado e un camiño permitido cara adiante. Os encamiñadores da LAN necesitan unha ruta de volta ao prefixo novo, ou o deseño necesita tradución de orixe co custo de visibilidade que iso implica. Unha ruta enviada á configuración do cliente configura o cliente, non o camiño de resposta da LAN.

Probe nun oínte separado

Levante o servizo novo xunto ao vello, no seu propio porto e o seu propio rango de enderezos, en lugar de substituír o único punto de entrada que funciona. Emita perfís de proba polo proceso de inscrición existente para que ninguén refaga a CA por unha migración. Conecte un cliente representativo con só o camiño de proba activo e despois compare os enderezos asignados, o DNS privado, as aplicacións do inventario e os camiños que deben quedar bloqueados.

Inclúa unha proba de reconexión e de tráfico de volta. Unha aperta de mans que se completa non di nada sobre se o outro extremo pode responder.

Mova clientes en grupos cunha reversión

Migre en grupos o bastante pequenos como para que un fallo sexa unha tarefa de soporte e non unha caída. Manteña o servizo vello en marcha e documentado ata que pasen os fluxos de traballo reais de cada grupo, e escriba a reversión como un cambio ao perfil anterior e non como unha reconstrución. Actualice as regras de cortafuegos baseadas en enderezos, a monitorización e calquera acceso iniciado polo servidor para o prefixo novo a medida que cada grupo se move.

Os grupos tamén lle dan un lugar onde descubrir a aplicación que ninguén mencionou, mentres o camiño vello aínda existe para comparar.

Retire a ponte só despois da aceptación

Quitar o dispositivo TAP é o último paso, non o primeiro. Comprobe se a ponte aínda leva o enderezo de xestión do servidor, un camiño de monitorización ou unha carga non relacionada antes de borrar nada. Retire as dependencias de arranque, a pertenza á ponte e as reservas DHCP a través dos seus propietarios, nesa orde, cunha nota do que se eliminou.

A migración remata cando o modelo de acceso encamiñado funciona para o inventario, non cando unha interface TAP desaparece da saída de ip link.