configurar rede Docker para isolar serviços no VPS

17 min de leitura  ·  Guia técnico

Configurar rede Docker para isolar serviços no VPS significa criar redes bridge personalizadas que segmentam containers em grupos lógicos, impedindo comunicação não autorizada entre serviços. Para isolar serviços Docker corretamente, siga estes passos:

1. Crie redes bridge personalizadas para cada camada da aplicação (frontend, backend, banco de dados).
2. Remova containers da rede bridge padrão docker0 e conecte-os apenas às redes necessárias.
3. Use a flag --internal para redes sem acesso à internet (bancos de dados, cache).
4. Defina as redes no docker-compose.yml com subnets fixas para facilitar o gerenciamento.
5. Valide o isolamento inspecionando cada rede com docker network inspect.

Pré-requisitos para configurar rede Docker no VPS

• Acesso SSH com privilégios root ou usuário com permissão sudo — veja como acessar em Acessando servidores VPS Linux da AviraHost.
• Docker Engine instalado (versão 24.x ou superior recomendada) no VPS com Debian 12, Ubuntu 24.04 LTS, Rocky Linux 9 ou AlmaLinux 9.
• Docker Compose v2 instalado (plugin integrado ao Docker CLI).
• Conhecimento básico de linha de comando Linux.
• Pelo menos uma aplicação com múltiplos serviços (ex.: aplicação web + banco de dados + cache).

Configurar rede Docker: entendendo os tipos de rede disponíveis

Antes de criar redes personalizadas, é essencial compreender os drivers de rede que o Docker oferece nativamente. Cada driver tem comportamento distinto e serve a casos de uso específicos no isolamento de serviços.

• bridge: driver padrão para containers no mesmo host. Cria uma interface virtual no Linux e roteia tráfego entre containers conectados à mesma rede. Redes bridge personalizadas oferecem DNS automático entre containers.
• host: o container compartilha a pilha de rede do host diretamente. Não há isolamento de rede — o container usa as portas do host sem mapeamento. Útil para performance máxima, mas elimina o isolamento.
• none: o container não tem interface de rede além do loopback. Isolamento total — sem comunicação externa nem com outros containers.
• overlay: conecta containers em múltiplos hosts Docker. Requer Docker Swarm ou Kubernetes. Ideal para clusters distribuídos.
• macvlan: atribui endereço MAC real ao container, que aparece como dispositivo físico na rede local. Útil para aplicações legadas que exigem IP dedicado.

Para a maioria dos cenários em VPS com um único host, o driver bridge personalizado é a escolha correta. Ele oferece isolamento, DNS automático e controle de subnet — sem a complexidade do overlay.

A rede padrão bridge (docker0) criada automaticamente pelo Docker não oferece resolução DNS entre containers por nome — apenas por IP. Isso é um motivo adicional para sempre criar redes bridge personalizadas em produção.

Como criar redes Docker personalizadas via linha de comando

O isolamento de containers começa pela criação explícita de redes com subnets definidas. Trabalhar com subnets fixas facilita regras de firewall e diagnóstico de tráfego.

Crie uma rede para a camada de aplicação (frontend/backend):

docker network create \
  --driver bridge \
  --subnet 172.20.0.0/24 \
  --gateway 172.20.0.1 \
  rede-app

Output esperado:
a3f8c2d1e4b5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1

Crie uma rede interna para o banco de dados — sem acesso à internet:

docker network create \
  --driver bridge \
  --subnet 172.21.0.0/24 \
  --gateway 172.21.0.1 \
  --internal \
  rede-db

Crie uma rede para o serviço de cache (Redis), também interna:

docker network create \
  --driver bridge \
  --subnet 172.22.0.0/24 \
  --gateway 172.22.0.1 \
  --internal \
  rede-cache

Liste todas as redes criadas para confirmar:

docker network ls

Output esperado:
NETWORK ID     NAME         DRIVER    SCOPE
a3f8c2d1e4b5   rede-app     bridge    local
b4c9d0e1f2a3   rede-db      bridge    local
c5d6e7f8a9b0   rede-cache   bridge    local
d6e1f2a3b4c5   bridge       bridge    local
e7f8a9b0c1d2   host         host      local
f8a9b0c1d2e3   none         null      local

