CGNAT na MEO: Como Verificar e Contornar para Acesso Remoto em 2026

CGNAT  |  ✎ Duarte Spínola  |  2026-06-27

A MEO é uma das operadoras portuguesas que aplica CGNAT (Carrier-Grade NAT) em ligações de fibra e ADSL para clientes particulares sem IP fixo. Isto significa que o teu router não recebe um endereço IPv4 público único — partilhas um endereço com dezenas ou centenas de outros clientes. Como consequência, tudo o que dependa de ligações inbound (servidores, port forwarding, acesso remoto a NAS ou câmaras IP) deixa de funcionar por IPv4. Este guia explica o que é o CGNAT, como verificares se estás afetado e quais as alternativas práticas disponíveis em 2026, com exemplos de configuração reais para Cloudflare Tunnel, Tailscale, WireGuard e IPv6.

Embora a MEO forneça connectivity IPv6 nativa (prefixo /64 via DHCPv6-PD) em grande parte da sua rede de fibra, muitos utilizadores só descobrem o problema quando tentam aceder ao NAS de casa a partir do escritório e percebem que o IP que vêem não corresponde ao IP atribuído ao router. Vamos cobrir tudo: diagnóstico, pedido de IP público pago e cinco alternativas para contornares o CGNAT sem mudares de operadora.

Conteúdos

1. O que é CGNAT e porque a MEO usa

CGNAT significa Carrier-Grade NAT, também designado LSN (Large-Scale NAT). É um mecanismo definido formalmente no RFC 6598 (IETF, 2012), que reservou o bloco 100.64.0.0/10 (endereços de 100.64.0.0 a 100.127.255.255) para uso interno de operadores, em vez do bloco privado habitual 192.168.0.0/16 ou 10.0.0.0/8. Este bloco é o “segundo nível” de NAT depois do NAT doméstico normal.

Em termos simples, o tráfego faz duas traduções de endereço: (1) o teu router doméstico traduz 192.168.1.x (LAN) para o IP WAN atribuído pela MEO (que pode ser 100.64.x.x); (2) um gateway CGNAT central na operadora traduz esse IP interno (100.64.x.x) para um IP público partilhado com outros clientes. O resultado: de fora, só é visível um único IP público partilhado por muitos clientes, e a operadora só pode aceitar ligações inbound para o IP público se houver uma entrada ativa na tabela de tradução — o que só acontece em resposta a uma ligação iniciada de dentro.

Porque as operadores usam CGNAT? Os endereços IPv4 são um recurso finito (4,3 mil milhões, declarados esgotados ao nível global em 2019 pelo RIPE NCC, que cobre a Europa). Com a crescente adopção de fibra e novos clientes, a MEO (e outras operadores em Portugal: NOWO, Vodafone em alguns planos) simplesmente não têm IPv4 suficientes para dar um IP público a cada cliente. O CGNAT permite multiplexar muitos clientes num único IP público, prolongando a vida do IPv4 por mais anos.

Em Portugal, a prática generalizou-se a partir de 2018-2019. Clientes particulares com fibra e contrato residencial sem opção de IP fixo recebem tipicamente um endereço do bloco 100.64.0.0/10 no WAN do router, atrás do CGNAT. Clientes com serviço “IP fixo” pago (ou planos empresariais) recebem um IP público real. A operadora não anuncia isto explicitamente na publicidade — é a infraestrutura por omissão.

O CGNAT tem implicações técnicas para além de port forwarding: o NAT em larga escala consome portos TCP/UDP por cliente (típico: 1000-2000 portos por cliente), o que pode ser um limite em casas com muitos dispositivos. Latência de ida e volta pode aumentar ligeiramente (alguns ms), e alguns serviços anti-fraude (bancos, streaming geo-bloqueado) começam a bloquear IPs CGNAT conhecidos por verem tráfego de múltiplas identidades a vir do mesmo IP. Também quebra protocolos peer-to-peer que dependam de inbound directo.

O bloco 100.64.0.0/10 é definido no RFC 6598 “IANA-Reserved IPv4 Prefix for Shared Address Space”. O RFC 1918 (blocos privados 10/8, 172.16/12, 192.168/16) é descrito no RFC 1918; o IPv6 e o conceito de NAT66 são tratados no RFC 4291 (IPv6 Addressing Architecture). Toda a fundamentação técnica está em domínio público.

2. Como verificar se estás em CGNAT

O diagnóstico é simples e leva 2 minutos. A lógica: compara o IP que os serviços externos vêem (IP público) com o IP que o teu router tem no WAN (interface virada para a MEO). Se o IP WAN do router estiver no bloco 100.64.0.0/10, estás atrás de CGNAT. Se ambos os IPs forem iguais, tens provavelmente IP público real (podes ainda estar atrás de NAT da operadora em casos raros — confirma com testes de inbound).

Passo 1: descobrir o IP público visto de fora

Usa um qualquer serviço que devolva o IP público. Em Linux/macOS ou Termux:

# Método 1: ifconfig.me (clássico)
curl -s ifconfig.me && echo

# Método 2: icanhazip.com (devolve só o IP)
curl -s icanhazip.com

# Método 3: whatismyip.akamai.com (Akamai, fiável)
curl -s whatismyip.akamai.com

# Método 4: ipinfo.io com JSON completo
curl -s ipinfo.io/json | jq '.ip, .city, .country'

Anota o IP devolvido — é o IP público que a Internet vê.

Passo 2: ver o IP WAN do router

Liga-te ao router MEO (normalmente Smart Router 2 ou similar). Podes aceder via web em http://192.168.1.1 (verifica o gateway por defeito: ip route | grep default em Linux). Procura a página de status da ligação WAN — verás o endereço atribuído pela operadora.

