A saída IPv6 morre após reiniciar o OpenVPN: verifique a propriedade do prefixo
O IPv6 morre depois que o túnel é recriado. Decida quem é dono do prefixo delegado, dos endereços dos clientes e da rota de retorno antes de reiniciar qualquer coisa.
O IPv6 deixa de passar tráfego no momento em que o OpenVPN reinicia, e o IPv4 continua funcionando. A interface do túnel foi recriada, e algo mais que gerenciava o estado IPv6 dela perdeu o endereço ou perdeu a rota que torna o prefixo alcançável. Há três peças de estado separadas e cada uma tem um dono diferente: o prefixo delegado do provedor e sua vida útil, os endereços entregues aos clientes VPN e a rota ascendente que devolve esse prefixo de cliente ao servidor. Identifique o dono de cada peça antes de tocar em qualquer daemon, porque reiniciar o errado esconde o problema por um dia e o traz de volta na próxima reconexão.
Três peças de estado IPv6, três donos
| State | Typical owner | What breaks when it is wrong |
|---|---|---|
| Delegated prefix and lifetime | Upstream router or provider via DHCPv6-PD | Clients keep addresses that the upstream no longer routes |
| Client addresses inside the tunnel | OpenVPN server config or a delegation daemon | No global address, or an address outside the routed prefix |
| Return route for the client prefix | Upstream router, or the server's own routing table | Outbound works, replies never arrive |
Um endereço com escopo global dentro do túnel não basta sozinho. Os roteadores acima ainda precisam enviar esse prefixo de volta ao servidor VPN, e não o farão só porque o servidor tem por acaso um endereço dele.
Por isso também é arriscado copiar um /64 público para um pool de túnel. Um prefixo roteado para o servidor não é o mesmo que um prefixo que o lado acima trata como on-link, e a descoberta de vizinhos não preenche essa lacuna.
Leia o estado do servidor antes de mudar qualquer coisa
Capture o estado duas vezes, uma enquanto o IPv6 funciona e outra depois do reinício, e então compare. As visões somente leitura bastam e não custam nada durante uma janela de manutenção:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingProcure três diferenças específicas: uma rota que desapareceu, um endereço que passou para uma vida útil obsoleta ou inválida, e um prefixo que mudou após uma redelegação enquanto a configuração VPN ainda anuncia o antigo.
Se o endereço sumiu mas o prefixo não mudou, o daemon que o atribui parou de gerenciar a interface. Se o prefixo mudou mas os endereços não, a configuração do cliente está obsoleta. As duas falhas parecem idênticas num navegador e não têm nada em comum.
Decida se o dhcpcd deve gerenciar o túnel
O dhcpcd pode descobrir interfaces e delegar partes de um prefixo DHCPv6 a interfaces abaixo, e sua configuração pode nomear explicitamente os destinos da delegação. Sem um destino explícito, o comportamento documentado pode envolver outras interfaces, e é assim que um túnel acaba com um endereço que ninguém planejou.
Duas condições devem empurrá-lo para deixar o OpenVPN dono do endereçamento estático do túnel: o servidor empurra endereços fixos na configuração, e o nome do túnel muda na reconexão. Se ambas valem, exclua o túnel do daemon de delegação de propósito, com um comentário que diga por quê.
Se, em vez disso, a delegação para o túnel é deliberada, implemente o tratamento da mudança de prefixo. Isso significa reagir quando o prefixo delegado ou sua vida útil mudam, atualizar o prefixo de cliente anunciado pelo servidor e readicionar a rota. Excluir a interface nesse desenho remove o único componente que conhece o novo prefixo.
Reiniciar o dhcpcd pode parecer que conserta as coisas porque recria estado, mas também renova ou retira configuração de interfaces nas quais você não estava pensando. Essa recuperação não o torna um requisito após cada reinício de VPN. Também zera os contadores que você usava como prova. Prefira uma recarga direcionada da interface que você realmente alterou.
Valide o IPv6 separadamente do NAT IPv4
Confirme que o encaminhamento está ativo e que a rota acima aponta para o prefixo de cliente real, e então faça uma nova conexão IPv6 permitida. Verifique também a tabela de rotas IPv6 do próprio cliente, porque um cliente mostrando um endereço público não prova que sua requisição usou o túnel.
O mascaramento IPv4 resolve outro problema: o caminho de retorno para fontes privadas. Não faz nada por um prefixo IPv6 retirado, e adicioná-lo não trará o IPv6 de volta.
Encerre com o registro de propriedade: qual componente delega o prefixo, qual atribui os endereços dos clientes, qual mantém a rota de retorno, e o que acontece com cada um na reconexão. Quatro linhas num runbook poupam a próxima pessoa de reiniciar três daemons para achar o que importava.