O Cloudflare Tunnel como alternativa à abertura de portas

O Cloudflare Tunnel explicado sem a necessidade de abrir portas

Numa abertura de porta clássica, um cliente externo liga-se diretamente ao endereço IP público do router ou do servidor. O router reencaminha, em seguida, o tráfego de entrada para um serviço na rede interna. Um Cloudflare Tunnel inverte este processo de estabelecimento da ligação: o Connector cloudflared funciona na rede interna acessível e estabelece, por si próprio, ligações de saída para a Cloudflare.

Se um utilizador aceder, por exemplo, a um portal de administração, a Cloudflare recebe o pedido relativo ao nome de host desse portal e reencaminha-o para o conector através de uma ligação em túnel já existente. Este chega ao serviço de destino configurado, por exemplo http://localhost:8080. Por isso, o Origin não necessita nem de um endereço IP acessível diretamente a partir da Internet, nem de uma autorização de entrada na firewall para este serviço.

Isso não significa que as regras de rede deixem de se aplicar. O anfitrião com cloudflared A Cloudflare tem de poder aceder ao exterior. A Cloudflare especifica para este efeito a porta 7844 via TCP ou UDP; neste contexto, são utilizados os protocolos HTTP/2 e QUIC, respetivamente. O tráfego de saída tem de ser permitido na firewall local, no router e, se for caso disso, através de um proxy da empresa. Esta é a limitação prática subjacente à afirmação „sem abertura de portas“.

Uma entrada DNS, por si só, não cria este canal de ligação protegido. O DNS apenas associa um nome a um endereço de destino; não inicia qualquer ligação a partir da rede privada nem fornece qualquer serviço local. O Conector de saída é o componente decisivo: conhece o serviço de destino interno e mantém aberto o caminho até lá, de dentro para fora. A configuração dos utilizadores autorizados a utilizar esse caminho deve ser feita separadamente.

O túnel não constitui uma proteção de acesso

Um túnel reduz a visibilidade direta da rede de origem, mas não decide autonomamente sobre as autorizações. Se um painel de administração web for encaminhado através de um nome de host público, poderá, em princípio, ser acedido por qualquer utilizador da Internet sem uma aplicação Access a montante. Por isso, a Cloudflare recomenda configurar o Access antes da rota do túnel em produção. O túnel é a via de transporte, não o controlo de acesso.

Para um painel de administração com privilégios, deve ser criada uma Política de Acesso Permitir apenas pessoas ou grupos claramente definidos. Para além dos critérios «Include», «Require» e «Exclude», estão disponíveis ações como «Allow», «Block», «Bypass» e «Service Auth». A autenticação multifator (MFA) pode ser imposta através de um fornecedor de identidade integrado ou como fator adicional. Uma regra genérica para todas as contas de um domínio de e-mail é, na maioria das vezes, demasiado abrangente para interfaces com privilégios elevados.

A camada de acesso complementa, mas não substitui a fortificação da aplicação. O painel de administração continua a exigir um início de sessão seguro, atualizações atempadas, regras de sessão adequadas e uma atribuição parcimoniosa de direitos. As contas de utilizador locais, as funções e os direitos de administração também continuam a ser fundamentais: se um utilizador obtiver acesso à aplicação após o início de sessão no Access, essa pessoa não deve receber automaticamente direitos administrativos mais amplos nessa aplicação.

Além disso, é necessário verificar se a aplicação valida os tokens de acesso ou se utiliza a opção de túnel prevista para a verificação de tokens. Isto vincula a aplicação à verificação de identidade a montante e reduz os riscos decorrentes de uma via de acesso alternativa e involuntária ao Origin. Recomenda-se uma abordagem em camadas: publicação restritiva, verificação de identidade com MFA, direitos mínimos de acesso à aplicação e um serviço de destino acessível internamente, mas não exposto ao público em geral.

Classificar HTTP, SSH, RDP e TCP

