Sub-redes IPv4 e VLSM para segmentação: aplicando em escritórios e data centers

Por que sub-redes e VLSM importam na segmentação

Em ambientes reais (escritórios e data centers), raramente uma única rede “plana” atende bem. Você precisa separar tráfego por função (usuários, servidores, gestão, serviços), reduzir domínio de broadcast, aplicar políticas diferentes (ACLs/firewall), e facilitar troubleshooting. Subnetting é a técnica de dividir um bloco IPv4 em redes menores. VLSM (Variable Length Subnet Mask) é a aplicação prática de subnetting com tamanhos diferentes por segmento, evitando desperdício de endereços e permitindo crescimento planejado.

A ideia central: você recebe (ou escolhe) um bloco “pai” e o subdivide em sub-redes com tamanhos adequados. Em VLSM, você cria primeiro as maiores sub-redes e depois encaixa as menores, garantindo que não haja sobreposição.

Conceito operacional: o que você precisa decidir antes de calcular

1) Quais segmentos existem e qual o objetivo de cada um

• Usuários (LAN): muitos hosts, tráfego variado, maior risco de incidentes; costuma precisar de políticas mais restritivas para acessar servidores.
• Servidores (produção): menos hosts, mas críticos; normalmente acessados apenas por portas específicas.
• Gestão (management): acesso administrativo a switches, iDRAC/iLO, hypervisors, storage; deve ser altamente restrito.
• Serviços críticos: DNS, DHCP, NTP, AD/LDAP, monitoramento, syslog; podem ficar em uma sub-rede própria ou junto de servidores, dependendo do desenho.
• DMZ (quando aplicável): serviços expostos; regras de entrada/saída bem específicas.

2) Quantos hosts por segmento e quanto reservar

Não planeje apenas “quantos dispositivos existem hoje”. Inclua:

• Crescimento (ex.: +30% em 12–24 meses).
• IPs reservados para gateways, balanceadores, VIPs, NAT, appliances, IPMI, etc.
• Endereços fixos (servidores, impressoras, APs, câmeras) e pools DHCP.

3) Um padrão de endereçamento que ajude na operação

Um padrão simples reduz erros e acelera troubleshooting. Exemplos de convenções:

• .1 = gateway (SVI/roteador)
• .2–.9 = infraestrutura (firewall interno, roteadores, balanceadores, VRRP/HSRP)
• .10–.49 = serviços críticos (DNS, DHCP, NTP, AD, monitoramento)
• .50–.199 = servidores/estáticos
• .200–.254 = DHCP para clientes (quando fizer sentido)

Você não é obrigado a seguir isso, mas escolher um padrão e documentar é parte do trabalho de administração.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

Como calcular o tamanho de uma sub-rede (regra prática)

Para suportar N hosts, você precisa de uma sub-rede com pelo menos N + reservas endereços utilizáveis. Em IPv4, uma sub-rede tem 2 endereços não utilizáveis (rede e broadcast). Então, você escolhe o menor bloco cujo total de endereços seja ≥ (N + reservas + 2).

Tamanhos comuns (endereços totais → utilizáveis):

• /24: 256 → 254
• /25: 128 → 126
• /26: 64 → 62
• /27: 32 → 30
• /28: 16 → 14

Exemplos pedidos (sem ainda encaixar em um bloco pai):

• 10 hosts → precisa de pelo menos 10 utilizáveis. /28 dá 14 utilizáveis (sobra para reservas).
• 30 hosts → /27 dá 30 utilizáveis (encaixe exato, pouca folga).
• 60 hosts → /26 dá 62 utilizáveis (folga pequena).
• 200 hosts → /24 dá 254 utilizáveis (folga boa).

Passo a passo VLSM: criando sub-redes para 200, 60, 30 e 10 hosts

Vamos partir de um bloco privado de exemplo: 10.20.0.0/23. Ele contém 512 endereços (de 10.20.0.0 a 10.20.1.255) e é suficiente para acomodar as quatro sub-redes sem sobreposição.

Passo 1: ordenar do maior para o menor

• 200 hosts → /24
• 60 hosts → /26
• 30 hosts → /27
• 10 hosts → /28

Passo 2: alocar sequencialmente, respeitando os limites de cada prefixo

