Rede privada entre VPS e Cloud Servers: como criar

Resposta direta

Uma rede privada entre VPS e Cloud Servers permite que aplicações, bancos de dados, balanceadores e serviços administrativos se comuniquem por endereços internos, sem publicar cada porta na internet. A conexão pode usar a rede virtual do próprio provedor, um túnel WireGuard ou uma camada overlay que funcione entre diferentes datacenters. O desenho mais seguro combina endereços RFC 1918, firewall com política restritiva, autenticação por chaves, segmentação por função e monitoramento contínuo. Para um ambiente pequeno, uma sub-rede como 10.20.0.0/24 costuma ser suficiente. Em produção, também é preciso validar se a rede privada atravessa regiões, como ocorre o roteamento, qual é a MTU disponível e se o tráfego interno entra na franquia de transferência do provedor.

Resumo rápido

• Use IPs privados para bancos, filas, caches, replicação e administração.
• Prefira a rede nativa do provedor quando todos os servidores estiverem na mesma região compatível.
• Use WireGuard ou uma rede overlay para conectar provedores, regiões ou escritórios diferentes.
• Separe produção, homologação e gerenciamento em sub-redes distintas.
• Libere somente portas necessárias entre origens conhecidas.
• Teste rota, MTU, latência, perda de pacotes e throughput antes de migrar serviços.
• Mantenha backup, logs e um caminho de acesso emergencial independente da rede privada.

Como funciona uma rede privada entre servidores

Uma rede privada é um domínio de comunicação no qual os servidores usam endereços que não são roteáveis diretamente pela internet. As faixas mais comuns são 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16, definidas pela RFC 1918. Um Cloud Server pode ter, por exemplo, o IP público 203.0.113.10 para receber HTTPS e o IP privado 10.20.10.5 para consultar PostgreSQL. O banco usa apenas 10.20.20.10, sem serviço escutando na interface pública.

A palavra privada, porém, não significa automaticamente criptografada. Em uma rede virtual nativa, o isolamento costuma ser feito pela infraestrutura do provedor. A proteção exata varia conforme produto, região e arquitetura. Se a aplicação transmite credenciais, dados pessoais ou backups, TLS continua indicado mesmo dentro da rede interna. Isso reduz o impacto de uma configuração incorreta, de uma máquina comprometida ou de uma mudança futura na topologia.

Rede nativa, túnel VPN e rede overlay

Existem três modelos principais. A rede privada nativa é criada no painel ou na API do provedor e conecta instâncias dentro de um escopo definido. Um túnel VPN, como WireGuard, cria interfaces virtuais e criptografa os pacotes entre os endpoints. Já uma overlay gerenciada distribui identidade, rotas e descoberta de pares por meio de um plano de controle, o que simplifica ambientes espalhados, mas adiciona uma dependência operacional.

Considere dois exemplos. Uma loja virtual com frontend e banco no mesmo datacenter pode usar a rede nativa 10.30.0.0/24, liberando TCP 5432 apenas do IP da aplicação. Uma agência que mantém servidores em dois provedores pode usar WireGuard, com 10.90.0.1/24 e 10.90.0.2/24, para transportar deploys, métricas e backups de forma cifrada.

Topologias comuns

Na topologia ponto a ponto, dois servidores se conectam diretamente. É simples e adequada para replicação ou backup. Em hub-and-spoke, um gateway central encaminha tráfego para vários nós. Isso facilita políticas, mas transforma o hub em componente crítico. Em malha, cada nó alcança os demais diretamente, reduzindo saltos, ao custo de mais pares, chaves e regras.

Um ambiente de três camadas costuma ter balanceadores em 10.20.10.0/24, aplicações em 10.20.20.0/24 e dados em 10.20.30.0/24. O usuário acessa apenas o balanceador. A aplicação recebe tráfego interno e consulta o banco. O banco não inicia conexões para a internet, exceto por rotas controladas para atualizações ou serviços autorizados.

Planejamento de endereços, sub-redes e rotas