As aplicações HTTP(S) e os protocolos de administração têm modelos de acesso diferentes. Uma interface Web interna pode ser publicada através de um nome de anfitrião e protegida com o Access perante o Origin. O SSH, o RDP e determinados serviços TCP também podem ser acedidos através de túneis, mas, dependendo do método utilizado, requerem software adicional do lado do cliente ou um acesso baseado no navegador. O facto de a autenticação ser feita através da Web não significa automaticamente que se trate de um acesso de rede nativo genérico.

Para o SSH com o terminal local habitual, é possível utilizar, do lado do cliente, cloudflared Estabelecer a ligação em conjunto com o Access. Além disso, a Cloudflare documenta o SSH renderizado pelo navegador como uma via de acesso específica. Ambas as variantes diferem no que diz respeito ao fluxo de trabalho do cliente, à configuração local do SSH e ao funcionamento; por isso, não são intercambiáveis de forma generalizada. As referências a modelos de infraestrutura ou de certificados mais abrangentes só devem ser incluídas num plano de implementação se a documentação atual e pertinente tiver sido verificada separadamente.

Um terminal SSH renderizado pelo navegador pode ser útil para assistência técnica ou para um acesso de emergência urgente, caso não esteja disponível um cliente SSH local. No entanto, antes da sua utilização, é necessário avaliar os requisitos de auditoria, os procedimentos operacionais, os métodos de chaves locais e as transferências de ficheiros. O RDP e outros serviços TCP devem igualmente ser analisados caso a caso, em vez de serem tratados de forma generalizada como uma interface web.

O Tunnel não é um substituto completo para todas as ligações de rede. Os protocolos iniciados pelo servidor, como o VoIP ou o SIP, não são suportados; também as sessões TCP de longa duração e sensíveis a interrupções exigem uma verificação de compatibilidade. Além disso, no caso do SSH, RDP e TCP, o Origin não vê o endereço IP original do cliente, mas sim o conector. No caso do HTTP, uma aplicação pode CF-Connecting-IP avaliar. As listas de autorização baseadas em IP e os registos forenses têm de ter em conta este limite.

Atribuir vários serviços de forma segura

Um ficheiro Ingress local associa cada nome de anfitrião publicado a um único destino interno. Para um painel de administração e o SSH, faz sentido utilizar nomes distintos: desta forma, as autorizações, os registos e as alterações posteriores permanecem claramente separados uns dos outros. O cloudflared avalia as regras de cima para baixo; a primeira regra que corresponder determina o destino.

O exemplo seguinte é um modelo de configuração para um túnel gerido localmente. Utiliza deliberadamente example.invalid e não contém nem dados de acesso nem um domínio real. O serviço web permanece em localhost:8080 acessível; o SSH é reencaminhado para o serviço SSH local.

tunnel: <TUNNEL-UUID>
credentials-file: /etc/cloudflared/<TUNNEL-UUID>.json

ingress:
  - hostname: admin.example.invalid
    service: http://localhost:8080
  - hostname: ssh.example.invalid
    service: ssh://localhost:22
  - service: http_status:404

A última regra é a seguinte: Regra de abrangência geral. É necessária para os ficheiros Ingress locais e, neste contexto, assegura que http_status:404 para garantir que um nome de anfitrião desconhecido não seja encaminhado acidentalmente para o primeiro serviço ou para qualquer outro serviço interno. Um reencaminhamento padrão abrangente representaria um risco desnecessário, especialmente no caso de destinos administrativos.

O ficheiro define exclusivamente o caminho do túnel até ao Origin. Não configura registos DNS nem protege os nomes através do Cloudflare Access. Por isso, antes de estabelecer uma rota em produção, é necessário configurar separadamente o nome do anfitrião e a política de acesso. Também a nível local, as portas de destino só devem estar acessíveis nos locais onde o cloudflared realmente as necessita.

Antes de iniciar, é possível verificar a ordem sem alterar as definições. O primeiro comando valida a configuração do Ingress; o segundo mostra qual a regra que se aplicaria ao endereço indicado.

cloudflared tunnel ingress validate
cloudflared tunnel ingress rule https://admin.example.invalid

Selecionar acessos SSH de forma seletiva

