Como movemos o tráfego entre nossos servidores sem expô-lo à Internet

Publicado em 2026-09-12 por frfrand

Cuando una app en un servidor necesita una base que vive en otro, hay dos caminos: abrir un puerto al mundo o hacer que se vean entre ellos. Por qué elegimos el segundo.

É uma das situações mais comuns quando um projeto cresce um pouco: a aplicação roda em um servidor e o banco de dados em outro. Como eles se comunicam?

A resposta rápida é abrir a porta do banco e apontar a aplicação para o IP público do outro servidor. Funciona em cinco minutos. E deixa um banco de dados exposto à Internet, que é exatamente o que alguém passa os anos seguintes tentando evitar.

Nós resolvemos ao contrário.

O problema com a solução fácil

Abrir o 5432 para o mundo tem três custos que não se veem no primeiro dia:

• O banco acaba nas listas de scanners automáticos em poucos minutos.
• A segurança passa a depender da senha do banco e de que sua versão não tenha vulnerabilidades. Para sempre.
• O tráfego entre seus dois servidores sai para a Internet e volta a entrar, adicionando latência e um trecho que você não controla.

Esse último ponto é subestimado. Dois servidores do mesmo provedor, às vezes no mesmo data center, enviando consultas pela Internet pública.

O que fazemos em vez disso

Entre os VPS da ArduMaker, o tráfego interno viaja por túneis criptografados entre as máquinas. Do ponto de vista da aplicação, o banco está no localhost, na porta de sempre. Do ponto de vista da Internet, o servidor do banco não tem nenhuma porta de banco de dados aberta.

A peça importante é a direção em que o túnel é levantado: ele é iniciado pelo lado que precisa se conectar. Isso significa que o servidor que armazena os dados não precisa aceitar conexões entrantes de ninguém. Não há uma porta para proteger, porque não há porta.

Como se vê na prática

A configuração é feita pelo painel: escolhe-se o VPS iniciador, o VPS receptor e qual porta é publicada de um lado para o outro. A partir daí:

# no servidor do app, a base é local DATABASE_URL=postgres://usuario:clave@localhost:5432/midb

A string de conexão do seu aplicativo aponta para localhost. Se amanhã o banco mudar para outro servidor, basta alterar a configuração do túnel e o aplicativo nem percebe.

Esse desacoplamento é metade do valor. A outra metade é que a superfície exposta não cresce quando sua infraestrutura cresce.

O que se ganha além

Menos configuração duplicada. Não é preciso manter regras de firewall para cada par de servidores que se comunicam.

Reversível. Desativar um túnel não deixa uma porta aberta esquecida: ao cortar o túnel, o acesso desaparece.

Audável. O túnel é um objeto da plataforma, com seu estado e seu histórico. É possível responder "quem pode falar com este banco?" olhando uma lista, e não reconstruindo isso a partir de regras de iptables.

Chaves próprias. O receptor aceita apenas as chaves que você declarou. Adicionar um servidor novo é incluir sua chave, e removê-lo é excluí-la.

Quando não é suficiente

Se o que você precisa é que um serviço de terceiros chegue ao seu banco (uma ferramenta de análise hospedada fora, por exemplo), um túnel entre seus servidores não resolve isso. Aí as opções são uma VPN que inclua esse terceiro, uma réplica de somente leitura pensada para ser exposta, ou uma API própria que devolva apenas o que esse terceiro precisa.

A terceira costuma ser a melhor, embora dê mais trabalho: é a única em que você decide exatamente o que sai.

A ideia de fundo

É a mesma que percorre toda a plataforma: o que não precisa estar aberto, não se abre. E quando duas coisas precisam se comunicar, é melhor fazer com que se vejam entre si do que torná-las visíveis para todos.