O planejamento deve começar antes da criação das interfaces. Escolher 10.0.0.0/24 por conveniência pode gerar conflito quando a empresa conecta uma VPN corporativa que já usa a mesma faixa. Prefira blocos menos previsíveis e documente a finalidade de cada sub-rede. Um exemplo organizado seria 10.42.10.0/24 para balanceadores, 10.42.20.0/24 para aplicações, 10.42.30.0/24 para bancos e 10.42.40.0/24 para monitoramento.

Uma sub-rede /24 oferece 256 endereços, embora alguns possam ser reservados pelo provedor. Para um enlace entre dois roteadores, /30 ou /31 economiza espaço, desde que a plataforma aceite essa máscara. Ambientes com containers também precisam de blocos próprios. Se o Docker usar 172.17.0.0/16 e a rede remota tiver a mesma faixa, o kernel poderá encaminhar o pacote para a bridge local em vez do túnel.

Escolha de faixas privadas

Monte um inventário com rede, gateway, ambiente, proprietário e serviços autorizados. Produção e homologação não devem compartilhar a mesma sub-rede apenas porque pertencem ao mesmo projeto. Um erro na regra do firewall poderia permitir que uma aplicação de teste consultasse dados reais. A separação pode ser lógica, com tabelas de rota e filtros, ou física, com redes virtuais diferentes.

Após atribuir um endereço, confirme em qual interface ele está configurado:

ip -br address
ip route show
ip route get 10.42.30.10

O último comando informa a interface, o gateway e o endereço de origem escolhidos pelo kernel. Ele ajuda a detectar um caso comum: a aplicação tenta alcançar o banco pela interface pública porque uma rota mais específica não foi instalada.

Rotas estáticas e encaminhamento

Servidores na mesma sub-rede normalmente se comunicam sem gateway adicional. Para ligar 10.42.20.0/24 a 10.42.30.0/24 por um roteador em 10.42.20.1, uma rota estática pode ser necessária:

ip route add 10.42.30.0/24 via 10.42.20.1

Se uma máquina atuar como roteador Linux, habilite o encaminhamento de forma persistente e restrinja o tráfego no firewall:

sysctl -w net.ipv4.ip_forward=1
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/90-private-routing.conf

Evite NAT entre redes internas quando o roteamento puro for possível. O NAT esconde a origem real, dificulta auditoria e pode confundir regras baseadas em IP. Ele faz sentido quando existe sobreposição de faixas ou quando uma rede de destino não possui rota de retorno. Antes de adotá-lo, verifique ida e volta com traceroute, tracepath e captura de pacotes nas duas extremidades.

Três formas de implementar a conexão privada

A escolha depende da localização das máquinas, do nível de automação e de quem deve controlar as chaves. Não existe uma opção universal. Uma rede do provedor costuma ter menos trabalho operacional, enquanto um túnel independente oferece portabilidade. Uma overlay simplifica dezenas de nós, mas requer avaliação do plano de controle, do método de autenticação e do comportamento quando esse serviço fica indisponível.

Abordagem	Escopo típico	Criptografia no enlace	Complexidade operacional	Melhor aplicação
Rede privada nativa	Instâncias compatíveis do mesmo provedor ou região	Depende do produto	Baixa	Aplicação, banco e cache próximos
WireGuard ponto a ponto	Provedores, regiões e redes diferentes	Sim	Média	Backup, replicação e administração
Overlay gerenciada	Muitos servidores e usuários distribuídos	Normalmente sim	Média	Acesso por identidade e malha dinâmica
Gateway IPsec ou WireGuard	Rede cloud ligada ao escritório	Sim	Alta	Integração híbrida e rotas entre sub-redes

Rede privada oferecida pelo provedor

Nesse modelo, crie a rede virtual, associe as instâncias e atribua endereços internos. Teste a comunicação antes de alterar a aplicação. Alguns produtos limitam redes privadas a uma região, conta ou zona específica. Outros permitem peering entre redes, possivelmente com limites e cobrança. Localidade, banda, MTU e tráfego contabilizado são dados variáveis e precisam ser confirmados na documentação oficial antes da implantação.

Um teste inicial pode usar ping, quando ICMP estiver permitido, seguido de uma conexão TCP real:

ping -c 4 10.42.30.10
nc -vz 10.42.30.10 5432