Agora inicie os containers conectando-os às redes corretas. O container do banco de dados deve estar apenas na rede interna:

docker run -d \
  --name postgres \
  --network rede-db \
  -e POSTGRES_PASSWORD=senhaforte123 \
  postgres:16

O container da aplicação precisa acessar tanto o banco quanto a rede pública — conecte-o a duas redes:

docker run -d \
  --name app \
  --network rede-app \
  minha-imagem-app:latest

docker network connect rede-db app

Agora o container app consegue resolver o hostname postgres via DNS interno da rede-db, enquanto o container postgres não tem rota para a internet.

Configurar isolamento de rede Docker com Docker Compose

Em ambientes de produção, gerenciar redes via Docker Compose é mais sustentável do que comandos manuais. O Compose permite declarar toda a topologia de rede em um único arquivo versionável.

Exemplo completo de docker-compose.yml com isolamento de três camadas:

version: "3.9"

services:
  nginx:
    image: nginx:1.26
    ports:
      - "80:80"
      - "443:443"
    networks:
      - rede-app
    depends_on:
      - app

  app:
    image: minha-app:latest
    networks:
      - rede-app
      - rede-db
      - rede-cache
    environment:
      DB_HOST: postgres
      REDIS_HOST: redis
    depends_on:
      - postgres
      - redis

  postgres:
    image: postgres:16
    networks:
      - rede-db
    environment:
      POSTGRES_PASSWORD: senhaforte123
      POSTGRES_DB: producao
    volumes:
      - dados-postgres:/var/lib/postgresql/data

  redis:
    image: redis:7.2-alpine
    networks:
      - rede-cache
    command: redis-server --requirepass senhaforte456

networks:
  rede-app:
    driver: bridge
    ipam:
      config:
        - subnet: 172.20.0.0/24
  rede-db:
    driver: bridge
    internal: true
    ipam:
      config:
        - subnet: 172.21.0.0/24
  rede-cache:
    driver: bridge
    internal: true
    ipam:
      config:
        - subnet: 172.22.0.0/24

volumes:
  dados-postgres:

Nesta topologia:

• nginx está apenas na rede-app — recebe tráfego externo e repassa para a aplicação.
• app está nas três redes — é o único serviço que faz a ponte entre camadas.
• postgres está apenas na rede-db (interna) — sem acesso à internet.
• redis está apenas na rede-cache (interna) — sem acesso à internet.

Suba o ambiente com:

docker compose up -d

Output esperado:
[+] Running 5/5
 ✔ Network rede-app     Created
 ✔ Network rede-db      Created
 ✔ Network rede-cache   Created
 ✔ Container postgres   Started
 ✔ Container redis      Started
 ✔ Container app        Started
 ✔ Container nginx      Started

Validar o isolamento de rede entre containers Docker

Após criar as redes, verificar o isolamento efetivo é tão importante quanto a configuração em si. Use os comandos abaixo para confirmar que cada container tem acesso apenas ao que deve.

Inspecione a rede interna do banco de dados para ver quais containers estão conectados:

docker network inspect rede-db

Output esperado (trecho relevante):
"Containers": {
    "abc123...": {
        "Name": "postgres",
        "IPv4Address": "172.21.0.2/24"
    },
    "def456...": {
        "Name": "app",
        "IPv4Address": "172.21.0.3/24"
    }
},
"Internal": true

Teste que o container postgres não consegue acessar a internet:

docker exec postgres ping -c 3 8.8.8.8

Output esperado:
ping: connect: Network is unreachable

Confirme que o container app resolve o hostname do banco de dados por DNS:

docker exec app ping -c 3 postgres

Output esperado:
PING postgres (172.21.0.2): 56 data bytes
64 bytes from 172.21.0.2: icmp_seq=0 ttl=64 time=0.123 ms

Verifique que o nginx não consegue acessar o banco diretamente (isolamento correto):

docker exec nginx ping -c 3 postgres