O SSH através de um túnel não é uma via de acesso única. A variante adequada depende do facto de os administradores continuarem a utilizar o seu terminal local ou de, em caso de avaria, terem de trabalhar sem um cliente pré-configurado. Os modelos disponíveis diferem no que diz respeito ao cliente, à identidade e ao fluxo de operações; a configuração concreta do SSHD e a gestão de direitos locais permanecem independentes disso.

Para uma equipa pequena que trabalha regularmente com ferramentas locais conhecidas, o Cloudflare no lado do cliente costuma ser adequado: a porta SSH permanece interna, enquanto o Access estabelece uma camada adicional de identificação antes do estabelecimento da ligação. No entanto, isto não é o mesmo que uma gestão centralizada de todas as autorizações SSH.

O acesso através do navegador deve ser considerado um processo independente. Pode ser útil em situações de suporte técnico ou de acesso não planeado, uma vez que não requer a configuração de um cliente SSH. No entanto, não se trata de um método de administração universalmente superior: as transferências de ficheiros, os fluxos de chaves locais habituais e os requisitos de auditoria podem tornar um cliente de terminal ou um acesso privado mais adequados.

Independentemente do caminho, as camadas de proteção locais permanecem. Contas Linux, Regras do sudo, a configuração do SSHD e os direitos no sistema de destino continuam a determinar o que uma pessoa que tenha iniciado sessão com sucesso pode fazer. O túnel não substitui estas regras nem a atribuição limitada de direitos.

No caso de serviços não-HTTP publicados, pode ser necessário utilizar o cloudflared do lado do cliente; o SSH oferece, além disso, acesso renderizado pelo navegador. O RDP e outros serviços TCP não devem, por isso, ser planeados precipitadamente seguindo o modelo do SSH, mas sim de acordo com os respetivos requisitos de cliente e de funcionamento.

Túnel, VPN, bastião ou abertura de portas

A escolha não se resume apenas à questão de saber se uma porta está aberta, mas também ao âmbito de acesso pretendido. O Cloudflare Tunnel é especialmente adequado para um número reduzido de serviços claramente definidos. Por outro lado, quem precisa de aceder a muitos sistemas internos e segmentos de rede necessita, na maioria das vezes, de um modelo de acesso à rede privada, em vez de um conjunto de publicações individuais.

A abertura clássica de portas não é, por si só, errada. Pode ser adequada para um serviço público deliberadamente aberto, cuja proteção de aplicações, funcionamento da firewall e acessibilidade pública sejam geridos de forma específica. Em contrapartida, no túnel, o conector estabelece a ligação a partir da rede interna; não é necessário aceder diretamente à origem a partir da Internet.

Para um único painel de administração ou um pequeno conjunto de alvos de manutenção, uma publicação baseada em serviço com acesso baseado na identidade geralmente mais fáceis de delimitar do que um túnel de rede abrangente. Isso não dispensa a verificação do protocolo: os protocolos iniciados pelo servidor não são suportados e as sessões TCP longas e sensíveis a interrupções podem exigir outros modelos de conectividade.

Uma VPN continua a fazer sentido quando os colaboradores necessitam de várias aplicações privadas, intervalos de endereços ou dependências internas. Um Bastion Host, por outro lado, concentra os acessos SSH num único ponto de entrada, que, por sua vez, deve ser cuidadosamente fortificado e gerido. Um proxy reverso, por sua vez, é uma camada destinada à terminação TLS e à disponibilização de aplicações; por si só, não responde à questão de como aceder à origem privada. As funções de proxy, servidor de aplicações e gestor de processos também podem ser desempenhadas no Comparação entre o NGINX Unit e o PHP-FPM entender.

A decisão prática começa, portanto, com uma delimitação: que pessoas precisam de acesso a que serviço e com que cliente? Quanto mais restrita for esta resposta, mais fácil será operar um túnel com nomes de anfitrião e regras precisas. Necessidades de rede abrangentes, protocolos especiais ou elevados requisitos de estabilidade da sessão justificam, por outro lado, uma avaliação separada.

Garantir a segurança dos túneis durante o funcionamento

