Mover o OpenVPN de TAP para TUN: uma ordem de migração que funciona

Trocar dev tap por dev tun muda o que o túnel transporta, e não apenas o seu nome. Uma interface TAP entrega quadros Ethernet a uma bridge, por isso os clientes comportam-se como se estivessem ligados ao switch do escritório. Uma interface TUN transporta pacotes IP, por isso os clientes precisam de rotas e o lado remoto precisa de um caminho de volta. Os clientes, o plano de endereços e a rota de retorno da LAN têm todos de mudar com essa alteração.

A migração é um redesenho da rede com um túnel acoplado, e a ordem abaixo mantém-na reversível.

Inventarie o que depende realmente de Ethernet

Liste as aplicações, não os servidores. Determine se cada uma usa serviços TCP ou UDP encaminhados, descoberta por broadcast, DHCP da LAN do escritório, um protocolo Ethernet que não seja IP, ou a suposição de que ambos os extremos estão na mesma sub-rede. O acesso IP comum sobrevive a um desenho encaminhado. Um protocolo que exige quadros Ethernet em bruto não sobrevive, e nenhuma quantidade de encaminhamento o fará funcionar. As aplicações dependentes de descoberta precisam de um mecanismo de substituição decidido antes da transição, e não durante.

Esse inventário é também a lista de aceitação. Cada entrada que não conseguir migrar torna-se uma exceção documentada ou uma razão para manter um pequeno segmento TAP vivo apenas para essa carga de trabalho.

Construa o plano de endereços e rotas de retorno

Escolha um prefixo de clientes que não se sobreponha à LAN, ao antigo intervalo da bridge ou a qualquer rede que um cliente já alcance. Um servidor com topologia de sub-rede precisa de um fragmento como dev tun, topology subnet e server 10.78.0.0 255.255.255.0, mas isso é um fragmento e não um perfil funcional. Mantenha à volta dele a política aprovada de TLS, identidade, transporte e acesso, e use um prefixo que tenha verificado estar livre.

Depois anote os destinos que os clientes têm de alcançar e quem fornece o caminho de retorno. O servidor precisa de encaminhamento ativo e de um caminho permitido para a frente. Os routers da LAN precisam de uma rota de volta para o novo prefixo, ou o desenho precisa de tradução de origem com o custo de visibilidade que isso implica. Uma rota enviada ao cliente configura o cliente, não o caminho de resposta da LAN.

Teste num listener separado

Ponha o novo serviço ao lado do antigo, no seu próprio porto e no seu próprio intervalo de endereços, em vez de substituir o único ponto de entrada que funciona. Emita perfis piloto através do processo de inscrição existente para que ninguém reconstrua a CA por causa de uma migração. Ligue um cliente representativo com apenas o caminho piloto ativo e depois compare os endereços atribuídos, o DNS privado, as aplicações do inventário e os caminhos que devem continuar bloqueados.

Inclua um teste de reconexão e de tráfego de retorno. Um handshake que termina não diz nada sobre se o lado remoto consegue responder.

Mova os clientes em grupos com rollback

Migre em grupos suficientemente pequenos para que uma falha seja uma tarefa de suporte e não uma paragem. Mantenha o serviço antigo a funcionar e documentado até os fluxos de trabalho reais de cada grupo passarem, e escreva o rollback como um regresso ao perfil anterior e não como uma reconstrução. Atualize as regras de firewall baseadas em endereços, a monitorização e qualquer acesso iniciado pelo servidor para o novo prefixo à medida que cada grupo avança.

Os grupos também lhe dão um lugar para descobrir a aplicação de que ninguém falou, enquanto o caminho antigo ainda existe para comparação.

Retire a bridge só depois da aceitação

Remover o dispositivo TAP é o último passo, não o primeiro. Verifique se a bridge ainda transporta o endereço de gestão do servidor, um caminho de monitorização ou uma carga de trabalho não relacionada antes de apagar seja o que for. Retire as dependências de arranque, a pertença à bridge e as reservas DHCP através dos respetivos donos, nessa ordem, com uma nota do que foi removido.

A migração está concluída quando o modelo de acesso encaminhado funciona para o inventário, e não quando uma interface TAP desaparece da saída de ip link.