Olá a todos
Conhecem (e se não conhecem já deviam conhecer) a minha maneira de pensar: Se é critico, então tem redundância. Até em produtos consumidos SaaS.
Todos temos aquela sensação de estarmos perfeitamente confortáveis com uma ferramenta, até que um dia nos dizem que o suporte vai acabar ou que o serviço vai mudar radicalmente – por exemplo começar a ser pago?
Pois…eu também já passei por isso (looking at you dyndns). E essas experiencias levam-me a escrever o post de hoje.
Quem depende do Cloudflared, o serviço da Cloudflare que facilita a exposição de aplicações e serviços privados na Internet, deve estar a par dos rumores e das incertezas sobre a sua continuidade – e que eu saiba são apenas rumores.
Mas não há que perder sono, porque como um grande professor meu diz, em linux/opensource há sempre alternativas.
Assim send, hoje vamos falar sobre o Rathole, uma ferramenta open-source que pode ser a tábua de salvação para lidar com CGNAT e a possível descontinuação do Cloudflared e não quiserem brincar muito com vpn’s e túneis por dentro de túneis.
O que é o Rathole e por que nos deve interessar?
O Rathole é um túnel reverso (reverse proxy) leve, rápido e seguro, desenhado para expor serviços locais à Internet sem a necessidade de mexer no router ou lidar com configurações complicadas. É especialmente útil para aqueles de nós que estão presos atrás de um CGNAT (Carrier-Grade NAT), aquela delicia tecnológica que os ISPs utilizam para partilhar um único endereço IP público entre múltiplos clientes (sim, estou a ser muito sarcástico).
Como muitos de vocês sabem, o CGNAT dificulta (ou mesmo impossibilita) a exposição direta de serviços locais, como um servidor web ou um sistema de automação residencial. Com o Rathole, é possível contornar essa barreira e ganhar mais controlo sobre os nossos próprios serviços, sem depender de soluções proprietárias como o Cloudflared.
Principais vantagens do Rathole
Antes de entrarmos nos detalhes técnicos, vale a pena destacar por que acho o Rathole uma alternativa interessante:
- Desempenho otimizado: O Rathole é escrito em Rust, uma linguagem conhecida pela sua eficiência e segurança. Isto significa que podemos esperar menos latência e melhor utilização de recursos em comparação com alternativas similares.
- Suporte para multiplex: Podemos usar um único túnel para múltiplos serviços, o que simplifica imenso a gestão.
- Configuração leve: Apesar de ser poderoso, o Rathole tem uma configuração simples e direta, mesmo para quem não é especialista.
- Código aberto: Transparência total. Podemos verificar o que a ferramenta faz e até contribuir para o projeto no GitHub. Isto quer dizer que teoricamente problemas de segurança ou bugs tem tendência a serem corrigidos mais rapidamente.Nota: o Rathole irá sempre necessitar de uma VPS entry-point. VPS extremamente baratas podem ser compradas em lowendbox ou caso aceitem sugestões, já sabem que sempre recomendo a ipdroid.pt.
Como funciona o Rathole?
Na sua essência, o Rathole funciona com dois componentes principais:
- Cliente: Este é o lado que corre no nosso dispositivo local, onde temos o serviço que queremos expor.
- Servidor: Corre num servidor remoto com um endereço IP público, atuando como intermediário entre os clientes na Internet e o serviço local.
Quando configuramos o Rathole, o cliente estabelece uma conexão persistente com o servidor remoto. Assim, quando alguém tenta aceder ao nosso serviço (como uma página web ou um servidor SSH), o servidor remoto redireciona o tráfego através do túnel para o cliente local.
Mas como é que isto nos ajuda a fugir ao CGNAT?
O truque aqui está na forma como o Rathole utiliza a conexão persistente. Mesmo que estejamos atrás de um CGNAT, o cliente Rathole consegue estabelecer e manter uma conexão com o servidor remoto. Essa ligação é iniciada do lado do cliente, contornando as restrições típicas de um CGNAT.
Uma vez estabelecida, essa conexão serve como um “canal aberto” para que o tráfego externo chegue ao serviço local. Assim, em vez de ficarmos limitados pelas configurações do ISP ou pelas capacidades do router, podemos expor os nossos serviços sem dores de cabeça.
Comparando Rathole com Cloudflared
Por esta altura, já estão a pensar: “Ok, mas como é que o Rathole se compara ao Cloudflared?” Não compara. Mas substitui e muito:
- Autonomia: O Rathole não depende de infraestruturas de terceiros como a Cloudflare. Podemos configurar o nosso próprio servidor, o que significa maior controlo e independência.
- Segurança: Embora o Cloudflared ofereça boas medidas de segurança, o Rathole utiliza TLS para encriptar as conexões, garantindo que os nossos dados estão protegidos.
- Custo: O Rathole é gratuito e open-source, enquanto serviços como o Cloudflared podem ter custos associados para funcionalidades avançadas.
- Flexibilidade: Com o Rathole, não estamos limitados aos serviços ou às políticas de uma empresa. Podemos personalizar a configuração para atender às nossas necessidades específicas.
Como começar com o Rathole
Agora que já estamos observamos as vantagens do Rathole, aqui está um guia rápido para dar os primeiros passos:
1. Instalar o Rathole
O Rathole está disponível no GitHub e pode ser facilmente descarregado e compilado. Para quem prefere um atalho, há binários pré-compilados disponíveis.
# Para sistemas baseados em Linux
wget https://github.com/rapiz1/rathole/releases/download/vX.Y.Z/rathole
chmod +x rathole
2. Configurar o servidor
No servidor remoto (aquele com IP público), criamos um ficheiro de configuração simples. Por exemplo:
[server]
bind_addr = "0.0.0.0:2333"
default_token = "um_token_seguro"
Este ficheiro indica ao Rathole para escutar conexões na porta 2333 e usar um token como chave de autenticação.
3. Configurar o cliente
No dispositivo local, criamos um ficheiro de configuração para o cliente:
[client]
remote_addr = "ip.do.servidor:2333"
default_token = "um_token_seguro"
[[client.services]]
local_addr = "127.0.0.1:8080"
remote_addr = "0.0.0.0:80"
Aqui estamos a dizer ao cliente para redirecionar o tráfego da porta 80 no servidor remoto para a porta 8080 no dispositivo local.
4. Executar e testar
Agora só precisamos de executar o Rathole tanto no servidor como no cliente:
No servidor:
./rathole -c server_config.toml
No cliente:
./rathole -c client_config.toml
E pronto! Se tiverem configurado tudo corretamente, o serviço local estará acessível através do endereço IP público do servidor remoto.
E chegamos ao fim de mais um post semanal. Desta vez com cariz técnico onde demonstramos que o Rathole é uma solução simples e eficaz – e dos testes que fiz bastante robusta – para quem precisa de contornar as limitações do CGNAT ou para quem quer estar preparado para o possível fim do Cloudflared.
Por ser open-source, é leve e altamente personalizável, o Rathole devolve-nos o controlo sobre os nossos próprios serviços e como tal recomendo-o.
Portanto, se alguma vez se sentirem encurralados pelas limitações do CGNAT ou pelas incertezas das ferramentas proprietárias, lembrem-se de que há sempre alternativas. O Rathole é uma delas. A internet foi desenhada para ser redundante e aberta. Que o nosso pensamento assim o seja também.
Até ao post da próxima semana e claro se descobrirem algo menos correcto sabem como me contactar.
1 abraço
Nuno