Alocação proposta dentro de 10.20.0.0/23:

Note como não há sobreposição: cada sub-rede começa exatamente no próximo limite válido do seu tamanho. O restante do bloco 10.20.1.112 – 10.20.1.255 fica livre para expansão (novas VLANs, DMZ, Wi‑Fi corporativo, VoIP etc.).

Passo 3: reservar IPs para gateways, balanceadores e serviços críticos

Agora transforme “faixa utilizável” em um plano operacional. Exemplo de reservas por segmento:

Segmento Usuários — 10.20.0.0/24

• Gateway (SVI/roteador): 10.20.0.1
• Firewall interno / next-hop (se aplicável): 10.20.0.2
• Relay DHCP (se o gateway não fizer isso): geralmente no gateway; se houver appliance dedicado, reserve 10.20.0.3
• Pool DHCP: 10.20.0.50 – 10.20.0.199
• Reservas para estáticos (impressoras/APs): 10.20.0.200 – 10.20.0.254

Segmento Servidores — 10.20.1.0/26

• Gateway: 10.20.1.1
• Balanceadores (dois nós): 10.20.1.2 e 10.20.1.3
• VIPs (endereços virtuais de serviços atrás do balanceador): reserve um bloco, por exemplo 10.20.1.10 – 10.20.1.19
• Servidores: 10.20.1.20 – 10.20.1.62

Segmento Serviços críticos — 10.20.1.64/27

• Gateway: 10.20.1.65
• DNS (2): 10.20.1.66, 10.20.1.67
• NTP: 10.20.1.68
• DHCP (se dedicado): 10.20.1.69
• Monitoramento: 10.20.1.70
• Syslog/SIEM: 10.20.1.71
• Reserva para novos serviços: 10.20.1.72 – 10.20.1.94

Segmento Gestão — 10.20.1.96/28

• Gateway: 10.20.1.97
• IPMI/iDRAC/iLO: 10.20.1.100 – 10.20.1.110
• Switches/roteadores (mgmt): 10.20.1.98 – 10.20.1.99

Repare que as reservas não são “obrigatórias”, mas tornam o ambiente previsível. Isso reduz tempo de diagnóstico e evita colisões de IP.

Como evitar sobreposição e erros comuns (checklist prático)

Checklist de alocação VLSM

• Ordene do maior para o menor antes de começar.
• Respeite o “salto” (block size) do prefixo. Exemplos: /24 salta de 256 em 256; /26 salta de 64 em 64; /27 salta de 32 em 32; /28 salta de 16 em 16.
• Não comece uma sub-rede no meio do bloco. Ex.: uma /27 não pode começar em .70; precisa começar em múltiplos de 32 (0, 32, 64, 96...).
• Documente rede, máscara/prefixo, gateway, reservas e finalidade.
• Separe “endereços para infraestrutura” do pool DHCP para evitar conflitos.

Exemplo de validação rápida (sem calculadora)

Você alocou 10.20.1.64/27. Como saber se está certo?

• /27 tem bloco de 32 endereços.
• Se começa em .64, termina em .95 (64 + 31).
• Logo, a próxima sub-rede possível (de qualquer tamanho menor ou igual) começa em .96. Isso bate com a gestão 10.20.1.96/28.

Aplicando em escritórios vs. data centers (padrões de segmentação)

Escritório (ênfase em usuários e serviços corporativos)

• Uma ou mais VLANs de usuários (por andar, por departamento ou por SSID).
• Uma VLAN de serviços (DNS/DHCP/AD/monitoramento) ou serviços em servidores com regras bem definidas.
• Uma VLAN de gestão separada (switches, APs, controladoras, IPMI).
• Possível VLAN de convidados (isolada, saída apenas para internet).

Data center (ênfase em isolamento e controle leste-oeste)

• VLANs por domínio: front-end, app, banco, storage, backup, management.
• Sub-redes menores e mais numerosas para reduzir blast radius.
• Uso frequente de VIPs e balanceadores; reservar blocos para VIPs evita reendereçamento.
• Rotas sumarizadas por bloco do DC para simplificar roteamento entre sites.

Como as decisões de subnetting impactam roteamento

1) Tabelas de rota e sumarização