WireGuard entre servidores

WireGuard cria uma interface como wg0 e associa cada peer a um conjunto de IPs permitidos. Gere as chaves localmente com permissões restritas. A chave privada nunca deve aparecer em repositório, ticket ou script compartilhado. Depois de configurar os peers, valide o estado com:

umask 077
wg genkey > /etc/wireguard/private.key
wg show
ip address show wg0

Para dois servidores atrás de NAT, configure um endpoint alcançável e keepalive somente quando necessário. Em uma malha com dez nós, a configuração manual já se torna trabalhosa, pois cada novo peer exige distribuição de chave pública e atualização de rotas. Nesse ponto, um hub ou uma camada de automação pode ser mais sustentável.

Overlay gerenciada

Uma overlay baseada em identidade é útil para conectar notebooks administrativos, servidores de múltiplos provedores e ambientes temporários. Em vez de liberar SSH para qualquer origem, a política pode autorizar apenas o grupo de operações a acessar TCP 22 nos nós de produção. Teste também o modo de contingência. A comunicação já estabelecida continua funcionando se o plano de controle ficar indisponível? Existem relays? Os nós conseguem formar conexão direta? Essas respostas mudam o risco operacional.

Firewall, segmentação e controle de acesso

A rede privada reduz a superfície pública, mas não substitui o firewall. Um servidor comprometido dentro da rede pode tentar alcançar bancos, painéis e serviços de monitoramento. A defesa precisa considerar origem, destino, porta, direção e função do sistema. Uma política adequada começa bloqueando encaminhamento e entrada não solicitada, depois libera fluxos explícitos.

Em um ambiente simples, o balanceador 10.42.10.5 pode acessar as aplicações em TCP 8080. As aplicações 10.42.20.10 e 10.42.20.11 acessam PostgreSQL em TCP 5432 e Redis em TCP 6379. O servidor de monitoramento 10.42.40.5 consulta exporters em TCP 9100. Nenhuma dessas portas precisa estar vinculada ao IP público.

Política de menor privilégio

Um conjunto básico com nftables pode aceitar conexões já estabelecidas, SSH pela interface VPN e PostgreSQL apenas pela sub-rede de aplicações:

nft add table inet filter
nft 'add chain inet filter input { type filter hook input priority 0; policy drop; }'
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input iifname lo accept
nft add rule inet filter input iifname wg0 tcp dport 22 accept
nft add rule inet filter input ip saddr 10.42.20.0/24 tcp dport 5432 accept

Regras digitadas diretamente podem desaparecer após reinicialização. Salve a configuração pelo mecanismo da distribuição e teste uma segunda sessão antes de fechar o acesso atual. O artigo sobre firewall e hardening de segurança em VPS aprofunda SSH por chave, atualizações, proteção contra força bruta e redução de serviços expostos.

Também configure o daemon para escutar no endereço correto. No PostgreSQL, restringir listen_addresses ao IP privado reduz o risco de uma regra de borda liberar a porta por engano. No Redis, combine bind interno, autenticação, ACL e TLS quando o cenário exigir. Firewall e configuração da aplicação formam camadas complementares.

Proteção do plano de administração

Não misture tráfego administrativo com tráfego da aplicação sem necessidade. Uma sub-rede ou VPN de gerenciamento permite limitar SSH, painéis e métricas. Use contas individuais, chaves separadas e logs centralizados. Se uma pessoa sair da equipe, revogue sua identidade sem trocar todas as credenciais do ambiente.

Mantenha um acesso emergencial pelo console do provedor. Uma rota incorreta ou regra de firewall pode bloquear a própria VPN. Teste a recuperação antes de uma falha real, registre quem pode usar o console e proteja a conta com autenticação multifator. A rede privada melhora a arquitetura, mas uma configuração sem caminho de recuperação transforma um erro simples em indisponibilidade prolongada.

Aplicações, bancos e balanceadores na rede interna

O ganho mais visível aparece quando a arquitetura deixa apenas a camada necessária exposta. Em uma aplicação web, os usuários acessam HTTPS no balanceador. O balanceador encaminha requisições por IP privado para dois servidores. Esses servidores consultam banco, cache e fila na rede interna. O desenho reduz portas públicas e mantém os endereços dos backends fora do DNS externo.

