Como burlei o CGNAT e consegui expor o localhost:80 para a internet

#Oracle Cloud
#Linux
#Serverless
#C#
#Cloud

Introdução

Se você já tentou expor um servidor local, de verdade, e descobriu que sua operadora usa CGNAT, sabe como isso é frustrante. Eu também passei por isso. Neste artigo explico, de forma prática, como entendi o que realmente é um túnel e como usei uma VPN + VPS (grátis) com IP público para finalmente tornar meus sites, serviços, APIs, Bots e até servidores de jogos hospedados na minha casa, acessíveis, mesmo sem ter um IP Público e estando atrás do CGNAT.

Quem sou eu e por que isso importa

Sou estudante de Engenharia de Software, desenvolvedor (C#) e entusiasta de selfhosting e homelab. Sempre achei que não seria possível expor algo hospedado no meu PC pra internet, diretamente, por causa do CGNAT. Só depois de compreender o funcionamento real do túnel de VPN é que tudo fez sentido. Este artigo é exatamente o que eu gostaria de ter lido antes de começar mexer com isso.

O que é o CGNAT

Quando o IPv4 foi criado, nos anos 80, ninguém imaginaria que 4 BILHÕES (e uns quebrados) de IPs não seriam, nem de longe, suficientes pra atender toda a demanda por IPs da humanidade. Mas a gente precisa um pouco mais que isso, e por isso foi criado o IPv6. Porém até toda a infra do mundo ser atualizada e ele ser totalmente implementado, precisamos nos "virar nos trinta" com o IPv4

E é por isso que as operadoras usam CGNAT (Carrier Grade NAT) para colocar vários clientes atrás de um único IP público. Isso possibilita com que uma operadora que tem apenas 10 IPs públicos, consiga fornecer acesso à internet pra centenas de usuários.

Contudo, para o usuário final, isso significa:

você não recebe um IP público próprio
sua rede fica atrás de um NAT compartilhado
conexões de entrada são bloqueadas
abrir portas no roteador não resolve

Mas existe um detalhe crucial:

Conexões de saída sempre funcionam.

E é isso que torna possível contornar o CGNAT.

Onde eu estava errando

Por muito tempo eu achava que "contornar o CGNAT" envolvia alguma técnica avançada, quase um hack. O problema é que eu não entendia como o túnel funciona internamente.

A ficha caiu quando percebi que:

Conectar-se a uma VPN é criar uma conexão de saída contínua.

Ou seja, meu PC (atrás do CGNAT) abre uma conexão para fora, em direção à minha VPS.

Como essa conexão fica aberta, permanente, ela vira um canal por onde a VPS pode devolver tráfego e isso permite expor qualquer serviço rodando localmente.

Quando a ficha caiu: o túnel não atravessa o CGNAT, ele burla

Eu nunca tinha entendido essa analogia do túnel. "Como assim faz um TÚNEL na rede que atravessa o CGNAT??"

A verdade é que a VPN não atravessa, não "quebra" o CGNAT.

Ela simplesmente cria um caminho de dentro para fora, que permanece ativo. Como um "ping eterno".

Quando seu PC inicia o túnel:

o CGNAT permite a saída (como sempre)
a conexão fica aberta de forma contínua
a VPS passa a conseguir enviar pacotes de volta pelo mesmo caminho

É como se você tivesse uma linha telefônica sempre aberta entre sua casa e uma central. Ninguém pode ligar diretamente para você, mas se o seu telefone ficar ligado o tempo todo, você vai ouvir quando a central recebe a ligação e passa para você.

Visualmente:

Cliente -> VPS (IP público) -> Túnel VPN -> Seu PC/homeserver (CGNAT)

Por que isso permite expor qualquer serviço

A lógica é simples:

A VPS tem IP público: qualquer cliente pode acessar
Seu PC/homeserver está conectado à VPS via VPN
A VPS recebe a requisição externa do cliente
Ela redireciona pro "túnel"
Seu PC/homeserver recebe, processa e responde
A resposta volta para a VPS
A VPS redireciona a resposta de volta pro cliente

Com isso, seu PC ou homeserver finalmente "ganha" um IP público através da VPS.

Por que não usei Cloudflare Tunnel (e quando vale a pena usar)

Talvez você se pergunte: "Mas a cloudflare tem um serviço gratuito que faz exatamente isso... um túnel!”

De fato! E soluções como Cloudflare Tunnel funcionam muito bem para expor sites e dashboards.

Mas elas só servem para protocolos HTTP/HTTPS.

Eu precisava mais:

servidores de jogos,
APIs em portas não convencionais,
serviços TCP/UDP variados.

Por isso optei por usar VPN + VPS, que é neutro em protocolo e me dá controle total.

Resumo rápido da minha "infraestrutura" caseira

Depois que entendi o túnel, montei um ambiente completo em casa:

um notebook antigo virou meu servidor local Linux
serviços rodando em Docker
gerenciados pelo Portainer
proxy reverso com Nginx Proxy Manager
e, na VPS da Oracle, iptables redirecionando portas para o túnel

Visão geral de como eu fiz e como reproduzir essa solução

1. Obtenha uma VPS com IP público

Usei uma instancia da Oracle Free Tier (é gratuita para sempre), mas qualquer VPS funciona

2. Instale WireGuard (ou outra VPN)

WireGuard é leve, rápido e simples

3. Configure o servidor (VPS)

Ele será o peer principal, com o IP público

4. Conecte seu dispositivo local à VPN

Assim você cria o túnel contínuo de saída

5. Libere e Redirecione portas na VPS

Usei o iptables no Linux e as configurações da Security List na rede da Oracle Cloud

6. Pronto: acesse seu serviço

O cliente se conecta à VPS e a VPS envia o tráfego pelo túnel até você

Tradeoffs e por que valeu a pena

Essa abordagem tem vantagens e responsabilidades:

Prós

controle total
nenhum limite de plataforma
privacidade
zero custo usando a VPS da Oracle Free Tier
aprendizado profundo de redes e infraestrutura

Contras

você precisa manter TUDO: energia, internet e atualizações
tudo depende da sua configuração
cuidados redobrados com segurança
exige manutenção continua

Ainda assim:

Nenhuma plataforma moderna (Vercel, Netlify, Serverless etc.) chega perto da experiência de operar sua própria infraestrutura.

E serve pra que tudo isso?

Além de todo o aprendizado fazendo tudo funcionar, ter um servidor próprio me oferece controle total e liberdade para rodar e experimentar qualquer coisa que eu quiser, gastando apenas um valor mínimo de energia pra manter ele ligado 24/7.

O que eu rodo ou já rodei no meu homeserver:

Soluções Frontend (NGINX)

Containers Docker NGINX para servir websites e soluções frontend

APIs Backend

Containers Docker com dotNET/ASP.NET para servir APIs backend

Automação e Integração

n8n para automações de workflows, usada para integrar e orquestrar diversos processos
Evolution API para automações e disparo de mensagens no WhatsApp
Script bash que monitora a temperatura do servidor, limita processos causadores de superaquecimento e dispara alertas via webhook para o n8n, que por sua vez envia as notificações para o meu WhatsApp.

Bancos de Dados

Containers Docker para bancos de dados: MariaDB, PostgreSQL, Redis

Servidores de Jogos

Servidores de jogos, incluindo Valheim, Aska, Enshrouded, e até mesmo um servidor de MMORPG: ArcheAge (em C#)

Conclusão

Agora que você entendeu como funciona o túnel VPN + VPS, experimente criar o seu próprio túnel. Comenta aí o que você acha dessa solução! Qual serviço você testaria na sua própria rede?

Obrigado pela leitura!