Por Como contornar CGNAT com túnel reverso em um VPS
Sem IP público por causa do CGNAT? Use frp em um VPS barato, conecte o servidor de casa por saída e termine HTTPS no VPS com certificado válido.
Por que o encaminhamento de portas não funciona atrás de CGNAT
Atrás de CGNAT (carrier-grade network address translation), o endereço WAN do seu router é partilhado com outros assinantes. Por isso, não tem um IP público atribuído exclusivamente a si e não existe uma porta que possa encaminhar. Um túnel reverso resolve esse problema: um VPS de baixo custo mantém o IP público, o seu servidor doméstico estabelece uma ligação de saída para o VPS e os pedidos de entrada regressam por essa ligação já aberta pelo servidor doméstico. Continua a utilizar o hardware que já possui. Aluga apenas o que o ISP não lhe fornece: um endereço encaminhável.
Cada comando abaixo indica a máquina onde deve ser executado. São necessárias duas máquinas: o VPS com um IP público e o servidor doméstico que executa o serviço que pretende aceder.
Como saber se está realmente atrás de CGNAT
Abra a página de administração do router e consulte o endereço WAN apresentado. Depois, pergunte à Internet qual é o endereço que ela vê.
# on the home box
curl -4 -s https://ifconfig.me; echoSe os dois endereços coincidirem, tem um IP público e não precisa de nada disto. Encaminhe a porta e pare de ler. Se o endereço WAN do router estiver dentro de 100.64.0.0/10, está atrás de CGNAT. Esse bloco é o espaço de endereços partilhados do RFC 6598, reservado precisamente para este fim. Alguns ISPs colocam 10.0.0.0/8 no lado WAN, o que corresponde à mesma situação com uma designação diferente.
Verifique uma coisa antes de alugar qualquer serviço. Muitos ISPs com CGNAT atribuem um prefixo IPv6 real e, se o seu equipamento doméstico tiver um endereço IPv6 global, pode abrir a firewall nesse endereço e evitar completamente o túnel. Isto deixa de funcionar quando um visitante está numa rede apenas IPv4, razão pela qual a maioria das pessoas acaba por chegar aqui.
Como funciona um túnel reverso de VPS, iniciado de dentro para fora
O CGNAT e os routers domésticos comuns bloqueiam ligações de entrada não solicitadas. As firewalls empresariais também. Nenhum deles bloqueia ligações de saída, porque é isso que todos os browsers e clientes de atualização fazem durante todo o dia. Quando um dispositivo NAT deteta uma ligação TCP de saída, cria um mapeamento para ela e permite o tráfego de retorno nessa ligação. Nada do exterior pode iniciar uma ligação para o seu servidor doméstico. Por isso, o servidor doméstico inicia a ligação, e o túnel transporta o tráfego de volta pela mesma ligação, na direção oposta.
Esse é todo o mecanismo. O servidor doméstico estabelece uma ligação de saída para o VPS numa porta e mantém essa ligação aberta. O VPS aceita os pedidos públicos e encaminha-os pela ligação existente. Nada tenta alcançar o seu endereço IP doméstico, por isso nada precisa de o fazer.
Daqui resultam duas consequências, e ambas são úteis. O seu registo DNS aponta para o VPS, nunca para a sua casa. E o seu endereço público passa a ser o endereço do VPS. Assim, qualquer observador que faça uma consulta IP obtém informações sobre um servidor alugado, e não sobre a sua ligação doméstica.
Três formas de fazer isto
ssh -R: já está instalado em ambas as extremidades e é adequado para um único serviço ou uma demonstração temporária. Não oferece dashboard nem uma lógica de reconexão que seja realmente útil.- frp: um servidor Go pequeno (
frps) e um cliente correspondente (frpc). É adequado para uma configuração permanente com vários serviços atrás de um único nome de host. Esta é a opção principal deste guia. - Uma VPN mesh: Tailscale ou um servidor WireGuard gerido por si. É adequada quando quer que os seus próprios dispositivos comuniquem entre si de forma privada, em vez de publicar algo na Internet pública.
Escolha a mesh se o objetivo for obter acesso privado a partir de dispositivos sob o seu controlo. Tailscale Serve e Funnel explica como publicar serviços fora de uma tailnet, e uma VPN WireGuard autoalojada no mesmo VPS oferece a mesma arquitetura sem um servidor de coordenação de terceiros no caminho. Leia uma dessas opções e ignore o resto desta página. Tudo abaixo pressupõe que quer um nome de host HTTPS público que qualquer pessoa possa abrir.
Versão rápida: ssh -R para um serviço
Suponha que o computador de casa execute uma aplicação em 127.0.0.1:3000 e que já tenha acesso SSH ao VPS.
# on the home box
ssh -N \
-o ExitOnForwardFailure=yes \
-o ServerAliveInterval=30 \
-o ServerAliveCountMax=3 \
-R 127.0.0.1:8080:127.0.0.1:3000 \
tunnel@vps.example.com-R 127.0.0.1:8080:127.0.0.1:3000 instrui o sshd do VPS a escutar na sua própria 127.0.0.1:8080 e a encaminhar tudo o que chegar nessa porta para 127.0.0.1:3000 no computador de casa. -N significa não iniciar um shell. As duas opções ServerAlive fazem o ssh detetar uma ligação interrompida em cerca de noventa segundos, em vez de ficar bloqueado numa ligação que já não existe.
Agora vem a parte que causa confusão. Esse listener está na interface de loopback, por isso curl http://vps.example.com:8080 a partir de qualquer outro local falha. O sshd vem com GatewayPorts no, o que significa que um encaminhamento remoto fica associado apenas à interface de loopback. Não corrija isto definindo GatewayPorts yes. Mantenha o encaminhamento na interface de loopback e coloque o nginx à sua frente, tal como na configuração com frp abaixo. Assim, a porta pública é 443 com um certificado, e a porta do túnel nunca fica exposta à Internet. Se não souber o que está atualmente a escutar nem em que interface, um breve guia sobre portas e listeners no Linux vale dez minutos.
Se a porta já estiver ocupada no VPS, o ssh apresenta esta mensagem, e ExitOnForwardFailure=yes faz com que desista em vez de estabelecer uma ligação sem um túnel funcional:
Warning: remote port forwarding failed for listen port 8080A causa habitual é uma sessão anterior que terminou sem que o sshd detetasse o problema. Defina ClientAliveInterval 30 e ClientAliveCountMax 3 no /etc/ssh/sshd_config do VPS para que as sessões interrompidas sejam removidas e libertem a porta. Coloque o comando completo numa unidade systemd com Restart=always e uma chave dedicada, ou use autossh. Para qualquer configuração com mais de um serviço, pare aqui e use frp.
Instalar o frp no VPS, fixado numa tag
O frp é distribuído como um binário Go estático e não está disponível nos repositórios do Ubuntu ou Debian. Por isso, deve descarregar uma release e verificá-la manualmente. Fixe a versão. O formato de configuração mudou na v0.52.0 e os nomes das opções também foram alterados desde então. Um tutorial desatualizado pode fornecer chaves que o seu binário não reconhece. Este guia usa a versão v0.71.0, publicada em 14 August 2026.
# on the VPS
FRP_VERSION=0.71.0
ARCH=amd64 # use arm64 if `uname -m` prints aarch64
cd /tmp
curl -fsSLO "https://github.com/fatedier/frp/releases/download/v${FRP_VERSION}/frp_${FRP_VERSION}_linux_${ARCH}.tar.gz"
curl -fsSLO "https://github.com/fatedier/frp/releases/download/v${FRP_VERSION}/frp_sha256_checksums.txt"
sha256sum --check --ignore-missing frp_sha256_checksums.txtsha256sum deve apresentar exatamente uma linha:
frp_0.71.0_linux_amd64.tar.gz: OK--ignore-missing é necessário porque o ficheiro de checksum inclui todos os dezoito artefactos da release e só descarregou um deles. Sem essa flag, sha256sum indica os outros dezassete como ausentes e termina com um código diferente de zero. Isto parece uma falha de verificação, embora não exista nenhum problema.
# on the VPS
tar xzf "frp_${FRP_VERSION}_linux_${ARCH}.tar.gz"
sudo install -m 755 "frp_${FRP_VERSION}_linux_${ARCH}/frps" /usr/local/bin/frps
sudo useradd --system --no-create-home --shell /usr/sbin/nologin frp
sudo install -d -m 750 -o root -g frp /etc/frp
frps --versionfrps --version apresenta 0.71.0. Apenas frps é instalado no VPS. frpc é instalado no computador de casa. Instalar os dois binários em todos os sistemas é uma forma comum de acabar a executar acidentalmente um servidor de túnel em casa.
A configuração do VPS: token, TLS obrigatório, listeners de loopback
Gere primeiro um token. É a única proteção entre o seu túnel e qualquer pessoa que faça uma varredura de portas no VPS.
# on the VPS
openssl rand -base64 32Escreva esse valor em /etc/frp/frps.toml:
bindAddr = "0.0.0.0"
bindPort = 7000
# Every listener frp creates for a proxy, including the HTTP vhost, stays on loopback.
proxyBindAddr = "127.0.0.1"
vhostHTTPPort = 8080
auth.method = "token"
auth.token = "PASTE_THE_OPENSSL_OUTPUT_HERE"
transport.tls.force = true
webServer.addr = "127.0.0.1"
webServer.port = 7500
webServer.user = "admin"
webServer.password = "PASTE_A_SECOND_SECRET_HERE"
log.level = "info"Quatro dessas linhas fazem o trabalho de segurança. Analise-as uma de cada vez.
auth.token tem de corresponder a auth.token no cliente. Sem essa correspondência, frps aceita qualquer cliente que encontre a porta 7000. Esse cliente pode então publicar o que quiser através do seu VPS e do seu certificado.
transport.tls.force = true rejeita qualquer ligação de controlo que não use TLS (transport layer security). Os clientes ativam o TLS por predefinição desde a v0.50.0. Na prática, isto não tem custo e elimina o caso em que um cliente antigo ou criado manualmente se liga sem encriptação e sem o informar.
proxyBindAddr = "127.0.0.1" é a linha que a maioria dos guias omite. É também o motivo pelo qual esta configuração pode permanecer ativa com segurança. Ela move todos os listeners que o frp abre em nome de um proxy, tanto o vhost HTTP como qualquer remotePort solicitado por um cliente, para a interface de loopback. A Internet não consegue alcançar esses listeners. A única porta pública é o nginx na porta 443, que você configura e controla.
webServer.addr = "127.0.0.1" mantém o dashboard fora da interface pública. O dashboard apresenta um mapa completo dos seus serviços privados e do respetivo tráfego. Ele é protegido por uma única palavra-passe de autenticação básica HTTP, por isso não deve ficar em 0.0.0.0.
Defina o proprietário para que o token não possa ser lido por outros utilizadores. Depois, verifique a sintaxe antes de iniciar qualquer serviço:
# on the VPS
sudo chown root:frp /etc/frp/frps.toml
sudo chmod 640 /etc/frp/frps.toml
sudo -u frp frps verify -c /etc/frp/frps.tomlUm ficheiro válido apresenta:
frps: the configuration file /etc/frp/frps.toml syntax is okUma nota sobre o formato pode poupar-lhe uma hora. O frp escolhe o parser com base na extensão do ficheiro e reconhece .toml, .yaml, .yml e .json. Os ficheiros .ini antigos continuam a ser carregados através de um processo de conversão legado, mas INI está obsoleto e as novas opções só estão documentadas para TOML. Se um tutorial mostrar uma secção [common] e server_addr = x.x.x.x, é anterior à v0.52.0 e os nomes das chaves não correspondem aos do binário que acabou de instalar.
Execute o frps como um serviço sem privilégios
bindPort é 7000 e vhostHTTPPort é 8080. Ambas estão acima de 1024, portanto o frps nunca precisa de root nem de CAP_NET_BIND_SERVICE. Esse é o motivo para não colocar o vhost na porta 80 e deixar o nginx assumir essa porta.
Escreva /etc/systemd/system/frps.service:
[Unit]
Description=frp reverse tunnel server
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=frp
Group=frp
ExecStart=/usr/local/bin/frps -c /etc/frp/frps.toml
Restart=on-failure
RestartSec=5s
LimitNOFILE=65535
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ProtectKernelTunables=true
[Install]
WantedBy=multi-user.target# on the VPS
sudo systemctl daemon-reload
sudo systemctl enable --now frps
sudo journalctl -u frps -n 20 --no-pagerO log deve mostrar os dois listeners, e os endereços são mais importantes do que as portas:
frps tcp listen on 0.0.0.0:7000
http service listen on 127.0.0.1:8080ProtectSystem=strict torna todo o sistema de ficheiros somente de leitura para este serviço. O frps tolera isso porque, por padrão, envia o log para a saída padrão, e o journald captura essa saída. Se definir log.to como um caminho de ficheiro, o serviço não conseguirá escrever nesse ficheiro até adicionar uma linha ReadWritePaths= correspondente. Por isso, mantenha o valor predefinido.
Firewall: abra uma porta, não um intervalo
# on the VPS
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 7000/tcp
sudo ufw enable
sudo ufw status numberedSão quatro regras, e uma delas existe apenas para a renovação do certificado. A porta 22 é usada pelo SSH. A porta 80 redireciona para a 443 e responde ao desafio ACME (ambiente de gestão automática de certificados). A porta 443 serve todas as aplicações em túnel. A porta 7000 é a porta de controlo do frp e é a única porta que um cliente precisa de conseguir alcançar.
Os guias que dizem para abrir um intervalo como sudo ufw allow 20000:30000/tcp descrevem a outra arquitetura, em que cada serviço utiliza a sua própria porta TCP pública. Não precisa disso neste caso, porque tudo chega à porta 443 e o frp encaminha o tráfego pelo nome do host. Se mais tarde precisar de uma porta TCP realmente pública, volte a colocar proxyBindAddr em 0.0.0.0 e adicione limites para que um cliente só possa utilizar as portas que indicou:
allowPorts = [
{ start = 20000, end = 20010 }
]
maxPortsPerClient = 5A maioria dos fornecedores também executa uma firewall de rede no painel de controlo, separada do ufw no servidor. Uma regra que parece correta em sudo ufw status mas continua a atingir o tempo limite está normalmente bloqueada nessa firewall. As regras do ufw de que um VPS realmente precisa explica a configuração de negação por predefinição assumida nesta secção.
Terminar HTTPS na VPS com um certificado válido
Aponte um registo A de home.example.com para o IP público da VPS. Não para a sua rede doméstica. A sua rede doméstica não tem um endereço para onde apontar, que é precisamente o problema que está a resolver.
# on the VPS
sudo apt update
sudo apt install -y nginx certbot python3-certbot-nginxCrie /etc/nginx/sites-available/home.example.com primeiro com um bloco simples para a porta 80, para que o certbot tenha um server_name correspondente:
server {
listen 80;
listen [::]:80;
server_name home.example.com;
location / { return 404; }
}# on the VPS
sudo ln -s /etc/nginx/sites-available/home.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
sudo certbot certonly --nginx -d home.example.comnginx -t apresenta nginx: configuration file /etc/nginx/nginx.conf test is successful quando os ficheiros são analisados. Execute-o antes de cada reload. O nginx mantém a configuração antiga em execução quando um reload falha. Por isso, uma alteração inválida parece uma alteração que não teve efeito.
As atualizações de WebSocket precisam de um map ao nível de http. Coloque-o em /etc/nginx/conf.d/upgrade.conf:
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}Agora substitua o ficheiro do site pelo ficheiro definitivo:
server {
listen 80;
listen [::]:80;
server_name home.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name home.example.com;
ssl_certificate /etc/letsencrypt/live/home.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/home.example.com/privkey.pem;
client_max_body_size 512m;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_read_timeout 3600s;
}
}proxy_set_header Host $host; é obrigatório neste caso. O vhost HTTP do frp encaminha os pedidos com base no cabeçalho Host, comparando-o com a lista customDomains na configuração do cliente. Se esse cabeçalho faltar, o nginx envia Host: 127.0.0.1, o frp não encontra um proxy para esse nome e o visitante recebe um 404 simples do frp em vez da página da aplicação. Explicação de cada linha de um bloco de reverse proxy do nginx descreve a função dos outros cabeçalhos.
# on the VPS
sudo nginx -t && sudo systemctl reload nginx
sudo certbot renew --dry-runO teste sem alterações confirma que a renovação funcionará daqui a noventa dias, quando não estará a monitorizar o sistema. Precisa de ter a porta 80 acessível. É por isso que essa regra do ufw existe.
O lado doméstico: frpc como serviço sem privilégios
Instale frpc no equipamento doméstico exatamente como instalou frps, com a mesma versão e o mesmo passo de verificação do checksum. Em seguida, crie o mesmo utilizador frp e o diretório /etc/frp. Escreva /etc/frp/frpc.toml:
serverAddr = "vps.example.com"
serverPort = 7000
auth.method = "token"
auth.token = "PASTE_THE_SAME_TOKEN_HERE"
transport.tls.enable = true
loginFailExit = false
proxies = [
{ name = "home-app", type = "http", localIP = "127.0.0.1", localPort = 3000, customDomains = ["home.example.com"] }
]A ordem das chaves é importante neste ficheiro, e não por razões de estilo. O TOML atribui todas as chaves que aparecem depois de um cabeçalho de tabela a essa tabela. Por isso, uma definição de nível superior como serverAddr, escrita abaixo do cabeçalho de uma tabela de proxy, passa silenciosamente a ser uma definição do proxy que o frp ignora. Escrever a lista de proxies como uma matriz inline, como aparece acima, evita este problema: todas as chaves de nível superior permanecem inequivocamente nesse nível.
type = "http" encaminha este proxy através do listener vhost, em vez de reservar a sua própria porta TCP pública. É por isso que a firewall ficou com quatro regras. customDomains tem de conter o hostname que o nginx encaminha no cabeçalho Host. Por isso, é home.example.com e nunca o endereço IP do VPS.
loginFailExit = false é mais importante do que parece. O valor predefinido é true, que faz o frpc terminar se a primeira tentativa de login falhar. Num equipamento doméstico que termina o arranque antes de a ligação do ISP estar disponível, isso deixa o serviço parado até alguém reparar no problema. Defina-o como false para que o frpc continue a tentar até o VPS responder.
Escreva /etc/systemd/system/frpc.service:
[Unit]
Description=frp reverse tunnel client
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=frp
Group=frp
ExecStart=/usr/local/bin/frpc -c /etc/frp/frpc.toml
Restart=always
RestartSec=10s
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
[Install]
WantedBy=multi-user.target# on the home box
sudo chown root:frp /etc/frp/frpc.toml
sudo chmod 640 /etc/frp/frpc.toml
sudo -u frp frpc verify -c /etc/frp/frpc.toml
sudo systemctl daemon-reload
sudo systemctl enable --now frpc
sudo journalctl -u frpc -n 20 --no-pagerUm cliente que estabeleceu ligação regista um ID de execução:
login to server success, get run id [3a1f9c2b7d4e5f60]Abra https://home.example.com num browser. Deverá obter a aplicação que está em 127.0.0.1:3000 em casa. Restart=always no cliente é intencional: as ligações domésticas podem cair, e o serviço deve voltar a funcionar sem intervenção manual.
Mantenha o dashboard fora da interface pública
Com webServer.addr = "127.0.0.1", o dashboard responde apenas no próprio VPS. Aceda a partir do seu portátil através de um encaminhamento local, em vez de abrir uma porta:
# on your laptop
ssh -N -L 7500:127.0.0.1:7500 you@vps.example.comAbra http://127.0.0.1:7500 e inicie sessão com webServer.user e webServer.password de frps.toml. A página lista todos os clientes ligados e os contadores de tráfego de cada proxy. Esta é a forma mais rápida de confirmar se o equipamento doméstico está ligado neste momento. Feche a sessão SSH e o dashboard volta a ficar inacessível.
O que o túnel não faz
Leia esta parte duas vezes, porque é onde surgem os problemas mais graves. O túnel torna um serviço privado acessível a partir da Internet pública. Ele não autentica as pessoas que acedem ao serviço. Depois de https://home.example.com resolver, os scanners vão encontrá-lo em poucos dias, independentemente de ter informado alguém sobre o nome. Os logs de transparência de certificados publicam cada hostname para o qual emite um certificado. Por isso, o nome torna-se público assim que o certbot termina com sucesso.
Tudo o que expuser tem de fornecer a sua própria autenticação. Se a aplicação tiver um login real com limitação de pedidos, melhor. Se o login usar uma única palavra-passe partilhada, ou se não existir qualquer login, coloque um proxy de autenticação à frente da aplicação no VPS. Um oauth2-proxy à frente da aplicação é a opção habitual. Ele fica entre o nginx e o vhost do frp, sem alterar nenhuma das extremidades do túnel.
O token em frps.toml protege o túnel, não as aplicações. Impede que um estranho registe o seu próprio proxy no VPS. Não faz nada em relação a um pedido que chegue à porta 443 para um hostname que publicou de propósito.
Vale a pena manter dois hábitos. Rode o token editando os dois ficheiros e reiniciando os dois serviços, porque ele não expira sozinho. Mantenha também o frp atualizado: este binário é a porta de entrada pública do servidor, e as notas da v0.71.0 listam um panic no servidor acionado por um valor inválido enviado por um cliente. Esse é o tipo de erro que deve corrigir com uma atualização, em vez de tentar analisar manualmente.
Modos de falha e as mensagens apresentadas
O cliente nunca estabelece ligação. journalctl -u frpc repete connect to server error: e, depois, ocorre um timeout de ligação. Nada está a chegar à porta 7000. Verifique o ufw na VPS, depois a firewall de rede do fornecedor no painel de controlo e, por fim, confirme que o nome é resolvido com getent hosts vps.example.com.
O token está incorreto. O cliente indica isso explicitamente:
login to the server failed: token in login doesn't match token from configurationCopie novamente o token. Uma nova linha no fim ou um $ numa string de shell sem aspas, que foi expandido para nada, causa quase todos estes casos. Por isso, a saída de openssl rand -base64 32 deve ficar entre aspas no ficheiro TOML.
O túnel está ativo, mas o browser recebe um 404 simples. O frpc registou um início de sessão bem-sucedido e o dashboard apresenta o proxy, mas a página devolve 404 sem qualquer estilo da aplicação. Isto significa que o frp não tem nenhum proxy para este cabeçalho Host. Teste o vhost diretamente na VPS, ignorando o nginx e o TLS:
# on the VPS
curl -s -o /dev/null -w '%{http_code}\n' -H 'Host: home.example.com' http://127.0.0.1:8080/Um 404 desse comando significa que customDomains está incorreto. Qualquer outro código significa que o pedido não recebeu o Host correto do nginx.
502 do nginx. O nginx está a responder e o frp não. sudo ss -lntp | grep 8080 na VPS deve mostrar o frps a escutar em 127.0.0.1:8080. Uma saída vazia significa que o frps está parado ou que vhostHTTPPort não está definido em frps.toml.
A aplicação considera todos os visitantes locais. Os logs da aplicação mostram 127.0.0.1 em todos os pedidos. O frp define X-Forwarded-For e o nginx acrescenta o seu valor, por isso o endereço real do cliente está nesse cabeçalho. Configure a aplicação para confiar nele. Não ignore este passo se a aplicação limitar a taxa por endereço IP, porque, neste momento, todos os visitantes da Internet partilham o mesmo limite.
Os pedidos longos são interrompidos após 60 segundos. Os uploads ou as respostas em streaming param a meio. Esse é o valor predefinido de proxy_read_timeout do nginx, não um problema do túnel. O bloco acima aumenta-o para 3600s. client_max_body_size é o limite correspondente ao tamanho do upload e o seu valor predefinido de 1 MB rejeita corpos maiores com um 413.
Tudo funciona, mas deixa de funcionar depois de um reboot do router. Restart=always na unidade frpc, juntamente com loginFailExit = false, resolve este caso. Confirme com sudo systemctl is-enabled frpc, que deve apresentar enabled.
FAQ
Como sei se estou atrás de CGNAT?
Compare o endereço WAN na página de administração do router com o que curl -4 -s https://ifconfig.me apresenta dentro da mesma rede. Se forem diferentes e o endereço WAN do router estiver dentro de 100.64.0.0/10, o seu ISP está a usar NAT de operadora. Esse intervalo é um espaço de endereços partilhado definido pela RFC 6598 e existe para este fim. Alguns ISP usam 10.0.0.0/8 no lado WAN, o que significa o mesmo. Se os dois endereços coincidirem, tem um IP público: encaminhe a porta e terminou.
Preciso de um nome de domínio para um túnel reverso?
Para a configuração HTTPS descrita aqui, sim. Um certificado é emitido para um nome de host, e o vhost HTTP do frp encaminha os pedidos com base no cabeçalho Host. Por isso, ambas as extremidades precisam de concordar num nome. Um proxy TCP simples numa porta numerada funciona com o IP direto do VPS, sem qualquer domínio, mas nesse caso não tem certificado nem encaminhamento por nome de host. Uma porta pública serve exatamente um serviço.
É seguro executar o frp num VPS público?
É seguro quando a porta de controlo é a única exposta e está autenticada. Defina auth.token com um valor aleatório em ambas as extremidades e configure transport.tls.force = true no servidor. Depois, defina proxyBindAddr = "127.0.0.1" para que nada que o frp abra para um proxy fique exposto à Internet. Mantenha o dashboard em webServer.addr = "127.0.0.1" e aceda a ele através de um encaminhamento local SSH. Atualize o binário quando forem lançadas novas versões, porque é o processo que está a escutar no seu endereço público.
Porque é que ninguém consegue aceder à minha porta encaminhada ssh -R?
O sshd é fornecido com GatewayPorts no, por isso um encaminhamento remoto fica ligado apenas à interface de loopback do VPS. curl executado no próprio VPS funciona, mas curl executado a partir de qualquer outro local excede o tempo limite. A correção adequada é manter o encaminhamento em loopback e colocar o nginx na porta 443 à sua frente. Definir GatewayPorts yes publica uma porta simples sem certificado e sem TLS, o que é pior do que o problema que resolve.
Devo usar frp ou uma VPN de malha, como Tailscale ou WireGuard?
Use uma VPN de malha quando apenas os seus próprios dispositivos precisam de acesso, porque assim nada fica publicado e não existe um nome de host público que alguém possa analisar. Use frp quando precisar de um endereço HTTPS público que qualquer browser possa abrir, como um recetor de webhooks ou uma página que queira partilhar com pessoas que não vão instalar um cliente VPN. As duas soluções funcionam em conjunto no mesmo VPS, em portas diferentes e com funções diferentes.