Suponha dois backends em 10.42.20.10:8080 e 10.42.20.11:8080. Um HAProxy em 10.42.10.5 pode verificar /health a cada dois segundos e retirar um nó após três falhas consecutivas. Antes de adotar esse padrão, confira como preservar o IP do cliente, onde terminar TLS e se a aplicação confia corretamente nos cabeçalhos de proxy. O conteúdo sobre Cloud Server com HAProxy e balanceamento de carga detalha health checks, algoritmos e tratamento de falhas.

Separação entre frontend e dados

O banco deve aceitar conexões somente das aplicações autorizadas. Se PostgreSQL estiver em 10.42.30.10, configure a aplicação com esse endereço interno e inclua regras específicas no pg_hba.conf. Não use 0.0.0.0/0 para resolver rapidamente um erro de conexão. Esse atalho amplia o acesso e esconde o problema original, que pode ser rota, firewall ou credencial.

Filas e caches também exigem cuidado. Redis não deve ser tratado como serviço confiável apenas por estar em IP privado. Use ACL, senha forte armazenada em gerenciador de segredos e limites de memória. Para RabbitMQ, separe as portas de protocolo, administração e clusterização. Um painel web pode ficar disponível apenas pela VPN, enquanto os produtores acessam somente a porta necessária.

Outro exemplo é o backup. O servidor de banco pode enviar cópias para 10.42.40.20 por SSH ou um protocolo próprio, mas o repositório não precisa iniciar conexões de volta. Regras direcionais reduzem movimento lateral. Uma cópia adicional fora do mesmo provedor ou domínio de falha protege contra exclusão acidental, credenciais comprometidas e falhas regionais.

Alta disponibilidade e replicação

Replicação privada evita expor portas sensíveis, mas não cria alta disponibilidade sozinha. É preciso detectar falhas, promover réplicas, atualizar rotas ou service discovery e impedir split-brain. Latência entre regiões afeta replicação síncrona, pois cada transação pode esperar a confirmação remota. Para distâncias maiores, replicação assíncrona costuma reduzir impacto na escrita, aceitando uma janela potencial de perda.

Quem está desenhando dois ou mais nós pode combinar esta rede com as práticas de alta disponibilidade e failover em VPS. O teste deve desligar um backend, bloquear uma rota e interromper o banco primário. Se a aplicação só funciona no diagrama, mas não durante esses ensaios, o ambiente ainda não está pronto para depender da automação de failover.

Desempenho, testes e solução de problemas

Uma conexão privada não é necessariamente mais rápida do que a pública. O caminho pode ser mais curto, evitar NAT ou permanecer na infraestrutura do provedor, mas isso precisa ser medido. CPU compartilhada, criptografia, limites de interface, distância física e congestionamento continuam influenciando o resultado. Compare latência, perda e throughput no mesmo período, usando carga controlada e registrando a configuração dos servidores.

Comece com um teste de latência de pelo menos 100 pacotes. Observe média, percentil alto e perda, não apenas o menor número exibido. Depois use iperf3 entre dois nós, primeiro com um fluxo e depois com quatro fluxos paralelos. Um único fluxo TCP pode não ocupar todo o enlace quando a latência é maior ou a janela está limitada.

ping -c 100 10.42.20.11
iperf3 -s
iperf3 -c 10.42.20.11 -P 4 -t 30

Execute testes fora do horário crítico e imponha limites quando necessário. iperf3 pode consumir a banda disponível e afetar replicação, backups ou usuários reais. Para banco de dados, um benchmark de rede não substitui um teste da aplicação. Meça tempo de consulta, conexões por segundo e comportamento do pool.

Latência, throughput e MTU

Túneis adicionam cabeçalhos e reduzem a MTU útil. Se a interface física usa MTU 1500, uma interface WireGuard frequentemente precisa de valor menor, conforme transporte e caminho. Sintomas de MTU inadequada incluem conexões que abrem, mas travam ao transferir respostas maiores, uploads interrompidos e TLS aparentemente instável.