Em alternativa, numa máquina dentro da rede, podes interrogar o router por TR-069 ou simplesmente ver o IP do próximo salto. Mas o método mais directo é mesmo a interface web do router.

# Em Linux: qual é o gateway por defeito (provavelmente o router)
ip route | grep default
# Output típico: default via 192.168.1.1 dev wlan0 proto dhcp metric 600

Passo 3: interpretar os resultados

IP WAN do router IP que sites externos vêem Diagnóstico
100.64.x.x … 100.127.x.x Outro IP (ex: 85.x.x.x) CGNAT confirmado
85.x.x.x (público) 85.x.x.x (igual) IP público dinâmico — podes fazer port forwarding
100.64.x.x 100.64.x.x Caso raro — operadora expõe o bloco CGNAT (mau sinal)

Atenção: alguns routers MEO mostram o IP 100.64.x.x como WAN mas o CGNAT é tão opaco que nem sempre percebes — o IP que aparece em ifconfig.me é o IP partilhado. A diferença entre os dois IPs (WAN vs público) é o indicador fiável. Se forem diferentes e o WAN estiver em 100.64.0.0/10, é CGNAT.

Teste adicional: traceroute para fora

# Verificar primeiros saltos — se veres 100.64.x.x no salto 1 ou 2, é CGNAT
traceroute -n 1.1.1.1
# ou
mtr -n 1.1.1.1

# Verificar o IP da interface externa do router (em Linux, gateway)
ip route get 1.1.1.1
# Mostra: 1.1.1.1 via 192.168.1.1 dev wlan0 src 192.168.1.234

Outro teste simples é tentar abrir uma porta do exterior. Configura um servidor de teste num port (por exemplo, python3 -m http.server 8080 na tua máquina) e faz port forwarding no router para 8080. De um telemóvel em 4G ou VPN externa, tenta aceder: curl -v http://SEU_IP_PUBLICO:8080. Se a ligação falhar (timeout) apesar do port forwarding estar bem configurado, estás em CGNAT — a entrada de NAT do CGNAT só é criada para tráfego outbound, não inbound.

3. Diferença entre IP público dinâmico, IP fixo pago e CGNAT

Existem três cenários possíveis para um cliente residencial MEO. A diferença é crítica para tudo o que se segue neste guia.

Característica IP público dinâmico IP fixo pago CGNAT
IP WAN do router 85.x.x.x (público) 85.x.x.x (público, fixo) 100.64.x.x (privado operador)
Partilhado com outros clientes Não Não Sim — até centenas
Port forwarding funciona Sim Sim Não
Servidor web acessível de fora Sim (com DDNS) Sim (sem DDNS necessário) Não (sem túnel)
Stun/TURN para VoIP/SIP Funciona melhor Perfeito Problemas frequentes
IP muda ao reiniciar router Possivelmente Não Partilhado, irrelevante
Custo adicional 0€/mês ~5-10€/mês (particular) ou incluído em planos empresa 0€/mês (imposto)
Latência adicional Mínima Mínima +1 a +5 ms (CGNAT gateway)
Geo-block em streaming/bancos Raramente Raramente Frequente (IP marcado como CGNAT)

Dica: Se queres evitar o CGNAT mas não queres pagar IP fixo, pede à MEO “IP público dinâmico” — por vezes é possível em algumas áreas, basta o router receber IP público sem ser fixo. Nem sempre está disponível, mas vale a pena perguntar. Combina com DDNS (secção 10) e tens acesso remoto sem custo adicional.

4. Impacto prático: port forwarding, servidores, câmaras IP, NAS, gaming

Estar atrás de CGNAT não afecta a navegação normal, streaming, videochamadas ou downloads — todo esse tráfego é outbound. Onde causa problemas é em qualquer serviço que precise receber ligações do exterior:

Port forwarding: simplesmente não funciona. Mesmo que cries regra NAT no router MEO (192.168.1.1 → 192.168.1.50:8080), o pacote nunca chega ao router MEO — o gateway CGNAT descarta-o porque não tem entrada de tradução para inbound. A regra NAT no router é inútil enquanto o CGNAT estiver ativo.

Servidor web/SSH em casa: não acessível. Podes ter um nginx a correr, mas de fora ninguém consegue aceder ao IP público partilhado. Precisas de túnel (Cloudflare Tunnel, Tailscale, WireGuard) ou IPv6 com DNS público.

Câmaras IP: as câmaras IP que dependam de visualização remota via IP:porta (sem P2P cloud proprietário) deixam de funcionar. Câmaras com solução cloud proprietária (Hikvision Hik-Connect, Dahua P2P, TP-Link Tapo, Eufy) funcionam porque usam servidores cloud do fabricante como relay. Mas se queres ver diretamente via RTSP ou app local, precisas de túnel.

NAS (Synology, QNAP, TrueNAS): QuickConnect (Synology) e myQNAPcloud funcionam porque usam relay proprietário. Mas DDNS directo e serviços como Nextcloud externo, PhotoStation acessível por URL própria, ou SSH ao NAS não funcionam sem túnel.

Gaming: jogos peer-to-host (onde o host é um jogador) podem ter problemas — o host não consegue receber ligações directas. Em jogos com servidor dedicado (CS, Valorant, LoL) o impacto é zero. Em jogos com matchmaking peer-to-peer (alguns jogos de consola, jogos indie) pode haver impossibilidade de hostear. NAT tipo “Strict” é comum.