Output esperado:
ping: postgres: Name or service not known

Este resultado confirma que o DNS interno do Docker só resolve hostnames para containers na mesma rede — o isolamento está funcionando corretamente.

Para uma visão geral de todas as redes e seus containers, use:

docker network ls --format "table {{.Name}}\t{{.Driver}}\t{{.Scope}}"

Se você também gerencia regras de firewall no host, consulte o artigo Configurando um Servidor Linux para Hospedagem de Sites para entender como o iptables interage com as redes Docker.

Boas práticas de segurança em redes Docker no VPS

O isolamento de rede é apenas uma camada da segurança em containers. Combine as configurações de rede com outras práticas para reduzir a superfície de ataque do seu VPS.

• Nunca exponha portas de banco de dados diretamente: evite -p 5432:5432 ou -p 3306:3306 em containers de banco de dados. O acesso deve ocorrer apenas via rede interna Docker.
• Use variáveis de ambiente para credenciais: prefira arquivos .env ou Docker Secrets em vez de hardcodar senhas no docker-compose.yml.
• Defina --cap-drop ALL e adicione apenas capabilities necessárias: reduz privilégios do processo dentro do container.
• Habilite o modo read-only no filesystem do container quando possível: --read-only impede escrita no sistema de arquivos do container.
• Monitore tráfego entre redes: use tcpdump na interface bridge para auditar comunicação entre containers em ambientes sensíveis.
• Remova redes não utilizadas regularmente: docker network prune limpa redes órfãs que podem representar vetores de ataque.
• Evite o modo --network host em produção: elimina todo o isolamento de rede e expõe o container diretamente à interface do host.

Atenção: ao usar docker network prune, todas as redes não utilizadas por nenhum container ativo serão removidas permanentemente. Certifique-se de que nenhum container parado (mas não removido) depende dessas redes antes de executar o comando.

Problemas comuns e como resolver

Sintoma: containers na mesma rede não se comunicam por hostname

Causa: o container foi iniciado usando a rede bridge padrão (docker0) em vez de uma rede bridge personalizada. A rede padrão não oferece resolução DNS automática entre containers — apenas IPs funcionam.
Solução: remova o container e recrie-o especificando a rede personalizada com --network nome-da-rede. Verifique com docker inspect nome-container | grep NetworkMode qual rede está sendo usada. Se usar Docker Compose, certifique-se de que o serviço está listado na seção networks do arquivo.

Sintoma: container com --internal ainda acessa a internet

Causa: o container está conectado a mais de uma rede, e uma delas não é interna. O Docker roteia o tráfego pela rede que tem gateway configurado.
Solução: execute docker network inspect nome-container e verifique todas as redes às quais o container está conectado. Desconecte o container de redes não internas com docker network disconnect nome-rede nome-container. Se o container precisar de múltiplas redes, garanta que apenas a rede de acesso externo tenha gateway configurado.

Sintoma: conflito de subnet entre rede Docker e rede do host

Causa: o Docker escolheu automaticamente uma subnet (ex.: 172.17.0.0/16) que conflita com a rede interna do VPS ou com VPNs configuradas no host.
Solução: ao criar a rede, especifique explicitamente uma subnet que não conflite com a infraestrutura existente usando --subnet. Para redes criadas via Compose, use o bloco ipam.config com subnet personalizada. Verifique as rotas do host com ip route show antes de definir os ranges.

Sintoma: docker network prune remove rede em uso por container parado

Causa: containers no estado Exited (parados mas não removidos) ainda mantêm referência às redes. O docker network prune remove apenas redes sem nenhum container associado — mas se o container foi removido incorretamente, a rede pode ficar órfã.
Solução: antes de executar prune, liste containers parados com docker ps -a e verifique suas redes com docker inspect. Remova containers desnecessários com docker rm nome-container antes de limpar as redes.

Sintoma: aplicação não consegue conectar ao banco de dados após reinicialização do VPS

