Proxmox NAT: quando uma VM privada perde Internet com o firewall ativo

Você ativa o firewall Proxmox em um nó que permanece acessível pela Web UI e via SSH. A VM privada, por sua vez, não consegue mais acessar a Internet. Uma rota ausente, o forwarding desativado ou um MASQUERADE ausente produzem o mesmo sintoma.

Antes de alterar uma regra, verifique a rota, o NAT e a regra MASQUERADE, e depois o DNS. Em seguida, controle a policy_out da VM e o caso específico das zonas conntrack em fwbr+. A correção oficial não diz respeito a todos os montagens NAT, então mantenha o rollback à mão.

Identificar o cenário correto antes de alterar as regras

O diagnóstico visa uma VM ou um CT colocado em uma sub-rede privada. Seu bridge não tem uma porta física pública direta e o convidado sai através do endereço público do nó Proxmox com uma regra de masquerading.

Aqui estão os passos a seguir antes de qualquer modificação:

• confirmar que o convidado possui um endereço privado e uma rota padrão;
• confirmar que o NAT existe no nó e que o forwarding IPv4 está ativo;
• confirmar que o firewall está ativo enquanto a Web UI e o SSH do nó permanecem acessíveis.

Se a VM nunca teve uma saída funcional, volte primeiro ao bridge, à interface virtual e à interface convidada. O artigo Restaurar a rede de uma VM Proxmox, do bridge ao convidado cobre esse ramo do diagnóstico.

Leia a rota e o NAT antes de culpar o firewall

Primeiro, é preciso entender se o pacote realmente está saindo da VM. No convidado, procure uma linha default com:

ip route
ping -c 3 1.1.1.1

Uma rota padrão ausente explica uma saída impossível. Uma falha do ping para o endereço IP de teste, portanto, não prova ainda que o firewall está bloqueando a VM.

No nó, verifique o forwarding e a cadeia POSTROUTING:

sysctl net.ipv4.ip_forward
iptables -t nat -S POSTROUTING

A documentação Proxmox descreve o masquerading para convidados privados com uma regra do tipo POSTROUTING. Seu exemplo utiliza 10.10.10.0/24, a interface de saída eno1 e a ação MASQUERADE. Adapte esses valores à configuração já presente, sem substituir uma regra ao acaso.

Um ip_forward=0, uma regra NAT ausente ou uma má interface de saída deslocam o problema para fora do firewall. Configurar o firewall Proxmox sem perder o acesso responde ao caso em que o acesso ao nó em si está em jogo.

Separar saída IP, DNS e atualização APT

Teste as camadas nesta ordem. Uma falha na resolução DNS não permite concluir que há um bloqueio no firewall.

ping -c 3 1.1.1.1
getent hosts deb.debian.org
curl -I https://deb.debian.org/

• o ping IP falha: verifique a rota, o forwarding e o MASQUERADE;
• o ping IP responde, mas getent falha: verifique o resolvedor convidado e uma eventual policy_out que bloqueie DNS;
• a resolução responde, mas a requisição HTTP falha: controle a saída HTTPS, a política da VM e a conectividade com o repositório;
• a saída de rede funciona, mas a atualização APT falha: não modifique o NAT antes de ter verificado o repositório e a imagem utilizada.

O teste APT diz respeito às imagens Debian e Ubuntu. Para outra distribuição, utilize o gerenciador de pacotes e o repositório adequados. O resultado esperado permanece o mesmo: distinguir uma falha de endereço IP, de resolução ou de acesso ao repositório.

Verificar a policy OUT e os logs Proxmox sem alterar o bridge

Quando a rota e o NAT estão coerentes, passe para a zona firewall do convidado. Proxmox separa as zonas Host, VM/CT e VNet. Uma regra da VM não é lida no mesmo lugar que uma regra que protege o nó.

No nó, mostre o estado e a compilação das regras:

pve-firewall status
pve-firewall compile

Depois, releia a configuração da VM ou do CT em /etc/pve/firewall/<VMID>.fw. Procure policy_out, log_level_out e as regras de saída que dizem respeito a DNS, NTP ou HTTP/HTTPS. Consulte também o Firewall Log da interface Proxmox se a gravação estiver ativada.

pve-firewall simulate pode simular uma origem, um destino, uma porta e um protocolo. Não simula a tabela de roteamento do kernel. Um resultado favorável, portanto, não valida o caminho completo do NAT.

Para as regras VM/CT, as políticas de saída e os logs, consulte também Regras de firewall Proxmox para uma VM ou um CT. Não mude o bridge para corrigir uma policy de saída.

Verificar o caso oficial das zonas conntrack em fwbr+

A documentação Proxmox aponta um caso particular: com algumas montagens de masquerade e o firewall ativo, as conexões de saída podem preferir o POSTROUTING do bridge da VM ao MASQUERADE. Uma zona conntrack pode então ser necessária para evitar um bloqueio de saída.

Não generalize essa correção para todos os NAT Proxmox. Verifique primeiro a presença de um bridge firewall na tabela raw:

iptables -t raw -S PREROUTING | grep 'fwbr'

Se o tráfego corresponder a esse cenário, a documentação oficial propõe essas duas linhas na configuração de rede concernida:

post-up iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1

A primeira linha adiciona a zona à subida da rede. A segunda remove exatamente a mesma regra na descida. Adicione-as na stanza existente de /etc/network/interfaces que possui a rede concernida, após ter confirmado que o NAT está funcionando bem nesse caminho.

Se o comando raw não mostrar nenhum fwbr e que a saída IP já funciona, não force a zona 1. Procure em vez disso pela rota, o NAT, o DNS ou a policy OUT que permanece em falha.

Testar a correção sem quebrar o acesso ao nó

Antes do recarregamento da rede, mantenha as duas linhas à vista e preveja uma janela de manutenção caso o acesso remoto possa ser interrompido. Recomendo manter o acesso ao console ou um outro caminho de recuperação antes de modificar /etc/network/interfaces.

Após aplicar a configuração, verifique primeiro a regra raw, depois repita os três testes a partir da VM:

iptables -t raw -S PREROUTING | grep 'fwbr'
ping -c 3 1.1.1.1
getent hosts deb.debian.org
curl -I https://deb.debian.org/

A saída IP deve responder antes de avaliar o DNS. A resolução deve responder antes de concluir sobre o acesso HTTP ou o repositório APT. Se o sintoma voltar, remova as duas diretivas post-up e post-down adicionadas, e verifique se a linha CT --zone 1 não aparece mais em iptables -t raw -S PREROUTING.

Atenção: pve-firewall stop retira ativamente as regras iptables Proxmox e pode deixar o host sem proteção. Este comando não substitui o diagnóstico e não deve ser usado como uma solução normal para uma VM privada que perde sua saída NAT.

O veredito será muito concreto: rota, forwarding, MASQUERADE, DNS e policy OUT devem ser coerentes antes de culpar o firewall. Se o NAT passa pelo fwbr+, a zona conntrack torna-se uma correção pontual, com um rollback simétrico. Caso contrário, volte ao diagnóstico do bridge ou às regras VM/CT.

Referências: documentação Proxmox sobre NAT e masquerading, documentação Proxmox VE Firewall e manual oficial pve-firewall.