VoIP/SIP: sem STUN/TURN explícito, registo SIP pode falhar ou áudio só funciona num sentido. Muitos softphones (Zoiper, Linphone) resolvem com STUN; chamadas RTP inbound podem não chegar. Para operadores VoIP português (VoIP.ms, Sipgate) configura TURN ou usa túnel SIP.

Self-hosting: Nextcloud, Jellyfin, Bitwarden/Vaultwarden, Home Assistant, Gitea, Grafana — nenhum é acessível de fora por IPv4. Tudo exige uma destas soluções: (a) IP fixo pago, (b) túnel para serviço externo (Cloudflare, Tailscale), (c) WireGuard com VPS público, ou (d) IPv6 se o cliente remoto também tiver IPv6.

VPN IPSec/L2TP ao router: não funciona. Não há port forwarding possível para a porta 500/4500. Solução: VPN over tunnel (WireGuard dentro do Tailscale, ou IPSec entre routers com IPs públicos em ambos os lados — ver o nosso guia FortiGate Firewall NAT e VPN IPsec).

5. Pedir IP público a MEO

A forma mais directa de resolver o CGNAT é pedir à MEO para desativar o CGNAT na tua ligação. Existem dois caminhos: (a) pedir um IP público dinâmico (nem sempre disponível, sem custo adicional em alguns casos); (b) subscrever o serviço de IP fixo (pago).

Para clientes particulares

Contacta a MEO pela linha de apoio cliente (1696 para particulares) ou pela área de cliente em cliente.meo.pt. Pede explicitamente:

  1. “Pretendo ativar o serviço de IP fixo no meu contrato residencial.”
  2. Confirma o custo mensal (varia consoante campanhas, tipicamente 5-10€/mês).
  3. Pede para confirmarem se é necessário algum equipamento específico (algumas áreas exigem router empresarial).
  4. Após activação, reinicia o router e verifica de novo o IP WAN — deve ser um IP público fixo.

Atenção: alguns operadores de apoio telefonam confundir “IP fixo” com “desativar CGNAT”. Esclarece: queres que o teu router receba um IP público no WAN, seja fixo ou dinâmico. Se só te oferecerem IP fixo pago, pergunta se existe opção de IP público dinâmico sem custo (em algumas zonas a MEO tem essa possibilidade).

Para clientes empresa

Clientes MEO Empresas têm acesso a planos com IP fixo incluído ou activável. Contacta o gestor de conta MEO Empresa ou a linha de apoio empresarial (1800 ou 707 24 24 24 Empresas). Para ligação site-to-site com VPN IPsec, é essencial pelo menos um lado ter IP fixo — recomenda-se IP fixo em ambos os lados. Vê também o nosso guia Azure VPN Gateway Site-to-Site para integração cloud.

Argumentos úteis ao contactar a MEO

  • “Preciso de acesso remoto ao NAS / câmaras de segurança” — uso legítimo frequentemente aceite.
  • “Trabalho em teletrabalho e preciso de VPN IPSec ao escritório” — para VPNs site-to-site.
  • “Tenho um serviço self-hosted que precisa de port forwarding” — caso genérico.
  • Se recusarem IP público dinâmico gratuito, pede IP fixo pago e confirma o custo.
  • Em última análise, ameaça mudar de operadora — Vodafone e Nos têm opções equivalentes; às vezes a retensão oferece IP fixo sem custo.

Aviso: alguns técnicos de apoio podem dizer “não temos CGNAT na sua área” mesmo quando tens 100.64.x.x no WAN. Pede para verificarem com o departamento de rede. Às vezes a primeira linha de apoio não sabe o que é CGNAT. Insiste de forma técnica.

6. Alternativa 1: IPv6 (MEO fornece /64 via DHCPv6-PD)

A MEO fornece conectividade IPv6 nativa na maioria da rede de fibra. O router recebe um prefixo /64 (ou em alguns casos /56) via DHCPv6 Prefix Delegation, e os dispositivos da LAN obtêm endereços IPv6 via SLAAC ou DHCPv6. Cada dispositivo fica com um IP IPv6 público e globalmente routeable — não há NAT. Port forwarding é substituído por regras de firewall IPv6 que permitem tráfego para o IP do dispositivo.

Em 2026, a maioria dos ISPs móveis (MEO Movimento, Vodafone, Nos) e operadores cloud (AWS, Azure, Google Cloud) já suportam IPv6. O problema clássico “mas o meu telemóvel em 4G tem IPv6?” está em grande parte resolvido. Verifica: curl -s -6 ifconfig.me deve devolver um IPv6 do bloco 2a0x:… atribuído pela operadora móvel.

Verificar IPv6 no router MEO

# Em Linux/macOS, verificar se tens IPv6 global
ip -6 addr show | grep "scope global"
# Output típico em MEO fibra:
# inet6 2a0d:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope global dynamic noprefixroute

# Verificar conectividade IPv6
curl -s -6 https://ifconfig.me && echo

# Verificar rota IPv6
ip -6 route show | grep default
# default via fe80::xxxx:xxxx:xxxx dev wlan0 proto ra metric 600

Se não tiveres IPv6, liga nas definições do router MEO (192.168.1.1) a opção “IPv6” / “Dual Stack”. Na maioria dos Smart Router MEO, está ativo por defeito. Se usares router próprio (pfSense, OPNsense, DrayTek), configura WAN para DHCPv6-PD com prefix /64 e SLAAC na LAN. Vê os nossos guias OPNsense Firewall Configuração e pfSense Firewall Configuração para detalhes.

Firewall IPv6: regras de inbound

No IPv6 não há NAT — todos os IPs são públicos. A firewall do router (ou do dispositivo) é que controla quem pode chegar. Para expor um serviço:

