Regras que encaminham todas as portas podem engolir o seu listener WireGuard

Um gateway público já executa WireGuard em UDP 51820, SSH na 22 e uma aplicação que precisa ser alcançável pela internet. A regra tentadora encaminha todas as portas para o peer e dá o trabalho por concluído. Num gateway WireGuard, essa regra pode capturar o transporte do próprio túnel e trancar você fora da máquina que o termina. Publicar é uma decisão de roteamento com uma exceção para o plano de controle, não uma única linha DNAT.

Entrada pública ou entrada pelo túnel: escolha uma

Publicar um serviço cria um novo ponto de entrada na internet. Não é o mesmo que conceder associação VPN a um peer, porque o visitante nunca entra no túnel e o gateway passa a ser a face pública do backend. Essa distinção decide o público da regra e o seu certificado.

Interfaces administrativas raramente pertencem a essa posição. Uma página de administração alcançada por clientes VPN autorizados mantém a superfície de ataque dentro do túnel e evita expor um formulário de login a varreduras arbitrárias. Endpoints de aplicação públicos ainda precisam do próprio certificado TLS, autenticação e limitação de taxa; o salto WireGuard cifrado não protege o trecho do visitante até o gateway.

Se o serviço realmente precisa ser público, anote o nome do host, o certificado que o cobre e as faixas de visitantes que devem alcançá-lo. Esses três fatos decidem depois a forma da regra e a política de filtro. Tudo fora deles é ampliação de escopo num listener público.

Uma porta entra, um backend sai

Use uma única porta pública e um único serviço de backend. Neste exemplo, a eth0 carrega o endereço público 198.51.100.20, o endereço de túnel do gateway é 10.200.0.1 e o peer executa a aplicação em 10.200.0.7. A porta pública TCP 9443 é mapeada para a TCP 8443 do peer:

iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1

A regra SNAT corresponde ao backend traduzido e ao destino público original, então outra conexão ao mesmo serviço de backend fica fora deste mapeamento. Ela também esconde o endereço do visitante do peer, e esse é o compromisso que torna um retorno roteado com preservação da origem um projeto separado. A referência das extensões do iptables documenta ambos os alvos e as suas opções de correspondência.

O encaminhamento ainda precisa estar habilitado, e a cadeia de filtro precisa de uma permissão para o destino e a porta traduzidos mais as respostas estabelecidas. A cadeia FORWARD vê o destino traduzido depois do DNAT, então uma regra escrita contra o endereço público não corresponde ao pacote encaminhado. Escreva a permissão contra a tupla do backend, não contra a pública.

O peer precisa aceitar a conexão do serviço a partir do endereço de túnel do gateway e enviar a resposta de volta pelo túnel. O AllowedIPs dele precisa autorizar a origem que ele realmente recebe, que sob tradução de origem é o endereço de túnel do gateway, e uma entrada ampla 0.0.0.0/0 em cada peer não é necessária para este projeto. O que derruba o tráfego de retorno é um peer cuja lista omite esse endereço, ou um projeto com preservação de origem que encaminha o endereço do próprio visitante, então verifique a origem que o peer realmente vê, não a que está na sua regra.

Mantenha os listeners do próprio gateway fora da regra

Troque a correspondência de porta por uma regra que cobre todo destino TCP e UDP, e o socket WireGuard do próprio gateway cai dentro dela. A tradução de destino acontece antes de a máquina decidir que um pacote é local, então o UDP 51820 pode acabar no peer em vez de no processo que mantém todas as conexões de peers. A regra carrega sem erro e o túnel morre, uma falha difícil de ler do lado do peer.

SSH, agentes de monitoramento e qualquer outro serviço hospedado no gateway têm a mesma exposição. Uma regra que encaminha tudo não distingue o plano de controle da aplicação publicada, e o primeiro reinício após a mudança é quando o bloqueio fica óbvio. A regra que captura tudo não avisa sobre o serviço que assume em silêncio. Você descobre quando a conexão seguinte falha.

Se o encaminhamento amplo for realmente necessário, reserve as portas de controle antes da regra que captura tudo ou use um endereço público separado para a publicação. A segunda opção é mais limpa porque o endereço de controle mantém a própria política, mas o provedor precisa entregar esse endereço; acrescentar um registro DNS não aloca nenhum.

O encaminhamento amplo de TCP e UDP também não cobre todos os protocolos. ICMP, IPv6, o retorno de path-MTU e o transporte externo da VPN precisam da própria política, e uma regra que cobre TCP e UDP deixa esses casos para a cadeia padrão.

Escolha o modelo antes de escrever as regras

Quatro formas cobrem a maioria das publicações a partir de um gateway, e a escolha depende de quantos serviços você executa e de quanto risco no plano de controle você tolera. A tabela abaixo as ordena da mais estreita para a mais ampla.

Comece pelo modelo estreito mesmo que espere mais serviços depois. É o mais fácil de auditar, e converter um conjunto de regras estreitas numa regra que captura tudo já revisada é mais simples do que descobrir qual listener uma regra ampla capturou. Seja qual for o modelo, mantenha as regras com o dono do firewall. Aplicar linhas de iptables ao lado de uma configuração de UFW ou nftables que também gerencia as mesmas cadeias produz uma política que muda conforme a ordem de inicialização.

Comprove a publicação e o caminho de controle

Teste a partir de um cliente externo autorizado usando o nome de host aprovado e um certificado válido para ele. Confirme qual backend respondeu e depois verifique que portas públicas não relacionadas continuam negadas. Uma verificação de certificado desativada não é um teste HTTPS aprovado, e uma conexão que chega ao backend errado é pior do que uma que falha.

Depois disso, verifique o próprio gateway: conecte um peer WireGuard, abra uma sessão SSH e confirme que o monitoramento ainda reporta. O serviço publicado pode funcionar enquanto o plano de controle está quebrado, então as duas verificações pertencem à mesma janela de mudança. Reinicie uma vez para provar que as regras são reaplicadas na ordem esperada, depois remova a publicação e confirme que a remoção realmente corresponde ao acréscimo. Um grande conjunto de acréscimos na inicialização com uma remoção incompleta é como um teste temporário vira uma abertura permanente.