Use tracepath para estimar a MTU do caminho e teste pacotes sem fragmentação. Não copie um valor de outro ambiente sem medir. Uma VPN sobre IPv6, PPPoE ou encapsulamento adicional pode exigir ajuste diferente. Após a alteração, repita testes de HTTP, banco e transferência de arquivo.

Diagnóstico por camadas

Quando a conexão falhar, siga uma ordem. Confirme que a interface está ativa e possui o IP esperado. Verifique a rota escolhida. Teste ARP ou vizinhança quando os hosts estiverem no mesmo segmento. Analise firewall local, firewall do provedor e serviço escutando. Por fim, capture pacotes nas duas pontas:

ss -lntup
ip route get 10.42.30.10
nft list ruleset
tcpdump -ni any host 10.42.30.10 and port 5432

Se o SYN sai da aplicação e não chega ao banco, o problema está no caminho. Se chega e não há resposta, examine firewall e processo no destino. Se o SYN-ACK volta por outra interface, corrija a rota de retorno e avalie o filtro de caminho reverso. Registre métricas da interface, handshakes da VPN, perda de pacotes e tempo de conexão. Alertas simples detectam degradação antes que ela apareça como erro intermitente na aplicação.

Recomendações por perfil

A arquitetura deve acompanhar o risco e a capacidade operacional. Um ambiente com dois servidores não precisa começar com múltiplos gateways e roteamento dinâmico. Da mesma forma, uma operação crítica não deveria depender de um único túnel configurado manualmente e sem monitoramento. Os perfis abaixo servem como ponto de partida, não como dimensionamento universal.

Desenvolvedor solo

Para uma aplicação pequena com um servidor web e um banco separado, use a rede privada nativa quando os dois estiverem no mesmo provedor e escopo compatível. Reserve uma sub-rede /24, atribua IPs fixos e publique somente TCP 80 e 443 no frontend. O banco deve escutar no endereço privado e aceitar TCP 5432 apenas do IP da aplicação. Mantenha SSH acessível por WireGuard ou por uma lista restrita de origens. Duas vCPUs e 4 GB de RAM podem atender uma aplicação inicial, mas o consumo real do banco e da linguagem precisa ser medido. Documente endereços, regras e procedimento de recuperação pelo console.

Equipe pequena ou produto em crescimento

Com três a dez servidores, separe balanceamento, aplicação, dados e monitoramento. Use sub-redes como 10.42.10.0/24, 10.42.20.0/24 e 10.42.30.0/24, mesmo que o provedor permita colocar tudo na mesma rede. Centralize logs e métricas, crie regras por função e evite liberar uma sub-rede inteira quando apenas dois IPs precisam acessar o banco. Uma VPN baseada em identidade pode simplificar o acesso da equipe, enquanto a rede nativa transporta o tráfego entre serviços. Teste restauração de backup, rotação de chaves e remoção de um backend. Para cada mudança, registre rota, porta, origem, destino e responsável.

Produção crítica e múltiplos ambientes

Para produção crítica, trate rede privada como parte do sistema, com redundância, observabilidade e controle de mudanças. Separe produção, homologação e gerenciamento em redes distintas. Use dois gateways quando a comunicação entre regiões ou provedores depender de VPN, evitando que uma única máquina interrompa todos os fluxos. Monitore handshake, latência, perda, throughput, tabela de rotas e uso de CPU causado pela criptografia. Replicação síncrona só deve atravessar enlaces cuja latência e estabilidade tenham sido testadas com a carga real. Inclua no plano de desastre um canal alternativo de acesso, cópias fora do domínio de falha e procedimentos para reconstruir túneis sem reutilizar chaves comprometidas.

Em qualquer perfil, confirme no provedor os limites de rede, a disponibilidade por região, a cobrança de tráfego e o comportamento de IPs privados durante migrações ou recriações. Faça a primeira implantação com serviços não críticos, provoque falhas controladas e guarde os resultados. Uma rede interna bem desenhada não é apenas um conjunto de IPs. Ela define quais componentes podem conversar, em quais condições e como a equipe recupera o ambiente quando algo sai do esperado.