Meu ISP retirou meu endereço IPv4 público anos atrás, e o CGNAT tem sido a ruína do meu laboratório doméstico desde então. Tailscale resolveu o acesso privado tão bem que parei de me importar. Mas Tailscale deliberadamente não faz nada: acesso público bruto onde meus serviços podem ser vistos real O endereço IP do usuário que está fazendo a conexão. O funil é apenas HTTPS, e tudo o que passa por um retransmissor ou proxy é registrado como um endereço de túnel, o que significa que as ferramentas de monitoramento de invasões e fail2ban funcionam, bem como o bloqueio geográfico.
Então, eu mesmo criei a peça que faltava usando o WireGuard Tunnel em execução no nível gratuito do Oracle Cloud. Uma tarde de trabalho depois, tive serviços capazes de registrar endereços IP de operadoras por trás do CGNAT, graças a um truque útil do iptables.
O nível gratuito da Oracle é bom se você conhece as armadilhas da configuração
Estes são dois firewalls, uma caixa de seleção e uma arma MTU
A Oracle sempre inclui uma pequena VM AMD no nível gratuito (VM.Padrão.E2.1.Micro) com um endereço IPv4 público real para sempre por US$ 0. Este endereço é o ponto de inscrição porque a falta de endereços IPv4 é a razão pela qual o CGNAT existe, e a Oracle o fornece gratuitamente. Eu escolhi deliberadamente o formato x86 pequeno em vez da opção Arm mais poderosa porque os gabinetes Ampere A1 são uma loteria na maioria das regiões e o relé WireGuard não precisa de núcleos.
Atualize sua conta para Pague conforme usar defina um orçamento de $ 1 de qualquer maneira. A atualização para PAYG impede que a Oracle recupere VMs ociosas, e o alerta de orçamento significa que você não terá nenhuma surpresa desagradável no final do mês.
A configuração ocorreu (na maior parte) sem problemas e, quando isso não aconteceu, a culpa foi minha. eu pulei Atribuir um endereço IPv4 público opção durante a criação da instância, que felizmente foi recuperável porque a máquina virtual acabou em uma sub-rede pública. Ainda faltam apenas alguns minutos para criar uma nova máquina virtual, e a maior parte dela está aguardando que a Oracle a provisione.
Então me deparei com o firewall duplo da Oracle. Sim, dois. Lado da nuvem Lista de segurançae um conjunto regras de iptables VMs Ubuntu incorporadas que rejeitam tudo, exceto SSH. Ambos exigem regras correspondentes para ativar uma porta aberta.
Outro problema é que a imagem do Ubuntu vem com o MTU 9000 e matará silenciosamente o WireGuard, a menos que você tunele o MTU 1420.
Talvez eu devesse ter dito problemas porque o firewall IPv6 está vazio. Isso não é necessário se você estiver usando apenas IPv4, mas vale a pena saber se você planeja usar IPv6. Cada um deles é uma solução de cinco minutos, uma vez que você sabe sobre eles, ou uma noite perdida e uma falha de segurança, se você não souber.
Por que DNAT sem SNAT é o truque que todo mundo está perdendo
Seu firewall pode finalmente ver quem está batendo
A receita padrão para encaminhamento de porta usando WireGuard que você verá na maioria dos tutoriais funciona, mas está quebrada por design. A maioria deles adiciona uma regra de máscara que aponta para um túnel que substitui o endereço de origem do tráfego de entrada. Seu serviço doméstico vê cada visitante recebido como 10.66.66.1. Isso quebra as listas de banimentos; registrar e denunciar abusos é inútil.
Um baile de máscaras nem era necessário. Ele descreve um problema de roteamento que o roteamento de política resolve corretamente e encontrei uma solução A essência do GitHub de Pituluk. Somente substituições no lado do servidor destino pacotes recebidos, apontando-os para o túnel enquanto deixa o endereço de origem real intacto:
# On the VPS, in wg0.conf — DNAT only, no SNAT toward the tunnel
PostUp = iptables -t nat -A PREROUTING -p tcp -i ens3 --dport 25565 -j DNAT --to-destination 10.66.66.2
PostUp = ip -4 rule add iif wg0 table main
Esse é um lado, mas a parte inteligente mora em casa. Seu tráfego de resposta geralmente é roteado através de sua conexão CGNAT com o endereço de origem errado, eliminando todas as conexões, daí o uso de mascaramento nos tutoriais. Em vez disso, configure o cliente WireGuard para rotear seu tráfego de resposta de volta através do túnel.
# On the home peer — the part everyone skips
Table = off
PostUp = ip route add default via 10.66.66.1 dev wg0 table 123
PostUp = ip rule add from 10.66.66.2 lookup 123
Todo o resto que a máquina faz ainda usa a conexão normal; sem roteamento completo de túnel, sem mascaramento, sem perda de endereços de origem. E funciona. Estou testando usando meu telefone em uma conexão celular no meu VPS e observando os logs em um contêiner em meu escritório atrás do CGNAT.
E os registros? Eles mostraram 172.225.30.89 - - (26/Jul/2026 09:41:12) "GET / HTTP/1.1" 200. Eu esperava ver o endereço IP da minha operadora e quem disse que era a Akamai Technologies. Isso ocorre porque eu tinha o iCloud+ Private Relay em execução no meu telefone, que usa Akamai. Depois de desligá-lo, vi meu bloco T-Mobile. Em seguida, adicionei a regra de mascaramento novamente e a próxima solicitação veio do endereço IP 10.66.66.1 para o Oracle VM.
Como bônus, a página do iPhone foi carregada de dois endereços Akamai diferentes em um segundo porque o Private Relay atribui um IP de saída a cada conexão. Se a sua lógica de proibição pressupõe que um visitante equivale a um IP, os smartphones de hoje quebram-na sem que você perceba.
Adicionar novo encaminhamento de porta é um processo curto
É quase tão fácil quanto usar a GUI
Adicionar um novo serviço posteriormente é uma viagem de duas paradas, e são as mesmas duas paradas de cada vez. Oracle executa um firewall na nuvem ( Lista de segurança), e sua VM está executando outra na caixa, e a porta não está aberta até que ambos concordem – isso me atrapalhou mais de uma vez. Primeira parada: adicione uma regra de entrada à sua lista de segurança com uma fonte 0.0.0.0/0protocolo wg0.confsubstitua os novos valores e reinicie o túnel:
PostUp = iptables -t nat -A PREROUTING -p-i --dport -j DNAT --to-destination
PostDown = iptables -t nat -D PREROUTING -p-i --dport -j DNAT --to-destination
Após uma reinicialização rápida do serviço com sudo systemctl restart wg-quick@wg0porto estava ativo. Você esperaria uma terceira parada na cadeia INPUT da máquina virtual, mas o tráfego encaminhado nunca a atinge. O DNAT ocorre antes do roteamento, então os pacotes viajam pela cadeia FORWARD diretamente para o túnel. As regras INPUT são relevantes apenas para portas atendidas pelo próprio VPS, como o listener WireGuard.
CGNAT tem imposto mas a correção agora é gratuita
O caminho completo vai de qualquer cliente na Internet, usando a máquina virtual gratuita da Oracle, através do túnel WireGuard para o qual meu contêiner foi invocado. para o exterior (então a configuração do meu roteador nunca mudou), para serviços que registram endereços. O desvio através dos servidores Oracle Ashburn adiciona um tempo de ida e volta de 8 ms, o que não é nada, e o túnel é reiniciado em ambas as extremidades.
O Tailscale ainda está em minha configuração fazendo o que faz de melhor, e ainda incentivo todos a deixarem o Tailscale fazer primeiro a parte assustadora do acesso privado, já que esta versão resolve especificamente a intrusão pública. Mas evita projetos que exigem um endereço IP real em vez de Tailnet e contorna o CGNAT com um serviço gratuito.
