Limite a regra SNAT do OpenVPN antes que ela quebre o nginx

Duas falhas chegam sempre do mesmo tipo de host. Na primeira, os clientes autenticam e depois não alcançam nada além do túnel. Na segunda, a VPN sobe e o próprio site do servidor para de responder, o que é o mais alarmante porque parece dano colateral. Num VPS baseado em contêineres, ambas costumam voltar à mesma lista curta de verificações, e a ordem importa: primeiro o dispositivo, depois a tradução, por último o escopo.

Confirme que o contêiner consegue criar um dispositivo tun

Nada mais importa se a interface do túnel não pode existir. Verifique se /dev/net/tun está presente e se a criação de um dispositivo de teste tem sucesso, porque muitos provedores desativam o tun dentro de contêineres por padrão. Nenhum trabalho de firewall compensa um dispositivo que nunca foi criado.

Se o dispositivo falta, só o host ou o provedor podem habilitá-lo. Muitas vezes um plano diferente é mais barato do que um tópico de suporte aberto que dura uma semana. Confirme isso antes de ler uma única linha do log do OpenVPN. Caso contrário, passará a noite ajustando regras que nunca verão um pacote.

Decida o que o MASQUERADE faz nesta interface

Numa máquina virtual comum, a regra de saída habitual é POSTROUTING MASQUERADE da interface principal. Num contêiner OpenVZ, o dispositivo visível costuma ser venet0, uma interface virtual gerenciada pelo host e não uma NIC roteada, e o MASQUERADE nem sempre se comporta ali como os tutoriais supõem.

A forma viável é uma tradução explícita para o endereço que os clientes já alcançam, com o encaminhamento permitido nos dois sentidos. Substituir o pool da configuração do servidor importa tanto quanto substituir o endereço. Leia cada linha antes de colá-la.

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Sem as regras de encaminhamento a tradução continua acontecendo e o kernel continua se recusando a encaminhar. Essa combinação produz o estado confuso em que os contadores da regra NAT sobem enquanto o cliente não recebe nada. As duas linhas FORWARD também precisam estar antes de qualquer regra drop ampla na mesma cadeia. A ordem faz parte da configuração, não é um detalhe de implementação.

Limite a regra a um pool e a uma interface

O segundo sintoma tem outra causa: uma regra POSTROUTING sem restrição de origem nem de saída. Uma regra assim reescreve cada pacote que deixa o host.

Os serviços que dependem da origem original passam a se comportar mal. Um servidor web atrás de um proxy local pode parar de responder, e reiniciá-lo não muda nada porque a regra ainda está no caminho. O tráfego que o host envia ao próprio endereço público também é afetado, e é por isso que a falha pode parecer um problema de DNS ou de certificado em vez de firewall. A regra quase certamente foi adicionada para corrigir o primeiro sintoma.

A solução é estreitar a correspondência ao pool do túnel e à interface de saída, e então adicionar uma regra por pool em vez de ampliar uma única regra para cobrir várias.

Torne as regras persistentes e descubra quem mais é dono delas

As regras adicionadas à mão desaparecem na reinicialização, então guarde-as com iptables-save ou gerencie-as via netfilter-persistent onde estiver instalado. Confirme que a restauração roda antes de o OpenVPN iniciar. Depois reinicie uma vez de propósito em vez de descobrir a lacuna durante um incidente.

Num host de contêineres, confirme também que o arquivo de persistência fica em armazenamento de contêiner gravável e que o provedor não substitui a filtragem na inicialização. Algumas plataformas gerenciam a política fora do contêiner, onde as regras locais são ignoradas ou conflitam com as do próprio host.

Verifique com contadores e um fluxo capturado

De um cliente conectado, verifique o endereço público que um serviço externo informa. Se coincidir com o endereço do servidor, a tradução funciona; se não, o pacote sai por outro caminho ou não sai de modo algum. Depois teste tanto um serviço hospedado no servidor quanto um na internet pública, porque seguem caminhos diferentes pelo mesmo conjunto de regras.

No servidor, leia os contadores de pacotes nas regras NAT e FORWARD com iptables -t nat -L -v -n e observe um fluxo numa captura. Se o endereço do cliente aparecer na captura e nenhuma resposta vier, a lacuna está no caminho de volta ou na filtragem do provedor, não no perfil do cliente. Compare a origem capturada com o endereço para o qual a regra traduz, porque uma divergência significa que outra regra correspondeu primeiro. Um único fluxo observado resolve mais do que uma página de leitura de configuração.

Mantenha o pool, o endereço traduzido e o nome da interface juntos no registro de mudanças. Uma regra correta para um pool traduz mal a seguinte.