Um túnel ativo não consiste numa única ligação pontual. A Cloudflare documenta, para cada túnel «cloudflared», quatro ligações de saída de longa duração a, pelo menos, dois dos seus próprios centros de dados. Assim, se um único caminho de ligação falhar, os pedidos podem ser encaminhados através de outro caminho existente. Isto reduz as dependências no percurso entre o Connector e a Cloudflare, mas não torna o próprio serviço interno altamente disponível.

Para aplicações críticas, várias instâncias do cloudflared podem utilizar o mesmo túnel como réplicas. Isto cria percursos adicionais da rede da Cloudflare para a rede privada, mas não substitui nem uma aplicação redundante nem uma estratégia de base de dados ou de alojamento. Se, por exemplo, o único servidor com o painel de administração estiver inacessível, outros conectores neste ou noutros servidores só serão úteis se conseguirem efetivamente aceder ao serviço de destino que esteja a funcionar. Percurso de ligação Por isso, a disponibilidade de pessoal e a disponibilidade do serviço devem ser planeadas separadamente.

Se for necessário verificar várias origens de forma seletiva, contorná-las em caso de falhas ou distribuí-las de acordo com regras, é necessário um equilíbrio de carga adicional com verificações de integridade e direcionamento de tráfego. Um túnel, por si só, não toma estas decisões de forma aprofundada. A arquitetura deve ainda definir como o serviço de destino será restaurado após uma falha e se o acesso administrativo continuará a ser necessário durante a falha.

A disponibilidade não se limita ao software. Se o conector e o sistema de destino se encontrarem numa sala técnica própria, a alimentação elétrica, a refrigeração, a qualidade do ar e as inspeções regulares também devem ser incluídas no plano de operação. A análise sobre a Ventilação de uma sala de servidores na cave. Estas medidas não substituem as réplicas, mas impedem que todos os percursos de ligação previstos falhem devido à mesma dependência da infraestrutura local.

As atualizações do cloudflared devem ser realizadas durante uma janela de manutenção planeada: implicam um reinício e podem, por isso, afetar o tráfego em curso. A Cloudflare indica o balanceamento de carga ou a utilização de várias instâncias do cloudflared como opções para atualizações sem interrupção. O método de atualização mais adequado depende do tipo de instalação e do ambiente operacional e deve ser documentado antes do período de manutenção.

Para cada atualização, registe a versão instalada, o host responsável, um plano de contingência e um teste de acessibilidade ao serviço de destino. Após o reinício, verifique não só o estado do túnel, mas também se a regra de entrada definida alcança o serviço esperado e se a camada de acesso prevista continua a estar em vigor. Desta forma, o conector, o serviço de destino e a via de autorização permanecem compreensíveis como tarefas operacionais distintas.

Detetar atempadamente erros de configuração típicos

Antes da entrada em funcionamento, começa a deteção de erros no conector: o anfitrião tem de conseguir aceder à Cloudflare a partir da porta 7844, via TCP ou UDP. É de esperar que não haja uma abertura de porta de entrada, mas não é de esperar que exista um firewall de saída que bloqueie de forma generalizada. Só quando o `cloudflared` conseguir estabelecer as ligações de saída é que vale a pena analisar o DNS, os nomes de anfitrião e as regras de acesso ao nível da aplicação.

1. Verificar a acessibilidade local: O serviço mencionado na regra do Ingress deve estar acessível a partir do host «cloudflared» através do ponto final local ou interno indicado.
2. Sincronizar o DNS e o Ingress: o nome de host público deve corresponder à rota do túnel pretendida; a ordem das regras deve fazer com que a regra específica para o serviço em questão seja aplicada antes das regras mais gerais.
3. Testar o «catch-all»: uma regra final com http_status:404 impede que nomes de host não previstos sejam reencaminhados para um serviço padrão.
4. Configurar o Access antes da publicação em produção: só depois disso é que o caminho externo pode ser verificado de forma controlada com uma conta autorizada e uma conta não autorizada.