# Exemplo: permitir HTTP inbound a um servidor IPv6 específico
# No router (iptables-exemplo):
ip6tables -I FORWARD -d 2a0d:xxxx:xxxx:xxxx::50 -p tcp --dport 80 -j ACCEPT
ip6tables -I FORWARD -d 2a0d:xxxx:xxxx:xxxx::50 -p tcp --dport 443 -j ACCEPT

# No servidor, certificar que escuta em IPv6
ss -tlnp | grep nginx  # deve mostrar [::]:80

Considera também DNS AAAA. No Cloudflare ou no teu fornecedor de DNS, adiciona um registo AAAA para o hostname apontar para o teu IPv6 fixo. Como o prefixo MEO pode mudar (renumeração), usa DDNS IPv6 — o cliente dynv6.com ou o Cloudflare API actualizam automaticamente. O Azure tem suporte para IPv6 em VNets; vê a documentação de IPv6 no Azure para integração cloud.

Vantagem: IPv6 contorna CGNAT sem intermediário externo. Compatível com HTTP/3, sem overhead de túnel. Limitação: o cliente remoto precisa também de IPv6 (cada vez mais comum em 2026). Para casos mistos, combina IPv6 directo + Cloudflare Tunnel como fallback IPv4.

7. Alternativa 2: Cloudflare Tunnel (gratuito)

Cloudflare Tunnel (antigo Argo Tunnel) é um serviço gratuito da Cloudflare que estabelece um túnel outbound persistente da tua máquina para a rede Cloudflare. Não precisas de IP público, não precisas de abrir portas — o cloudflared mantém uma ligação HTTPS para cloudflare.com, e a Cloudflare encaminha tráfego inbound via esse túnel. É a forma mais simples e gratuita de expor um serviço self-hosted atrás de CGNAT.

