O interruptor de emergência do UFW bloqueia sua VPN? Permita o par

Você seguiu a lista de verificação: negar a saída, permitir o túnel, ativar o ufw. Então o cliente espera no handshake e nunca conecta, ou conecta e nenhuma página carrega. As duas falhas vêm do mesmo buraco. Falta a regra que deixa o túnel existir, porque o túnel não é uma interface por onde seus pacotes saem.

Por que uma permissão em tun0 não corresponde a nada no início

tun0 é criado pelo cliente depois que existe uma sessão. Os datagramas que constroem essa sessão são pacotes UDP comuns endereçados ao provedor na porta 1194, e saem por wlan0 ou eth0 com o endereço de origem físico. allow out on tun0 só corresponde ao tráfego cuja interface de saída é tun0, então durante o handshake não corresponde a nada.

Coloque default deny outgoing por cima e os pacotes externos são descartados antes mesmo que a interface apareça. O cliente tenta de novo, esgota o tempo e relata uma falha de TLS ou de handshake, o que manda as pessoas vasculharem certificados e MTU enquanto o firewall come a conexão em silêncio. A regra que deveria conter seu tráfego impede que esse tráfego seja contido.

A correção reflexa torna o vazamento permanente. sudo ufw allow out on wlan0, ou voltar o padrão para permitir, levanta o túnel e deixa a máquina sem interruptor de emergência: na próxima vez que o túnel cair, tudo recomeça pelo adaptador físico. Perdi uma tarde exatamente nesse par de edições antes de descobrir qual pacote eu estava realmente filtrando.

Do que os dois conjuntos de pacotes precisam

Seu tráfego cruza o firewall duas vezes, em duas formas. O pacote interno sai do endereço do túnel para fora por tun0. O pacote externo vai do endereço físico ao par, e é a única coisa visível no fio. Uma regra por forma:

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

Substitua o endereço e a porta pelos do seu próprio perfil. Os pares do WireGuard costumam responder em 51820/udp; perfis do OpenVPN que passam por TCP 443 precisam dessa porta em vez disso. Os detalhes mudam, a forma não: as duas regras são estreitas e juntas definem os únicos destinos que a máquina alcança enquanto o túnel está fora do ar.

A ordem é o segundo mito. Com iptables cru você lê a cadeia de cima para baixo e raciocina sobre qual regra vence. O ufw não é um invólucro fino da lista que você digitou; ele compila suas regras em cadeias próprias e escolhe os pontos de inserção. ufw status as imprime na ordem do ufw, não na sua. Quando uma regra parece ignorada, compare ufw show added com o conjunto compilado de iptables -S | grep ufw antes de reescrever qualquer coisa.

A exceção precisa continuar larga de um único endereço

Uma regra de par só está correta enquanto nomeia o endereço que o cliente disca. Os provedores rodam endpoints, e um perfil que resolve um nome de host vai seguir a mudança de DNS para um endereço novo enquanto a regra continua apontando para o antigo. Quando um túnel que funcionava há meses deixa de subir, compare o endereço da regra com o que o cliente procura antes de ampliar qualquer coisa.

Ampliar para uma sub-rede inteira, ou para cada destino na porta 1194, transforma a política de volta num firewall com um buraco. A exceção é o interruptor de emergência; uma vez que é amplo, não sobra nada para desligar. Mantenha-o em um único endereço e deixe um comentário nomeando o perfil e o provedor a que pertence, porque em seis meses o endereço vai parecer arbitrário.

A resolução de nomes merece a própria linha. A consulta acontece antes de o túnel existir, pela interface física, então uma política rígida de negação de saída pode deixar o cliente incapaz de achar o próprio servidor. Permita a porta 53 para o endereço do seu resolvedor, ou resolva uma vez e fixe o endereço no perfil. Permitir DNS em todas as interfaces é uma decisão, não um padrão.

Construa a política antes de o túnel ser necessário

ufw enable aplica a política inteira de uma vez e recarrega suas cadeias, e mudar uma política padrão num firewall em execução também as recarrega. O manual do ufw avisa que isso pode derrubar conexões existentes como SSH. Por isso os comandos vão nesta ordem, com a regra de SSH antes da ativação e uma sessão de console aberta:

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

ufw reset é deixado fora desse bloco de propósito. Ele apaga todas as regras e desativa o firewall, e num host remoto a ativação seguinte é o que derruba sua sessão. Se você fizer o reset mesmo assim, acrescente a regra de SSH e confirme um segundo caminho de volta por console antes de continuar.

A sequência não é cosmética. Regras adicionadas enquanto o ufw roda não esvaziam nada, mas no momento em que você vira uma política padrão as cadeias recarregam, e uma sessão que a política antiga permitia vai junto. Faça os padrões, as permissões e a ativação numa só passada, enquanto ainda tem um caminho para dentro que não depende da máquina.

Teste o estado bloqueado e guarde o desfazimento

Um interruptor de emergência não testado é um palpite. Desconecte o cliente de propósito e tente carregar uma página: tem de falhar. Reconecte e ele tem de se recuperar sem tocar em regra alguma. sudo ufw status verbose confirma os padrões e o estado do registro, e ufw status numbered mostra qual regra de teste apagar quando ela sobrevive ao propósito.

Guarde o script inverso ao lado do direto. Uma máquina com negação de saída e um túnel morto não consegue baixar o próprio conserto, então o desfazimento tem de estar no disco e ser legível a partir de um console:

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Execute-o quando o túnel já está fora do ar e as regras precisam sair, não como passo de rotina. Antes de fechar o terminal, quatro coisas devem valer: a regra do par nomeia exatamente um endereço, o DNS tem uma exceção nomeada, a ativação veio depois das permissões, e puxar o túnel mata o tráfego comum sem matar o cliente de vez.