Exceção do UFW para a VPN quando o endereço do endpoint muda

O cliente tenta reconectar-se e nada sai da máquina, embora o mesmo perfil funcionasse na semana passada. O nome do host do endpoint agora resolve para um endereço diferente, e a exceção de saída ainda nomeia o antigo. Essa única permissão obsoleta basta para transformar um kill switch funcional numa queda total, e é invisível em todos os indicadores de estado que o ambiente de trabalho mostra. A reparação é um pequeno fluxo de trabalho, não uma edição de uma linha.

O túnel reconecta-se e depois não sai nada

Uma regra de saída que nomeia um endereço de destino é uma fotografia instantânea, e as respostas DNS não o são. Quando o fornecedor roda um endereço, o pacote que o cliente envia para o novo par não corresponde a nada e é descartado pela negação predefinida. O cliente reporta então um tempo limite, que soa a problema do servidor e não do firewall.

Fixar o endereço que uma consulta pública devolve faz funcionar hoje e deixa amanhã quebrado. Isso é uma edição pontual, não uma política de manutenção.

Descreva a exceção que realmente pretende

Comece por anotar os quatro valores de que a regra precisa: o nome ou conjunto de endereços do endpoint aprovado, o transporte, a porta de destino e a interface por onde o pacote sai. Todos os quatro fazem parte da permissão, e qualquer um deles pode estar errado enquanto a regra ainda parece plausível. Uma regra correta em três deles falha exatamente como uma regra errada nos quatro. Anote-os antes de escrever o comando, porque uma regra vale apenas o que vale a descrição por trás dela.

O comando abaixo mostra a forma para um endpoint IPv4 UDP numa ligação por cabo. Substitua ambos os valores pelos que verificou contra a implementação.

sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose

Essa permissão não autoriza destinos arbitrários na mesma porta, não cria um ouvinte e não cobre TCP. A página de manual do UFW descreve como o endereço, a interface e o protocolo restringem uma regra, e essa restrição é o ponto principal.

Atualize-a como um único fluxo de trabalho

Trate a exceção como um recurso com um dono e uma transição, não como um comando de que alguém se lembra. Primeiro obtenha um candidato do resolver e do inventário de endpoints da própria implementação, e defina deliberadamente como esse nome é resolvido antes de o túnel existir. Depois valide o candidato contra o protocolo, a porta e a família de endereços pretendidos antes de tocar no conjunto de regras.

Instale primeiro a nova permissão estreita e confirme que foi carregada, porque pedir ao cliente que use um endereço que o firewall ainda bloqueia produz uma falha que parece um erro do servidor. Mantenha as regras não relacionadas intactas durante a mudança.

Observe a transição do cliente pelo seu caminho de reconexão suportado e confirme que endereço remoto escolheu. Atualizar apenas o DNS não move um socket existente, e uma definição de persistência do endpoint pode manter o cliente no par antigo muito depois de o registo mudar.

Por fim, retire a permissão obsoleta de propósito, permitindo a janela de sobreposição aprovada enquanto uma sessão antiga ainda está ativa. Remover a entrada antiga demasiado cedo produz uma breve queda; deixá-la para sempre deixa uma permissão que ninguém sabe explicar.

Retire a permissão antiga de propósito

A remoção é onde está a maior parte do risco, porque a regra antiga é a única coisa que funciona neste momento. Se a instalação do candidato falhou, não continue nem apague a entrada que ainda transporta tráfego. Se a própria remoção falhar, registe a permissão obsoleta como obsoleta em vez de declarar a política atual.

Repita toda a revisão quando a ligação passar de Ethernet para Wi-Fi, quando o transporte mudar ou quando um serviço rodar entre vários endereços. Supõe-se que uma regra específica de interface deixa de corresponder após uma mudança de rede, e esse comportamento está correto mesmo que pareça uma regressão.

Prove o contrato depois com tráfego inofensivo. O endpoint aprovado tem de ser alcançável durante a configuração, a aplicação protegida tem de funcionar depois de ligada, e o tráfego direto não relacionado tem de permanecer bloqueado durante uma queda. Inclua as duas famílias de endereços e uma tentativa de atualização falhada de propósito, porque uma ligação que tem sucesso após uma única edição de endereço fixado não prova nenhum desses casos.