Um erro de segurança frequente é uma rota demasiado ampla: em vez de permitir o acesso apenas a um painel de administração ou a um serviço SSH definido, é disponibilizada uma área de rede mais vasta. Igualmente arriscadas são as regras genéricas relativas a domínios de e-mail para interfaces privilegiadas. No que diz respeito aos acessos de administração, devem ser definidos grupos pequenos e verificáveis, critérios de exigência adequados e autenticação multifator (MFA) para refletir o círculo real de pessoas autorizadas. Autorização mínima significa também não agrupar desnecessariamente nomes de anfitrião e serviços de destino distintos.

A configuração de túneis e de autorizações desempenha funções diferentes. A regra de entrada (Ingress) determina para onde segue uma ligação já estabelecida; a regra de acesso (Access) decide quem é autenticado e autorizado antes disso. Sem uma aplicação de acesso adequada, um nome de anfitrião HTTP publicado pode ficar acessível a partir da Internet. Por isso, as contas locais, as regras do sudo, as predefinições do SSHD e o reforço da segurança da aplicação continuam a ser, portanto, pontos de verificação independentes.

No que diz respeito aos registos e auditorias, o limite do endereço IP de origem é importante: no caso do SSH, RDP e outros acessos TCP, o servidor de origem não vê o endereço IP original do cliente, mas sim o contexto do conector. As listas de autorização baseadas em IP no sistema de destino não constituem, por isso, uma atribuição fiável ao utilizador. As aplicações HTTP podem avaliar o cabeçalho «CF-Connecting-IP», desde que o seu registo e a sua cadeia de confiança tenham isso em conta de forma deliberada.

Escolher a solução de acesso adequada

O Cloudflare Tunnel é adequado para um único painel de administração web, caso se pretenda que o serviço seja acessível através de um nome de host claro, sem disponibilizar um IP de origem público nem permitir tráfego de entrada. A configuração recomendada consiste num destino restrito, precedido por uma aplicação de acesso com um pequeno grupo de identidades e autenticação multifator (MFA). Este procedimento protege o percurso de rede, mas não substitui nem a gestão segura de sessões nem a verificação de direitos no painel de administração.

Uma pequena equipa de administração, habituada a trabalhar com o terminal, pode utilizar o SSH através do cloudflared e do Access do lado do cliente. O SSH renderizado pelo navegador é especialmente adequado como acesso de emergência ou de suporte pré-configurado. Ambas as opções apresentam requisitos diferentes em termos de cliente e utilização; a transferência de ficheiros, os fluxos de trabalho e os requisitos de auditoria devem estar em conformidade com o método escolhido. A decisão sobre modelos mais avançados para autorizações SSH centralizadas só deve ser tomada com base na documentação específica e atualizada de cada um.

Quem necessite de muitos serviços internos, segmentos inteiros ou uma comunicação ampla entre leste e oeste deve considerar um acesso à rede privada, como uma VPN, ou um modelo de conectividade específico para esse fim. Um único túnel publicado não substitui automaticamente todas as cargas de trabalho de VPN. O túnel não é adequado para protocolos iniciados pelo servidor, como o VoIP ou o SIP; também as sessões TCP de longa duração e sensíveis a interrupções exigem uma análise do protocolo específico e das possíveis consequências de uma reconexão.

A abertura clássica de portas pode ser aceitável quando um serviço é deliberadamente disponibilizado diretamente ao público e o firewall, a proteção da origem e a autenticação da aplicação são geridos de forma adequada. Um Bastion Host agrupa os acessos SSH, mas continua a ser, ele próprio, um ponto de entrada que deve ser protegido com especial cuidado. Um proxy reverso, por sua vez, é uma camada destinada à terminação TLS e à disponibilização de aplicações; não responde, por si só, à questão de como aceder à origem privada.

O padrão mínimo de produtividade consiste no seguinte: âmbito de alvos mais reduzido possível, regras baseadas na identidade, autenticação multifator (MFA) para funções privilegiadas, configuração testada do Ingress e do Catch-all, processo de atualização planeado e recuperação documentada. Plano de recuperação inclui, no mínimo, as responsabilidades, os percursos alternativos e a verificação de se o serviço de destino e o conector voltam a estar acessíveis após a manutenção. Os túneis reduzem a superfície de exposição da rede, mas não substituem o reforço da segurança das aplicações, as autorizações locais nem a monitorização contínua do funcionamento.