Quando você escolhe blocos contíguos e bem alinhados, pode anunciar rotas sumarizadas (menos rotas, convergência mais simples). Exemplo: se todas as VLANs internas estiverem dentro de 10.20.0.0/23, um roteador upstream pode ter uma rota única para o site: 10.20.0.0/23 apontando para o core.

Se você espalha sub-redes sem padrão (ex.: uma VLAN em 10.20.0.0/24, outra em 10.20.50.0/24, outra em 10.21.7.0/24), a sumarização fica difícil ou impossível sem incluir redes que não pertencem ao site.

2) Inter-VLAN routing e gateways

Cada sub-rede precisa de um gateway (SVI em switch L3 ou interface de roteador/firewall). Um plano consistente (gateway sempre .1, por exemplo) reduz erros de configuração e acelera a identificação do próximo salto durante troubleshooting.

Como as decisões de subnetting impactam ACLs e políticas

1) Regras por sub-rede ficam mais simples

Segmentos com função clara permitem ACLs objetivas. Exemplo de política típica:

• Usuários (10.20.0.0/24) podem acessar serviços críticos (10.20.1.64/27) apenas em portas específicas (DNS, NTP, LDAP/AD, HTTP/HTTPS para portais internos).
• Usuários não acessam gestão (10.20.1.96/28) de forma alguma.
• Gestão acessa servidores e equipamentos em portas administrativas (SSH, RDP, HTTPS de iDRAC/iLO), a partir de um jump host.

2) Menos exceções quando há VLSM bem planejado

Se você mistura serviços críticos dentro da mesma sub-rede de usuários, as ACLs viram uma lista de exceções (permitir alguns IPs, negar outros) e o risco de abrir demais aumenta. Separar por sub-rede reduz ambiguidade: “tudo que está em 10.20.1.64/27 é infraestrutura crítica”.

Troubleshooting orientado por sub-redes (o que muda na prática)

1) Identificar rapidamente onde está o problema

Com segmentação, você consegue localizar falhas por domínio:

• Se apenas usuários falham, mas servidores e gestão estão ok, investigue VLAN de usuários, DHCP, uplinks do andar, políticas de acesso.
• Se apenas gestão falha, investigue ACLs que bloqueiam a VLAN de management, ou rotas ausentes para 10.20.1.96/28.
• Se serviços críticos falham (DNS/NTP), o impacto é amplo; a sub-rede dedicada ajuda a isolar e monitorar.

2) Sintomas comuns quando há erro de máscara ou sobreposição

• Host acha que o destino é local (máscara grande demais): tenta ARP em vez de rotear; comunicação falha para redes que deveriam ser remotas.
• Dois segmentos com a mesma sub-rede (sobreposição): rotas ambíguas, tráfego indo para o lugar errado, conflitos de IP, intermitência.
• DHCP entregando máscara errada: dezenas de máquinas com comportamento estranho ao mesmo tempo.

3) Verificações rápidas que dependem do plano

• O IP do host está dentro da faixa correta do segmento?
• O gateway configurado é o gateway padrão daquele segmento (ex.: .1)?
• O endereço do serviço (DNS, AD, monitoramento) está no bloco reservado de serviços críticos?
• Existe rota (ou anúncio) para o bloco sumarizado do site (10.20.0.0/23) nos roteadores upstream?

Exemplo completo de plano (pronto para documentação)

Exercício guiado: ajuste de capacidade e crescimento

Recalcule o plano se:

• Usuários crescerem de 200 para 350: a VLAN de usuários precisaria de pelo menos /23 (510 utilizáveis) ou dividir em duas VLANs /24 (ex.: por andar/departamento).
• Servidores crescerem de 60 para 120: migrar de /26 (62) para /25 (126) ou criar uma segunda sub-rede de servidores e ajustar rotas/ACLs.
• Gestão precisar incluir mais equipamentos (ex.: 40 IPMIs): sair de /28 (14) para /26 (62) ou criar uma segunda VLAN de gestão (ex.: gestão de rede vs. gestão de servidores).

O ponto do exercício: VLSM permite começar enxuto, mas você deve deixar espaço contíguo para crescer sem reendereçar, ou aceitar que, em algum momento, será necessário criar novas VLANs e ajustar políticas.