Causa: a ordem de inicialização dos containers não garante que o banco de dados esteja pronto antes da aplicação tentar conectar. O Docker Compose inicia containers em paralelo por padrão.
Solução: use depends_on com condition: service_healthy no Compose, combinado com healthcheck no serviço do banco de dados. Exemplo para PostgreSQL: healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"]. Isso garante que a aplicação só inicia após o banco estar aceitando conexões.

Perguntas frequentes sobre configurar rede Docker

Por que criar redes separadas no Docker em vez de usar a rede padrão bridge?

A rede bridge padrão do Docker (docker0) permite que todos os containers se comuniquem entre si por padrão, o que representa um risco de segurança. Ao criar redes bridge personalizadas, você isola grupos de serviços, garantindo que apenas containers explicitamente conectados à mesma rede possam se comunicar. Além disso, redes personalizadas oferecem resolução de nomes DNS automática entre containers — na rede padrão, você precisaria usar IPs fixos para comunicação entre containers, o que torna a configuração frágil e difícil de manter.

Qual a diferença entre rede bridge, overlay e macvlan no Docker?

A rede bridge conecta containers no mesmo host Docker e é ideal para ambientes de host único. A rede overlay conecta containers em múltiplos hosts Docker (usada com Docker Swarm ou Kubernetes). A rede macvlan atribui um endereço MAC real ao container, fazendo-o aparecer como dispositivo físico na rede — útil para aplicações legadas que precisam de IP dedicado na rede local. Para a maioria dos VPS com aplicações web, o driver bridge personalizado atende todos os requisitos de isolamento sem a complexidade adicional dos outros drivers.

Como impedir que um container acesse a internet mas ainda se comunique com outros containers?

Crie uma rede Docker interna com a flag --internal ao executar docker network create. Containers nessa rede conseguem se comunicar entre si, mas não têm rota para fora do host. Isso é ideal para bancos de dados e serviços de cache que não devem ser expostos externamente. No Docker Compose, adicione internal: true na definição da rede. Valide o isolamento executando docker exec nome-container ping 8.8.8.8 — o resultado deve ser "Network is unreachable".

É possível conectar um container a mais de uma rede Docker ao mesmo tempo?

Sim. Um container pode ser conectado a múltiplas redes Docker simultaneamente usando o comando docker network connect nome-rede nome-container. Isso permite, por exemplo, que um container de aplicação acesse tanto a rede do banco de dados quanto a rede pública, enquanto o banco de dados permanece isolado em sua própria rede interna. No Docker Compose, liste todas as redes necessárias na seção networks do serviço. Cada interface de rede adicional aparece como uma interface virtual separada dentro do container.

Como verificar quais redes Docker estão configuradas e quais containers estão em cada rede?

Execute docker network ls para listar todas as redes disponíveis. Para inspecionar uma rede específica e ver quais containers estão conectados, use docker network inspect nome-da-rede. O output em JSON exibe o subnet, gateway e a lista de containers com seus IPs atribuídos. Para uma visão rápida de todas as redes de um container específico, use docker inspect nome-container --format '{{json .NetworkSettings.Networks}}' e pipe para python3 -m json.tool para formatação legível.

Conclusão

• Crie sempre redes bridge personalizadas em vez de usar a rede padrão docker0 — você ganha DNS automático, isolamento real e controle de subnet.
• Use a flag --internal para redes de banco de dados e cache, garantindo que esses serviços não tenham acesso à internet mesmo que o container seja comprometido.
• Declare toda a topologia de rede no docker-compose.yml com subnets fixas — isso facilita auditoria, reprodução do ambiente e integração com regras de firewall no host.

Leia também

• Entenda o Checklist de Segurança do Docker antes de ir ao ar
• Como Instalar e Configurar o Failover de Rede no VPS Linux para Alta Disponibilidade
• Como solucionar problemas de permissão de arquivos no VPS Linux: Guia Completo

Precisa de ajuda com Docker e infraestrutura no VPS?

Configurar redes Docker com isolamento adequado exige um VPS com recursos suficientes e acesso root completo. Na AviraHost, os planos de VPS Linux oferecem controle total sobre o ambiente, permitindo implementar topologias de containers com segurança e performance.

Conheça os planos de VPS Linux da AviraHost