Funciona assim: registas um domínio na Cloudflare (ou transferes um que já tens, custa ~10€/ano .com), instalas o cloudflared na tua máquina em casa, autenticas-te com a Cloudflare, crias um tunnel, defines um hostname público (ex: nas.meudominio.pt) que aponta para um serviço local (ex: http://192.168.1.50:5000), e pronto. A Cloudflare faz TLS termination no edge, o túnel transporta o tráfego encriptado para a tua máquina. Documentação oficial em developers.cloudflare.com/cloudflare-one.

Vantagens: grátis (inclui SSL, CDN, DDoS protection), não há port forwarding, não há IP fixo necessário, suporta HTTP, HTTPS, TCP arbitrário, SSH, RDP. Limitações: tráfego HTTP passa pela Cloudflare (sujeito aos termos de uso — proibido streaming de vídeo em massa, etc.); o túnel adiciona ~20-50 ms de latência dependendo do PoP Cloudflare servido (em Portugal, geralmente LIS ou MAD); para serviços não-HTTP, tens de usar o client cloudflared access no lado do cliente, que é menos conveniente que um browser.

Passo-a-passo detalhado na secção 12. Em baixo, a ideia geral:

  1. Criar conta Cloudflare gratuita (se não tiveres).
  2. Registar ou transferir um domínio para a Cloudflare (ou usar um subdomínio *.trycloudflare.com para testes sem domínio).
  3. Instalar cloudflared na máquina que vai servir de túnel (Raspberry Pi, NAS, servidor Linux).
  4. Autenticar: cloudflared tunnel login.
  5. Criar tunnel: cloudflared tunnel create kbase-tunnel.
  6. Configurar config.yml com hostname → serviço local.
  7. Correr como serviço: cloudflared tunnel run (systemd).

8. Alternativa 3: Tailscale (gratuito para uso pessoal)

Tailscale é uma rede overlay baseada em WireGuard que cria uma VPN mesh ponto-a-ponto entre os teus dispositivos. Não precisas de IP público — todos os dispositivos autenticam-se contra o servidor de coordenação do Tailscale (ou um servidor próprio com Headscale) e recebem um IP na sub-rede 100.64.0.0/10 (curiosamente, o mesmo bloco RFC 6598, mas usado aqui de forma intencional e não-confusiva como endereços da rede virtual). A ligação entre dois dispositivos é directa (peer-to-peer) sempre que possível, usando técnicas de NAT traversal (STUN, port prediction); quando não é possível, há relays DERP da própria Tailscale (gratuitos).

Vantagens: grátis para uso pessoal até 100 dispositivos, instala em 30 segundos, funciona em Linux/macOS/Windows/Android/iOS/synology/Apple TV, suporta subnet routing (uma máquina pode exportar a sub-rede 192.168.1.0/24 inteira para a rede Tailscale), MagicDNS (resolução por hostname), e SSH automatizado. Documentação oficial em tailscale.com/kb.

Limitações: tráfego de coordenação passa pelos servidores Tailscale (mas dados peer-to-peer são directos encriptados WireGuard). Para clientes empresa, opção paga com SSO, ACLs granulares. Para acesso remoto a um único NAS, é a forma mais simples. Para acesso a partir de qualquer browser (sem instalar Tailscale), usa Tailscale Funnel (exposição pública de um serviço, ainda em beta).

Instalação rápida em Linux (Debian/Ubuntu)

# 1. Instalar Tailscale
curl -fsSL https://tailscale.com/install.sh | sh

# 2. Iniciar e autenticar
sudo tailscale up
# Vai abrir um URL para autenticação no browser

# 3. Verificar status
tailscale status
tailscale ip -4  # mostra o IP Tailscale (ex: 100.101.102.103)

# 4. ativar subnet routing (exportar LAN 192.168.1.0/24)
sudo tailscale up --advertise-routes=192.168.1.0/24 --accept-routes

# 5. Para ativar subnet routes no painel admin:
# https://login.tailscale.com/admin/machines — clicar no device e "Edit route settings"
# Habilitar a rota 192.168.1.0/24

Em outros dispositivos (telemóvel, portátil), instala a app Tailscale, autentica-te com a mesma conta, e passa a poder aceder ao IP Tailscale do NAS (ex: http://100.101.102.103:8080) ou, com subnet routing ativo, directamente ao IP local http://192.168.1.50:8080 a partir de qualquer lugar.

Instalação em Raspberry Pi / NAS

# Raspberry Pi OS / Debian
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --advertise-routes=192.168.1.0/24

# Synology NAS: instalar via Package Center > "Tailscale"
# (pacote oficial disponível)
# Ou via Docker:
docker run -d --name=tailscale \
  --restart=always \
  -v /var/lib/tailscale:/var/lib/tailscale \
  -v /dev/net/tun:/dev/net/tun \
  --network-mode=host \
  tailscale/tailscale:latest \
  tailscaled --advertise-routes=192.168.1.0/24

Combinação poderosa: Tailscale como rede base + Cloudflare Tunnel para exposição pública de um serviço específico. Tailscale para aceder a tudo em casa (NAS, SSH, câmaras internas); Cloudflare Tunnel para um Nextcloud público acessível sem cliente Tailscale.

9. Alternativa 4: WireGuard self-hosted num VPS

Para quem quer controlo total e não confiar em serviços externos (Tailscale, Cloudflare), a alternativa clássica é alugar um VPS barato com IP público e configurar WireGuard com reverse tunnel. A ideia: a tua casa (atrás de CGNAT) mantém um túnel WireGuard persistente outbound para o VPS, e o VPS expõe portas públicas que encaminham para dentro do túnel. Quem acede ao IP público do VPS:8080 chega à tua casa.

VPS recomendados (preço baixo)

  • Hetzner Cloud — CX22 (~4€/mês, 2 vCPU, 4GB RAM, Alemanha/Finlândia). Excelente para isto.
  • Contabo VPS S — ~6€/mês, mais RAM (8GB), mas rede menos consistente.
  • OVH VPS Starter — ~3€/mês, França/Polónia.
  • Netcup VPS 200 — ~4€/mês, Alemanha.
  • Para Latência baixa em Portugal, escolhe datacenters em Madrid (MAD) ou Frankfurt (FRA).

Configuração do VPS (servidor WireGuard + reverse proxy)

# VPS: instalar WireGuard
sudo apt update && sudo apt install -y wireguard

# Configuração /etc/wireguard/wg0.conf no VPS
[Interface]
Address = 10.200.0.1/24
ListenPort = 51820
PrivateKey = <CHAVE_PRIVADA_VPS>

# Casa (peer atrás de CGNAT)
[Peer]
PublicKey = <CHAVE_PUBLICA_CASA>
AllowedIPs = 10.200.0.2/32
# Sem endpoint — a casa inicia a ligação

Configuração em casa (cliente + reverse tunnel)

# Casa: /etc/wireguard/wg0.conf
[Interface]
Address = 10.200.0.2/24
PrivateKey = <CHAVE_PRIVADA_CASA>

# PersistentKeepalive mantém o túnel aberto através do CGNAT
[Peer]
PublicKey = <CHAVE_PUBLICA_VPS>
Endpoint = VPS_IP_PUBLICO:51820
AllowedIPs = 10.200.0.0/24
PersistentKeepalive = 25  # importante! sem isto, o CGNAT fecha a entrada

Encaminhar porta pública do VPS para casa

# No VPS, encaminhar 8080/TCP do IP público para 10.200.0.2:8080 dentro do túnel
# Opção 1: socat (simples, não optimizado)
sudo apt install socat
socat TCP-LISTEN:8080,fork,reuseaddr TCP:10.200.0.2:8080

# Opção 2: iptables (eficiente, sem proxy)
sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.200.0.2:8080
sudo iptables -t nat -A POSTROUTING -p tcp -d 10.200.0.2 --dport 8080 -j SNAT --to-source 10.200.0.1

# Opção 3: nginx reverse proxy (para HTTP, com TLS termination no VPS)
# /etc/nginx/sites-available/casa
server {
    listen 80;
    server_name nas.meudominio.pt;
    location / {
        proxy_pass http://10.200.0.2:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Para SSH, RDP ou outros protocolos TCP não-HTTP, socat ou iptables DNAT são apropriados. Para UDP (ex: gaming, WireGuard dentro de WireGuard), usa iptables DNAT com -p udp.

Iniciar e testar

# Em ambos os lados
sudo wg-quick up wg0
sudo systemctl enable wg-quick@wg0

# Verificar túnel
sudo wg
# Deve mostrar "latest handshake" e "transfer" bytes a crescer

# Testar de fora: aceder ao IP público do VPS na porta encaminhada
curl http://VPS_IP_PUBLICO:8080

Para segurança, integra com firewall no VPS — só expõe as portas que precisas. Vê os nossos guias OPNsense e pfSense para configurações de firewall mais elaboradas.

Latência: adiciona 1 salto até ao VPS. Em casa com fibra MEO → VPS em Frankfurt: ~25-35 ms. Para serviços interactivos (SSH, Nextcloud) é imperceptível. Para gaming hosteado em casa, a latência extra pode afectar jogabilidade — considera VPS em Madrid (~10-15 ms).

10. Alternativa 5: DDNS + port forwarding (se IP público dinâmico)

Se conseguiste obter da MEO um IP público dinâmico (sem ser fixo), esta é a alternativa mais simples e com menor latência. Funciona assim: o teu router tem IP público (muda occasionalmente, tipicamente em cada reboot ou a cada 24h), e usas DDNS (Dynamic DNS) para manter um hostname sempre apontando para o IP actual.

Serviços DDNS

  • Dynv6.com — gratuito, suporta IPv4 e IPv6, cliente leve. dynv6.com.
  • DuckDNS — gratuito, subdomínio *.duckdns.org, fácil de configurar.
  • No-IP — gratuito com renovação mensal manual, ou plano pago.
  • Cloudflare API — se tiveres domínio na Cloudflare, podes atualizar o registo A via API (gratuito, sem limite de renovação). Recomendado.
  • Muitos routers MEO têm DDNS integrado (D-Link dyn, noip) — verifica no interface do router.

Configuração com Cloudflare API

#!/bin/bash
# /usr/local/bin/ddns-cloudflare.sh
# Executar via cron a cada 5 minutos

ZONE_ID="xxxx"
RECORD_ID="yyyy"
API_TOKEN="zzzz"
RECORD_NAME="nas.meudominio.pt"

IP=$(curl -s https://ifconfig.me)

curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID" \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  --data "{\"type\":\"A\",\"name\":\"$RECORD_NAME\",\"content\":\"$IP\",\"ttl\":60,\"proxied\":false}"

# Cron:
# */5 * * * * /usr/local/bin/ddns-cloudflare.sh >/dev/null 2>&1

Port forwarding no router

No router MEO (192.168.1.1), vai a “Advanced” → “NAT” → “Port Forwarding” (ou similar). Cria regra:

Campo Valor (exemplo)
External port 8080
Internal IP 192.168.1.50
Internal port 8080
Protocol TCP
Enabled Yes

Para routers mais avançados (DrayTek Vigor, Mikrotik, pfSense) a configuração é mais flexível. Vê o nosso guia DrayTek Vigor Router Configuração para detalhes.

Atenção: abrir portas ao IP público expõe-te directamente a ataques. Usa sempre: (1) HTTPS com Let’s Encrypt, (2) firewall no servidor (ufw) a limitar IPs se possível, (3) fail2ban para SSH/HTTP, (4) autenticação forte (2FA em Nextcloud, etc.). Não exponhas SSH na porta 22 — usa porta alta (ex: 22022) e desactiva password authentication, só chaves.

11. Comparação de soluções

Qual escolher? Depende do caso de uso, orçamento, conhecimentos técnicos e requisitos de latência. A tabela abaixo resume as cinco alternativas principais mais a opção “pedir IP fixo à MEO”.

Solução Custo Dificuldade Latência extra Fiabilidade Caso de uso ideal
IP fixo MEO 5-10€/mês Baixa Nenhuma Alta VPN IPSec site-to-site, servidores públicos com baixa latência
IPv6 nativo 0€ Média Nenhuma Média (depende do cliente ter IPv6) Self-hosting quando cliente remoto tem IPv6 (cada vez mais comum)
Cloudflare Tunnel 0€ (domínio ~10€/ano) Baixa-Média +20-50 ms Alta Expor serviços HTTP(S) públicos sem instalar cliente no utilizador
Tailscale 0€ pessoal (até 100 devs) Muito baixa Directa (p2p) ou +20-50 ms (DERP) Alta Acesso remoto pessoal a NAS, SSH, serviços internos
WireGuard + VPS 4-6€/mês (VPS) Alta +10-35 ms (VPS hop) Alta Controlo total, expor qualquer protocolo, sem depender de terceiros
DDNS + port forwarding 0€ (IP dinâmico) Baixa Nenhuma Média (IP pode mudar) Quando já tens IP público dinâmico (sem CGNAT)

Recomendação kbase.pt para 2026: se queres a vida mais fácil e grátis: Tailscale para acesso remoto pessoal. Se queres expor um serviço público acessível sem cliente: Cloudflare Tunnel. Se queres controlo total e não te importas de pagar 4€/mês: WireGuard + Hetzner VPS. Para VPN site-to-site entre escritórios: IP fixo MEO + IPSec. Combina Tailscale + Cloudflare Tunnel para cenários mistos.

12. Configurar Cloudflare Tunnel (passo-a-passo completo)

Vamos detalhar a configuração completa de um Cloudflare Tunnel para expor um serviço interno (ex: Nextcloud em http://192.168.1.50:8080) acessível publicamente em https://cloud.meudominio.pt. Documentação de referência: Cloudflare Tunnel — Create remote tunnel.

Passo 1: preparar domínio na Cloudflare

  1. Cria conta gratuita em dash.cloudflare.com.
  2. Regista um domínio (ex: meudominio.pt) — a Cloudflare é registar de .com/.net/.org e muitos TLDs. Em Portugal, .pt tens de registar em dns.pt (FCCN) e depois apontar nameservers para Cloudflare.
  3. Confirma que o domínio está “Active” na Cloudflare (pode demorar algumas horas).

Passo 2: instalar cloudflared

# Debian/Ubuntu/Raspberry Pi OS
# Adicionar repositório Cloudflare
sudo mkdir -p /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | \
  sudo gpg --yes --dearmor --output /usr/share/keyrings/cloudflare-main.gpg
echo "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared $(lsb_release -cs) main" | \
  sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt update && sudo apt install -y cloudflared

# Verificar
cloudflared --version
# cloudflared version 2024.x.x

Em macOS: brew install cloudflared. Em Windows: download do binário em github.com/cloudflare/cloudflared/releases.

Passo 3: autenticar na conta Cloudflare

cloudflared tunnel login
# Abre um URL no browser para autorizar
# Depois de autorizares, cria /home/utilizador/.cloudflared/cert.pem

Passo 4: criar o tunnel

cloudflared tunnel create kbase-tunnel
# Cria um tunnel com UUID e ficheiro de credencial em
# /home/utilizador/.cloudflared/<UUID>.json

# Listar túneis
cloudflared tunnel list

Passo 5: criar config.yml

# /home/utilizador/.cloudflared/config.yml
tunnel: <UUID-do-tunnel>
credentials-file: /home/utilizador/.cloudflared/<UUID>.json

ingress:
  # Nextcloud
  - hostname: cloud.meudominio.pt
    service: http://192.168.1.50:8080
  # SSH para o NAS
  - hostname: ssh.meudominio.pt
    service: ssh://192.168.1.50:22
  # Gitea
  - hostname: git.meudominio.pt
    service: http://192.168.1.51:3000
  # Catch-all (necessário como última regra)
  - service: http_status:404

Passo 6: criar DNS records automaticamente

cloudflared tunnel route dns kbase-tunnel cloud.meudominio.pt
cloudflared tunnel route dns kbase-tunnel ssh.meudominio.pt
cloudflared tunnel route dns kbase-tunnel git.meudominio.pt
# Cria CNAME cloud.meudominio.pt → <UUID>.cfargotunnel.com automaticamente

Passo 7: testar em modo foreground

cloudflared --config /home/utilizador/.cloudflared/config.yml tunnel run kbase-tunnel
# Vai mostrar logs em tempo real
# Testa: https://cloud.meudominio.pt no browser
# Ctrl+C para parar

Passo 8: instalar como serviço systemd

sudo cloudflared --config /home/utilizador/.cloudflared/config.yml service install
sudo systemctl enable cloudflared
sudo systemctl start cloudflared
sudo systemctl status cloudflared

# Logs
sudo journalctl -u cloudflared -f

Passo 9: configurar políticas de acesso (opcional)

No painel Cloudflare Zero Trust → Access → Applications, podes adicionar políticas para limitar quem pode aceder. Por exemplo:

  • Política “Permitir apenas emails @meudominio.pt” — só contas autorizadas.
  • Integração com Google/GitHub/Microsoft como IdP.
  • 2FA obrigatório (TOTP, WebAuthn).
  • Country restriction (ex: só Portugal).

Para serviços não-HTTP (SSH, RDP), o utilizador remoto tem de instalar cloudflared access tcp e configurar ProxyCommand em ~/.ssh/config:

# ~/.ssh/config no cliente
Host ssh.meudominio.pt
  ProxyCommand /usr/local/bin/cloudflared access tcp --hostname ssh.meudominio.pt %h %p
  User utilizador
  IdentityFile ~/.ssh/id_ed25519

Para VPN site-to-site com Azure usando IP fixo, o Cloudflare Tunnel não substitui IPSec — nesse caso, combina com o nosso guia Azure VPN Gateway Site-to-Site.

13. Erros comuns e soluções

Erro / Sintoma Causa provável Solução
Port forwarding não funciona, IP WAN começa por 100.64 CGNAT ativo Usa túnel (Cloudflare/Tailscale/WireGuard) ou pede IP público à MEO
WireGuard “handshake” não completa PersistentKeepalive em falta Adiciona PersistentKeepalive = 25 no peer
Cloudflare Tunnel: “tunnel not found” UUID errado no config.yml Verifica cloudflared tunnel list e copia exactamente o UUID
Tailscale: estado “idle”, sem handshakes Firewall bloqueia UDP 41641 Permite outbound UDP 41641; Tailscale usa DERP relay como fallback
Subnet routing Tailscale não funciona Routes não aprovadas no admin Em login.tailscale.com/admin/machines, clica no dispositivo e aprova a rota
IPv6 atribuído mas serviços não resolvem DNS sem suporte IPv6 (resolver usa só IPv4) Usa resolver dual-stack (1.1.1.1 + 2606:4700:4700::1111); configura /etc/resolv.conf com IPv6
DDNS Cloudflare actualiza mas serviço inacessível Registo “proxied” em vez de “DNS only” No Cloudflare, define o registo A como “DNS only” (proxy desactivado) para port forwarding
Stun/TURN falha em VoIP com CGNAT CGNAT simétrico bloqueia STUN Usa TURN relay (coturn) num VPS ou serviço VoIP com relay próprio
Gaming: NAT “Strict” em Xbox/PlayStation CGNAT impede UPnP efectivo UPnP no router não ajuda; soluções: IP fixo MEO ou IPv6 (algumas consolas suportam)
MEO diz “não temos CGNAT na sua zona” Primeira linha de apoio desconhece Insiste com detalhe técnico, mostra IP 100.64.x.x; pede para escalar a 2ª linha
Cloudflare Tunnel: 530 (origin DNS error) service aponta para hostname não resolvível Usa IP directo em service: em vez de hostname
Tunnel desconecta-se a cada X horas CGNAT fecha conexão idle Keepalive mais frequente; em WireGuard, baixar PersistentKeepalive para 15s

14. Checklist de implementação

Checklist final para resolver CGNAT na MEO de forma definitiva. Segue por ordem — cobre diagnóstico, decisão de solução e implementação.

Diagnóstico

  • ☐ Verificar IP público com curl -s ifconfig.me
  • ☐ Verificar IP WAN do router (192.168.1.1 → status WAN)
  • ☐ Confirmar: IP WAN começa por 100.64 → CGNAT confirmado
  • ☐ Verificar IPv6 disponível: ip -6 addr show | grep global
  • ☐ Testar traceroute: traceroute -n 1.1.1.1 — ver se primeiro salto é 100.64.x.x
  • ☐ Teste prático: servidor HTTP local + port forwarding → acesso externo falha → confirma CGNAT

Decidir solução

  • ☐ Definir caso de uso: acesso pessoal (NAS/SSH) vs. serviço público (web app acessível sem cliente)
  • ☐ Verificar orçamento: 0€/mês, 5-10€/mês, ou aceita custo baixo (4€/mês VPS)
  • ☐ Verificar se clientes remotos têm IPv6 (cada vez mais em 2026, mas não universal)
  • ☐ Avaliar requisitos de latência (gaming exige baixa; HTTP Nextcloud aceita +30 ms)
  • ☐ Considerar combinação: Tailscale (pessoal) + Cloudflare Tunnel (público)

Implementação (Cloudflare Tunnel)

  • ☐ Criar/transferir domínio para Cloudflare
  • ☐ Instalar cloudflared (Debian: repo Cloudflare; macOS: brew)
  • ☐ cloudflared tunnel login e autenticar
  • ☐ cloudflared tunnel create <nome>
  • ☐ Criar ~/.cloudflared/config.yml com ingress rules
  • ☐ cloudflared tunnel route dns para cada hostname
  • ☐ Testar em foreground: cloudflared tunnel run
  • ☐ Instalar como serviço: cloudflared service install
  • ☐ Configurar políticas de acesso (Zero Trust) se necessário
  • ☐ Configurar HTTPS no serviço local (Let’s Encrypt não é necessário — Cloudflare trata TLS no edge)

Implementação (Tailscale)

  • ☐ Criar conta em login.tailscale.com
  • ☐ Instalar em cada dispositivo (Linux/macOS/Windows/iOS/Android)
  • ☐ tailscale up em cada um
  • ☐ ativar subnet routing no servidor de casa
  • ☐ Aprovar subnet routes no admin Tailscale
  • ☐ Testar acesso a 192.168.1.50:8080 a partir de rede externa
  • ☐ ativar MagicDNS para resolução por hostname
  • ☐ Configurar ACLs se partilhares rede com família

Implementação (WireGuard + VPS)

  • ☐ Alugar VPS Hetzner/Contabo (registo, pagamento)
  • ☐ Hardening SSH (chaves, firewall ufw, fail2ban)
  • ☐ Instalar WireGuard no VPS e em casa
  • ☐ Gerar chaves com wg genkey / wg pubkey
  • ☐ Configurar wg0.conf com PersistentKeepalive = 25
  • ☐ ativar IP forwarding no VPS (sysctl net.ipv4.ip_forward=1)
  • ☐ Configurar DNAT/iptables ou nginx reverse proxy para portas públicas
  • ☐ Testar acesso a http://VPS_IP:porta → chega a casa
  • ☐ ativar systemd wg-quick@wg0
  • ☐ DDNS opcional: configurar A record a apontar para IP do VPS

Implementação (IPv6)

  • ☐ ativar IPv6 no router MEO (192.168.1.1 → IPv6 → enable)
  • ☐ Verificar prefixo /64 recebido no router
  • ☐ Confirmar dispositivos têm IPv6 global: ip -6 addr show
  • ☐ Configurar firewall IPv6 no router (ip6tables) para permitir portas necessárias
  • ☐ Adicionar registo AAAA no DNS (Cloudflare) apontando para IPv6 do servidor
  • ☐ Configurar DDNS IPv6 (dynv6.com ou Cloudflare API) — prefixo pode mudar
  • ☐ Testar acesso a partir de cliente externo com IPv6 (telemóvel em 4G geralmente tem)
  • ☐ Documentar que clientes sem IPv6 precisam de fallback IPv4 (Cloudflare Tunnel ou Tailscale)

Segurança geral

  • ☐ TLS em todos os serviços expostos (Let’s Encrypt ou Cloudflare SSL)
  • ☐ fail2ban para SSH e HTTP
  • ☐ ufw/iptables ativo, só portas necessárias abertas
  • ☐ 2FA em todos os serviços que suportem (Nextcloud, Gitea, Vaultwarden)
  • ☐ Backups automatizados do NAS

    • ☐ Monitorização: Uptime Kuma ou similar para alertas

  • ☐ Auditoria periódica de logs (Cloudflare dashboard, Tailscale admin, VPS sshd)

Conclusão: O CGNAT da MEO não é o fim do mundo — é uma infraestrutura inevitável dada a escassez de IPv4. Em 2026, com IPv6 cada vez mais universal e soluções gratuitas como Cloudflare Tunnel e Tailscale, contornar CGNAT é trivial. Para casos profissionais (VPN site-to-site, SLA), paga IP fixo (5-10€/mês). Para uso pessoal self-hosting, combina Tailscale (acesso pessoal) + Cloudflare Tunnel (serviços públicos) + IPv6 nativo (clientes com IPv6) e tens cobertura total sem custo adicional além do domínio (~10€/ano). Boa implementação.

Artigos relacionados

Para aprofundar configurações de firewall, VPN e routers compatíveis com estas soluções, consulta os guias complementares no kbase.pt:

Referências externas essenciais:

Artigo publicado em 2026-06-27 no kbase.pt. Conteúdo técnico sobre CGNAT na MEO e alternativas de acesso remoto para utilizadores em Portugal. Para questões, contacta-nos. Atualizado pela última vez: 27 de junho de 2026.

← Voltar ao Índice

Este artigo foi útil?

Duarte Spínola

Artigos  

Deixe um Comentário