DEV Community: Levi Gomes

(8/8) Testes Finais, Troubleshooting e Encerramento

Levi Gomes — Mon, 08 Dec 2025 19:09:22 +0000

1. Objetivo

A etapa final serve para verificar se a rede opera como um sistema coerente: endereçamento consistente, caminhos previsíveis, resolução de nomes estável e isolamento funcional entre segmentos. Nesta fase, o importante não é mais validar comandos específicos, mas confirmar o comportamento global da infraestrutura.

2. Checklist final

Uma rede bem estruturada mostra alguns sinais claros:

hosts recebem IPs corretos
serviços internos são acessíveis sem gambiarras
caminhos de roteamento fazem sentido
a tradução de endereços ocorre apenas onde planejado e as políticas de firewall se mantêm previsíveis entre LAN, DMZ e redes de convidados.

Quando tudo está alinhado, o ambiente se torna transparente no dia a dia — nenhuma máquina depende de configurações manuais, e cada teste básico (acesso externo, resolução de nomes, comunicação entre segmentos autorizados) indica que os blocos funcionam de forma integrada.

3. Encerramento: teoria aplicada e próximos passos

A partir daqui, o ganho real vem da prática: montar serviços internos na DMZ, testar alta disponibilidade com múltiplos roteadores, comparar iptables e nftables em cenários equivalentes, explorar IPv6 puro e experimentar segmentações mais rígidas com VLANs e roteamento inter-VLAN. Projetos assim revelam como cada componente reage sob carga, falha ou reconfiguração — algo que não aparece em exercícios isolados.

Para quem deseja avançar além do laboratório, há caminhos amplos e complementares. Em redes, isso envolve estudar modelos de segurança mais abrangentes, fundamentos de arquitetura distribuída, protocolos de roteamento dinâmico, monitoração contínua e práticas de endurecimento de serviços expostos. Para quem vem do desenvolvimento, o passo seguinte costuma ser integrar infraestrutura e aplicação: revisar padrões de deploy, redes em containers, ambientes multi-zona, políticas de segurança aplicadas ao tráfego da aplicação, integração com CI/CD e observabilidade.

Conforme esses estudos se acumulam, a rede deixa de ser um conjunto de comandos memorizados e passa a operar como parte de um sistema maior, onde cada decisão estrutural influencia desempenho, segurança e escalabilidade. Esse é o ponto que dá continuidade ao que foi construído na série e abre espaço para arquiteturas mais sólidas, modernas e sustentáveis.

(7/8) Firewall: Estrutura, Fluxo e Políticas Reais

Levi Gomes — Mon, 08 Dec 2025 19:08:57 +0000

1. Motivação

Um firewall não serve apenas para bloquear acessos: ele organiza o caminho que cada pacote percorre. Funciona como o “controle de fronteira” da rede, definindo o que pode entrar, o que pode sair, o que só pode atravessar e o que deve ser descartado imediatamente.
Entender essa lógica é essencial para projetar ambientes seguros e previsíveis, especialmente quando você precisa isolar serviços, publicar aplicações ou segmentar usuários.

2. Fluxo do kernel (diagrama)

O firewall segue a ordem interna do Netfilter, que define onde e como cada pacote é tratado:

PREROUTING → INPUT → FORWARD → OUTPUT → POSTROUTING

PREROUTING: antes do kernel decidir o destino; onde ocorre DNAT.
INPUT: pacotes cujo destino final é o próprio host.
FORWARD: pacotes que só estão passando pelo host (roteador).
OUTPUT: pacotes originados localmente.
POSTROUTING: depois do roteamento; onde ocorre SNAT/MASQUERADE.

3. Conceitos

Firewalls modernos são stateful — eles acompanham o estado de cada conexão, evitando que você escreva regras inutilmente repetitivas. O conntrack mantém uma tabela com o estado atual de cada fluxo, e as regras podem filtrar com base nela.

Os principais estados são:

NEW: Pacote que inicia uma conexão nova.
ESTABLISHED: Pacote pertencente a uma conexão já estabelecida.
RELATED: Fluxos auxiliares, como conexões de dados no FTP ou ICMP gerado por outra sessão.
INVALID: Pacotes sem contexto válido (checksum errado, sem associação).
UNTRACKED: Pacotes deliberadamente excluídos do mecanismo de estado.

Esses poucos estados já permitem construir políticas robustas, reduzindo o risco de bloquear respostas legítimas.

4. Regras essenciais

A política recomendada consiste em adotar uma postura restritiva por padrão (default-deny), permitindo apenas o tráfego declarado como necessário. As regras de exceção devem incluir o tratamento adequado para fluxos estabelecidos e relacionados, garantindo que respostas legítimas circulem sem interrupções.

iptables -P INPUT DROP
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

Essa base funciona em servidores, roteadores e appliances dedicados: elimina ruído, traz clareza e reduz a superfície de ataque.

5. Implementando DMZ, LAN e convidados

Antes de escrever regras, é essencial entender o papel de cada rede:

LAN interna
Rede de confiança maior, onde ficam hosts corporativos e serviços não expostos. Normalmente, só ela acessa a DMZ ou Internet com menos restrições.
Rede de convidados
Segmento isolado para dispositivos não confiáveis — visitantes, IoT, equipamentos pessoais. Essa rede deve alcançar apenas a Internet, nunca a LAN.
DMZ (zona desmilitarizada)
Segmento intermediário criado para hospedar serviços que precisam ser acessados de fora, mas que não devem expor a rede interna caso sejam comprometidos.
A DMZ não é “meio LAN, meio Internet” — é uma rede própria, projetada com regras específicas:
- Entrada da Internet → acesso estritamente filtrado
- Acesso da LAN → permitido apenas ao serviço necessário (ex.: SSH restrito aos admins)
- Saída da DMZ → limitada; servidores comprometidos não devem alcançar a LAN

Em termos práticos, se você tem servidores web e de e-mail públicos, eles vão para a DMZ. A LAN nunca confia cegamente neles. A rede de convidados, menos ainda.

Regras típicas:

# Internet → DMZ (somente portas públicas)
iptables -A FORWARD -i eth_wan -o eth_dmz -p tcp --dport 80 -j ACCEPT
iptables -A FORWARD -i eth_wan -o eth_dmz -p tcp --dport 443 -j ACCEPT

# DMZ → LAN (geralmente bloqueado)
iptables -A FORWARD -i eth_dmz -o eth_lan -j DROP

# LAN → DMZ (administração controlada)
iptables -A FORWARD -i eth_lan -o eth_dmz -p tcp --dport 22 -j ACCEPT

# Convidados → Internet (permitido)
iptables -A FORWARD -i eth_guest -o eth_wan -j ACCEPT

# Convidados → LAN/DMZ (bloqueado)
iptables -A FORWARD -i eth_guest -o eth_lan -j DROP
iptables -A FORWARD -i eth_guest -o eth_dmz -j DROP

A ideia é simples: cada rede tem um “perímetro” com intenções diferentes, e o firewall é quem materializa essas intenções.

6. Logging

Logs ajudam a depurar políticas complexas, mas devem ser usados com cuidado para evitar spam:

iptables -A INPUT -j LOG --log-prefix "FIREWALL_DROP: "

É útil adicionar essa regra em pontos estratégicos: logo antes do DROP final, ou na chain que filtra tráfego crítico.

7. Testes

As ferramentas de diagnóstico dão mais contexto do que as regras em si:

nmap entre redes
Mostra portas expostas, rotas funcionando e filtragem consistente. Se algo aparece “filtered”, talvez o firewall esteja bloqueando silenciosamente.
tcpdump
Revela se o pacote chega na interface certa, o que muitas vezes resolve dúvidas antes mesmo de olhar o firewall.
tcpdump -i eth_dmz host 10.10.0.10 ajuda a confirmar se o tráfego está entrando e saindo pelo caminho planejado.

8. Erros comuns

Alguns clássicos:

Regras na chain errada: Tentar filtrar pacotes destinados a outro host na chain INPUT, quando deveria ser FORWARD.
Ordem incorreta: Uma regra muito permissiva acima do bloqueio anula toda a camada de segurança.
Falta de rota de retorno: Pacote entra, mas não consegue voltar — o firewall parece o culpado, mas o problema está no roteamento.
Log excessivo: Um LOG mal colocado cria um fluxo infinito de mensagens, tornando o servidor lento e mascarando problemas reais.

Saber identificar esses padrões economiza horas em diagnósticos.

9. Conclusão

Um firewall eficiente não é uma lista interminável de regras, mas um conjunto de decisões claras sobre como cada rede deve se comportar. Entender o fluxo do kernel, o papel das chains e a lógica stateful são os pilares para montar políticas consistentes — da simples proteção de um servidor pessoal até o isolamento de uma DMZ inteira. Organizando as regras com propósito, você constrói redes mais seguras, previsíveis e fáceis de manter.

(6/8) DHCP: IPv4, IPv6, Reservas e Boas Práticas

Levi Gomes — Mon, 08 Dec 2025 19:07:57 +0000

1. Introdução

Gerenciar endereços manualmente funciona em redes pequenas, mas se torna impraticável quando dezenas de dispositivos entram e saem o tempo todo. O DHCP oferece distribuição automática de endereços IPv4, definição de gateway, DNS e outros parâmetros fundamentais de conectividade. Além de reduzir erros humanos, ele centraliza o controle da rede e permite ajustes coordenados. Em IPv6, ele convive com mecanismos autônomos como SLAAC, criando um ambiente mais flexível — mas também mais propenso a erros se não houver clareza de papéis.

2. Arquitetura do DHCP

O fluxo básico do DHCPv4 segue o modelo DORA: o cliente envia um Discover, anunciando que precisa de um endereço; o servidor responde com um Offer contendo um IP disponível; o cliente confirma com um Request e, por fim, o servidor conclui com Ack. Esse processo renova-se periodicamente, o que mantém endereços confiáveis mesmo em redes dinâmicas.

No IPv6, o DHCPv6 não substitui outros mecanismos — ele complementa. O endereço base normalmente chega ao host por SLAAC, um mecanismo no qual o roteador anuncia um prefixo via RA (Router Advertisement) e o cliente monta o próprio endereço a partir dele. Isso torna a rede mais autônoma, mas não resolve tudo: o RA não entrega informações como DNS interno, domínio de busca ou opções específicas da rede. É aí que o DHCPv6 entra, fornecendo esses parâmetros adicionais.

Essa divisão de responsabilidades funciona bem quando planejada, mas vira um problema em ambientes mistos ou mal configurados. Um roteador pode anunciar que “SLAAC é suficiente”, enquanto o servidor DHCPv6 tenta fornecer DNS ao mesmo tempo. Alguns hosts seguem fielmente o RA e ignoram o DHCPv6; outros fazem o oposto. O resultado é uma rede com comportamentos imprevisíveis: máquinas que conseguem navegar, mas não resolvem nomes internos, ou servidores que falham esporadicamente porque perderam o DNS de referência. Entender como SLAAC e DHCPv6 se sobrepõem — e decidir quem faz o quê — é decisivo para evitar esses cenários difíceis de diagnosticar.

3. Configuração do servidor (isc-dhcp)

Um exemplo de configuração para a sub-rede 10.20.0.0/24, respeitando a topologia usada nos artigos anteriores:

subnet 10.20.0.0 netmask 255.255.255.0 {
    range 10.20.0.50 10.20.0.200;
    option routers 10.20.0.1;
    option domain-name "empresa.lan";
    option domain-name-servers 10.20.0.5;
}

Aqui, o servidor distribui endereços de .50 a .200, deixando a faixa inicial reservada para equipamentos fixos — roteadores, servidores e dispositivos críticos. O DNS interno assumido é 10.20.0.5, e o gateway padrão 10.20.0.1.

4. Reservas - como planejar e por que usar

Reservas mapeiam um endereço IP a um MAC específico, garantindo previsibilidade sem abrir mão da automação. Diferente de um IP estático configurado no próprio host, uma reserva mantém administração centralizada: se você alterar o DNS da rede, o host reservado também herda a mudança sem intervenção manual.

Um conjunto típico de reservas na sua topologia poderia ser:

host servidor_web {
    hardware ethernet 00:11:22:33:44:55;
    fixed-address 10.20.0.10;
}

host servidor_dns {
    hardware ethernet aa:bb:cc:dd:ee:ff;
    fixed-address 10.20.0.5;
}

host roteador_x {
    hardware ethernet 66:77:88:99:aa:bb;
    fixed-address 10.20.0.2;
}

Esses exemplos seguem a lógica da rede construída nos artigos anteriores: o servidor web em .10, o DNS interno em .5, o roteador X em .2. Manter as reservas organizadas e agrupadas por função evita confusões durante a manutenção e facilita depuração, especialmente quando múltiplos equipamentos usam bridges, VLANs ou múltiplas interfaces.

5. Testes práticos

O teste mais direto é acionar manualmente o cliente DHCP e observar o ciclo completo de negociação. Ao executar:

dhclient -v eth0

O host inicia o processo enviando um DHCP Discover em broadcast, anunciando: “estou aqui, alguém pode me oferecer um endereço?”. O servidor que estiver ativo na rede responde com um DHCP Offer, propondo um IP e parâmetros de rede. Em seguida, o cliente envia um Request confirmando qual oferta escolheu — mesmo que só exista uma — e o servidor fecha o ciclo com o Ack, oficializando a concessão.

A flag -v revela cada etapa desse diálogo, facilitando a identificação de conflitos, atrasos ou ofertas vindas do servidor errado.

Para enxergar o que acontece no lado do servidor, você pode acompanhar os logs em tempo real:

journalctl -u isc-dhcp-server -f

Aqui aparecem mensagens como “DHCPDISCOVER from XX:XX:XX…” ou “DHCPOFFER on 10.20.0.80 to XX:XX:XX…”, permitindo verificar se o servidor está respondendo, se está respeitando as reservas ou se há outro serviço indesejado competindo na rede. É um teste simples, mas que costuma resolver boa parte das dúvidas quando o DHCP parece “não pegar”.

6. Erros comuns e como reconhecê-los

Um dos problemas mais frequentes é ter dois servidores DHCP ativos na mesma rede, muitas vezes um roteador doméstico esquecido ou uma VM mal configurada. O sintoma clássico é clientes recebendo IPs inconsistentes ou gateways errados.

Outro erro recorrente ocorre quando SLAAC distribui um prefixo IPv6 automático enquanto o administrador espera que DHCPv6 forneça DNS. O host então recebe endereço via SLAAC, mas não recebe DNS via DHCPv6 e perde resolução interna.

Por fim, ranges mal definidos — como incluir o IP do gateway dentro do pool — geram conflitos que só aparecem após renovações.

7. Conclusão

DHCP é simples na superfície, mas seu impacto na estabilidade da rede é profundo. Ele centraliza a distribuição de parâmetros fundamentais, suporta reservas para equipamentos essenciais e convive com mecanismos automáticos do IPv6. Um ambiente previsível exige ranges bem planejados, reserva para hosts críticos e vigilância constante sobre quem está realmente anunciando leases na rede. Seguindo boas práticas desde o início, você evita conflitos difíceis de rastrear e ganha um ambiente coerente em todos os níveis — do roteamento ao DNS.

(5/8) DNS: Resolver, Autoritativo e Zona Interna

Levi Gomes — Mon, 08 Dec 2025 19:07:14 +0000

1. Introdução

Apesar de parecer simples — transformar nomes em endereços IP — o DNS é um dos pilares mais delicados de qualquer rede. Sem ele, serviços continuam online, mas se tornam invisíveis. A diferença entre um ambiente funcional e um cheio de timeouts costuma ser uma configuração de DNS mal feita, seja por falta de servidores internos, falta de separação entre consultas internas/externas ou erros básicos na zona. Entender DNS significa entender como o tráfego realmente se orienta dentro da sua rede.

2. Hierarquia do DNS

A hierarquia do DNS é distribuída e cooperativa. No topo estão os root servers, que não respondem nomes, mas indicam o caminho. Abaixo deles ficam os TLDs (.com, .org, .br). Cada domínio registrado aponta para seus servidores autoritativos, que têm a palavra final sobre os registros daquela zona.

Quando uma máquina faz uma consulta, ela não fala diretamente com essa hierarquia — quem assume esse papel é o resolvedor recursivo (geralmente seu roteador, seu provedor ou um servidor interno da empresa). Ele percorre a cadeia: pergunta ao root “quem sabe sobre .com?”, pergunta ao TLD “quem sabe sobre exemplo.com?” e finalmente consulta o servidor autoritativo do domínio. Só então devolve a resposta ao cliente.

Essa separação entre recursivo (que busca) e autoritativo (que decide) é fundamental quando montamos DNS interno, porque a mesma máquina pode desempenhar um papel, o outro, ou ambos — e isso afeta diretamente a forma como a rede resolve nomes.

3. Entendendo uma consulta real com `dig`

Uma consulta real ajuda a visualizar tudo isso. Exemplo:

> dig dev.to

; <<>> DiG 9.10.6 <<>> dev.to
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65291
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;dev.to.                IN  A

;; ANSWER SECTION:
dev.to.         245 IN  A   151.101.2.217
dev.to.         245 IN  A   151.101.194.217
dev.to.         245 IN  A   151.101.130.217
dev.to.         245 IN  A   151.101.66.217

;; Query time: 9 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Mon Dec 08 15:34:10 -03 2025
;; MSG SIZE  rcvd: 99

Elementos essenciais do output:

QUESTION SECTION: O que foi perguntado. Útil para ver se não houve anexação de sufixos automáticos.
ANSWER SECTION: Resposta final, geralmente contendo um registro A/AAAA ou um CNAME.
AUTHORITY SECTION: Indica quais servidores são responsáveis pela zona consultada caso a resposta venha de delegação.
ADDITIONAL SECTION: Traz informações extras, como endereços IP dos servidores autoritativos.
Query time: Mostra se há lentidão na recursão.
SERVER: Indica qual resolvedor respondeu; isso revela rapidamente se o cliente está consultando DNS interno ou o DNS do provedor sem querer.

Essa leitura ajuda a detectar loops, consultas externas indevidas e comportamentos que escapam da topologia planejada.

4. Montando um DNS interno com Bind9

Ambientes corporativos normalmente mantêm um DNS interno para resolver nomes que não devem — e nem podem — existir no DNS público. Isso inclui servidores internos, serviços administrativos, endereços de infraestrutura e aliases operacionais.

Para isso, define-se uma zona autoritativa privada, carregada somente pelos servidores internos.

Definição da zona no named.conf.local:

zone "empresa.lan" {
    type master;
    file "/etc/bind/db.empresa.lan";
};

zone "empresa.lan" — nome da zona. É o sufixo que todos os registros vão compartilhar.
type master — indica que este servidor é a origem autoritativa da zona.
file — caminho do arquivo de zona.

Um arquivo de zona simples pode conter:

$TTL 86400
@       IN  SOA ns1.empresa.lan. admin.empresa.lan. (
            2025010101 ; serial
            3600       ; refresh
            1800       ; retry
            604800     ; expire
            86400      ; minimum
)

IN  NS      ns1.empresa.lan.

; Registros A (IPv4)
ns1     IN  A       10.20.0.2
host1   IN  A       10.20.0.10
nginx   IN  A       10.20.0.20

; Registros AAAA (IPv6)
webv6   IN  AAAA    fd00:20::50

; Alias / CNAME
api     IN  CNAME   nginx.empresa.lan.

; Serviço fictício para demonstrar registros mistos
db      IN  A       10.20.0.30
db      IN  AAAA    fd00:20::30

Vamos olhar em detalhes cada parte:

$TTL 86400
Tempo padrão de cache para todos os registros que não tiverem TTL próprio.

@ IN SOA ns1.empresa.lan. admin.empresa.lan. ( ... )
O registro SOA (Start of Authority) define a origem autoritativa da zona.

ns1.empresa.lan.: servidor responsável pela zona
admin.empresa.lan.: contato do administrador (o "@" vira um ponto)
serial: número de versão da zona, que deve ser incrementado a cada mudança
refresh, retry, expire, minimum: parâmetros de controle de cache e atualização

IN NS ns1.empresa.lan.
Lista os servidores que respondem pela zona.
Em ambientes internos, normalmente só existe um servidor, mas pode haver redundância.

ns1     IN  A       10.20.0.2
host1   IN  A       10.20.0.10
nginx   IN  A       10.20.0.20

Associa um nome a um endereço IPv4.
Base de qualquer resolução dentro de LANs.

webv6 IN AAAA fd00:20::50
Associa um nome a um endereço IPv6.
Usado quando a rede interna já opera com IPv6 — especialmente útil para testes.

api IN CNAME nginx.empresa.lan.
Define um apelido: api.empresa.lan → nginx.empresa.lan.

o CNAME redireciona o nome, não o IP;
um nome que é CNAME não pode ter outros registros A/AAAA/NS/MX;
útil para abstrair serviços (“api”, “db”, “mail”), permitindo mover o backend sem quebrar clientes.

db      IN  A       10.20.0.30
db      IN  AAAA    fd00:20::30

O nome db.empresa.lan tem resoluções distintas para IPv4 e IPv6.
Clientes dual-stack escolhem de acordo com a pilha habilitada.

5. Reverse DNS (PTR) — quando faz sentido

O reverse é o oposto do DNS convencional: dado um IP, retorna o nome. Ele vive em zonas como:

0.20.10.in-addr.arpa

Em redes internas ele não é obrigatório, mas é extremamente útil para logs, auditoria, integração com sistemas de e-mail e ferramentas de monitoramento. Sem PTR, várias interfaces aparecem só com IP, o que dificulta depuração e análise de tráfego.

6. Testando corretamente

O teste mais confiável é direcionar a consulta explicitamente ao servidor interno:

dig @10.20.0.2 host1.empresa.lan

Depois, teste a cadeia completa fazendo consultas externas e internas do mesmo cliente para garantir que:

nomes públicos continuam resolvendo via resolvedor externo;
nomes internos não vazam para a Internet;
o cliente está usando o DNS correto (verifique a seção “SERVER” no dig);
forwarders do Bind9 estão funcionando (em casos em que ele também atua como resolvedor).

Use tcpdump se precisar observar se pedidos internos estão escapando para fora — problema comum causado por má configuração de search domains ou múltiplos DNS no /etc/resolv.conf.

7. Problemas frequentes e como identificá-los

Leak de DNS: clientes internos enviam consultas para DNS públicos. Sintomas: lentidão, respostas inconsistentes, falha em resolver nomes internos.
Servidor interno sem forwarders: consultas para domínios externos demoram ou falham porque o Bind9 só atua como autoritativo, não como recursivo.
Zona mal definida: SOA incorreto, serial não incrementado, registros ausentes, TTLs exagerados. Tudo isso faz com que mudanças não propaguem ou causem respostas erradas.

Esses problemas não são óbvios no início, mas se tornam triviais quando você olha o dig com atenção.

8. Conclusão

DNS só parece simples à distância. Quando você entende o papel dos resolvedores, da hierarquia e das zonas internas, percebe que uma rede estável depende de um DNS coerente e bem isolado. Montar um servidor interno não é complicado, mas exige disciplina: manter zonas organizadas, testar rotas de consulta e garantir que nenhum cliente escape para fora da estrutura planejada. Uma base sólida de DNS deixa todo o restante — roteamento, firewall, serviços — mais previsível e muito menos sujeito a falhas silenciosas.

(4/8) NAT: Entendendo SNAT, DNAT e MASQUERADE

Levi Gomes — Mon, 08 Dec 2025 19:06:52 +0000

1. Por que NAT existe

O NAT nasceu como uma resposta direta ao esgotamento do IPv4—mas isso nunca foi tudo. Ele também virou uma ferramenta de isolamento, pois permite que redes internas usem endereços privados, enquanto um único endereço público faz a ponte com a Internet. Isso dá controle sobre o tráfego de saída, reduz exposição e mantém a topologia interna invisível para o mundo externo. Em ambientes domésticos e corporativos, NAT é o que torna possível que dezenas ou centenas de dispositivos compartilhem o mesmo IP público sem colapsar a estrutura de endereçamento.

2. Tipos de NAT

SNAT (Source NAT) altera o endereço de origem de um pacote. É usado quando sua máquina ou sua rede interna precisa “sair” para outra rede, normalmente a Internet. O roteador substitui o IP privado pelo IP público e registra a tradução para conseguir reverter na volta.
MASQUERADE é um SNAT “dinâmico”, pensado para interfaces com IP variável (como DHCP ou PPPoE). Ele recalcula o IP de saída sempre que necessário, e por isso é a escolha comum em roteadores domésticos ou máquinas com IP público não fixo.
DNAT (Destination NAT) faz o caminho inverso: altera o endereço de destino de um pacote que chega pela interface externa. É a base do port forwarding. Um pacote destinado ao IP público na porta 80, por exemplo, pode ser redirecionado para um servidor interno em outra rede — algo obrigatório em ambientes que usam endereços privados.

3. A tabela de estado (conceito chave)

O NAT só funciona de forma confiável porque o roteador acompanha cada fluxo individualmente. A tradução de endereços não é estática nem contínua — ela é específica a cada conexão.

⬆️ Por isso, sempre que um pacote sai da rede interna em direção à Internet, o roteador:

1) Detecta um novo fluxo.
Identifica 5-tuple: IP_origem, porta_origem, IP_destino, porta_destino, protocolo.
2) Aplica a tradução de saída (normalmente no POSTROUTING).
Ex.: 10.0.1.20:42831 → 200.200.200.10:55000.
3) Registra esse mapeamento na conntrack table.
É isso que será consultado no caminho de volta.

Esse registro é uma entrada com estado próprio, incluindo tempo de expiração, flags de protocolo (SYN/ACK/FIN no TCP, por exemplo), portas traduzidas, e o estado atual do fluxo.

⬇️ No caminho de retorno, o processo é o inverso:

1) O roteador recebe um pacote destinado ao IP público e à porta traduzida.
2) Consulta a tabela e encontra:
200.200.200.10:55000 → 10.0.1.20:42831
3) Restaura os valores originais e entrega o pacote ao host interno certo.

Sem a tabela, esse pacote voltaria “cego”: não há nada no cabeçalho que identifique qual host interno iniciou o fluxo.

A simetria entre como o pacote sai e como volta existe só porque a tabela mantém estado

O NAT depende fundamentalmente do rastreamento de estado (stateful connection tracking). Quando o host envia um pacote para fora da sua rede, o roteador NAT executa a tradução no momento de saída, substituindo o endereço e — se necessário — a porta de origem por um par público. Esse é o instante em que o roteador cria uma entrada na tabela de estado, registrando o mapeamento completo: endereço interno, endereço público usado, destino externo e o protocolo envolvido.

Tráfego de saída:

Tráfego de retorno:

Essa tabela funciona como um mapa de retorno: quando um pacote chega da Internet destinado ao IP público, o roteador consulta o registro correspondente e restaura os valores originais, entregando o tráfego ao host correto dentro da rede interna.

Já a tabela conntrack representa o coração do NAT. Cada linha corresponde a um fluxo ativo, indicando exatamente como o pacote de ida foi traduzido e como o pacote de volta deve ser restaurado. Mesmo com um único host, fica claro o princípio fundamental: o roteador depende dessa tabela para garantir consistência entre ida e retorno, preservando o fluxo TCP/UDP como se a comunicação fosse direta, apesar da tradução intermediária.

4. Configurações no Linux

Abaixo estão exemplos práticos para cada tipo de NAT usando iptables.

Cenário 1 — Saída padrão para a Internet (MASQUERADE):

Rede interna 10.10.0.0/24 sai para a Internet pela interface eth0, com IP dinâmico.

iptables -t nat -A POSTROUTING -s 10.10.0.0/24 -o eth0 -j MASQUERADE

Uso típico em gateways domésticos ou laboratoriais, quando o endereço público pode mudar.

Cenário 2 — Saída com IP público fixo (SNAT):

Servidor de borda tem IP público estático 203.0.113.5, e todos os hosts internos devem sair usando esse endereço.

iptables -t nat -A POSTROUTING -s 10.10.0.0/24 -o eth0 -j SNAT --to-source 203.0.113.5

Evita o overhead do MASQUERADE e garante consistência para logs e firewalls externos.

Cenário 3 — DNAT simples para um servidor web interno:

Qualquer tráfego que chega ao IP público na porta 80 deve ir para 10.10.0.10:80 na DMZ.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 10.10.0.10:80

Clássico port forwarding, usado em servidores web expostos.

Cenário 4 — Redirecionar SSH externo para um bastion host

Acesso SSH público na porta 2222 deve ser encaminhado para o host interno 10.10.0.50:22.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 2222 -j DNAT --to-destination 10.10.0.50:22

Evita expor diretamente máquinas internas e permite controle mais estrito no firewall.

Cenário 5 — Dois serviços internos compartilhando o mesmo IP público

Chegadas em 80 → servidor A;
Chegadas em 443 → servidor B.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 10.10.0.10:80
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 10.10.0.20:443

Mostra como o roteador pode “demultiplexar” serviços distintos por porta.

Cenário 6 — SNAT específico para um host ou serviço interno

Um servidor interno (10.10.0.30) precisa sair para a Internet com um IP secundário público 203.0.113.6, diferente do restante da rede.

iptables -t nat -A POSTROUTING -s 10.10.0.30 -o eth0 -j SNAT --to-source 203.0.113.6

Muito usado quando se quer segmentar logs, reputação de IP ou tráfego de e-mail.

5. Testes

O jeito mais simples é abrir um curl a partir de uma máquina externa e verificar se o tráfego chega corretamente ao host interno.

Se quiser observar o processo mais de perto, tcpdump na interface externa revela a porta traduzida e os fluxos acontecendo em tempo real.

Esse tipo de inspeção ajuda muito a entender se o problema é de NAT ou de firewall.

6. Erros comuns

Duplo NAT sem necessidade:
Duas camadas fazendo SNAT criam fluxos difíceis de rastrear e dificultam depuração.

Errado ❌: roteador da operadora + seu roteador, ambos fazendo NAT.
Correto ✅: apenas o equipamento de borda fazendo NAT; o segundo só roteia.

NAT sem rota de retorno:
A tradução funciona na ida, mas o retorno nunca encontra o caminho certo.

Errado ❌: DNAT para 10.0.0.10, mas o host 10.0.0.10 envia resposta para outro gateway.
Correto ✅: ajustar a rota padrão do servidor interno para apontar para o roteador que fez o DNAT.

MASQUERADE no lugar errado:
Ele tem que estar apenas na interface que leva ao destino externo.

Errado ❌: aplicar MASQUERADE numa interface interna.
Correto ✅: aplicar na interface de saída (geralmente WAN).

7. Conclusão

O NAT continua sendo uma solução prática para manter redes funcionando em um cenário de endereços escassos e topologias diversas. Ele resolve problemas reais de conectividade, mas exige atenção ao caminho do tráfego, à tabela de estado e ao alinhamento entre NAT, rotas e firewall. Quando tudo conversa bem, ele é quase invisível. Quando algo fica desalinhado, os sintomas aparecem imediatamente — pacotes sem retorno, serviços inacessíveis, fluxos presos. Entender a lógica interna do NAT torna esses problemas muito mais previsíveis e fáceis de resolver.

(3/8) Roteamento: Conceitos, Rotas Estáticas e Fluxo

Levi Gomes — Mon, 08 Dec 2025 19:04:26 +0000

1. Introdução

Roteamento é o mecanismo que permite que redes distintas se comuniquem de forma estruturada. Sem ele, o tráfego fica restrito ao próprio segmento local, mesmo que a topologia física conecte todas as máquinas. O papel do roteamento é determinar, para cada destino possível, qual é o próximo salto responsável por encaminhar o pacote. É essa simples ideia — escolher o caminho correto — que sustenta arquiteturas corporativas, nuvens privadas e praticamente toda troca de dados na internet.

2. Conceitos essenciais

Toda máquina possui uma tabela de roteamento, que nada mais é do que uma lista de caminhos possíveis. É ali que o sistema decide para onde enviar um pacote: se vai direto para a rede local ou se precisa passar por outro roteador. Essa tabela existe tanto nos hosts quanto nos roteadores — a diferença é que nos roteadores ela costuma ser bem mais rica.

A rota padrão é a regra para tudo que não se encaixa em nenhuma outra rota. Quando o host não reconhece a rede de destino, ele envia para o gateway padrão, confiando que ele saberá o caminho. Em redes simples, ela é quase invisível; em redes maiores, ela é o fio condutor que impede que o tráfego se perca.

Já a rota de rede define um caminho específico para um bloco de endereços. Por exemplo, se a rede 192.168.0.0/16 está atrás de um certo roteador, você adiciona uma rota apontando diretamente para esse roteador. Isso possibilita roteamento entre sub-redes, permitindo que máquinas em redes distintas se comuniquem sem depender de NAT ou gambiarras. É a base de todas as topologias profissionais, de datacenters a pequenos laboratórios.

3. Diagrama do fluxo

Quando um host envia um pacote ele executa duas operações simples e determinísticas:
1) verifica se o endereço de destino pertence ao mesmo prefixo configurado em sua interface (comparação IP vs. máscara);
2) se pertencer, envia diretamente ao destino resolvendo o MAC via ARP; se não pertencer, encaminha o pacote ao gateway configurado (default gateway).

O gateway (ou roteador) que recebe o pacote realiza uma busca na sua tabela de roteamento para decidir o próximo salto. Essa decisão usa o princípio do longest-prefix match: entre todas as rotas cuja rede contém o endereço de destino, a rota com o prefixo mais específico (maior comprimento de máscara) é escolhida. O roteador então encaminha o pacote para o próximo roteador ou, se a rede de destino estiver diretamente conectada a uma de suas interfaces, entrega localmente ao segmento destino. Esse processo se repete salto a salto até a entrega final.

O diagrama ilustra a primeira decisão feita pelo host (entrega direta se o destino pertence ao mesmo prefixo; caso contrário, encaminhamento ao gateway). O roteador aplica então um algoritmo de seleção de rota baseado em longest-prefix match na sua tabela de roteamento para escolher o próximo salto até a rede destino.

4. Configuração de rotas

Via iproute2 (temporário):

ip route add 192.168.0.0/16 via 10.20.0.1

Permanente no /etc/network/interfaces:

post-up ip route add 192.168.0.0/16 via 10.20.0.1

Esse padrão é valioso porque deixa o comportamento previsível após cada reboot. Você sabe exatamente quais rotas entrarão em cena, sem depender de scripts externos ou configurações dispersas pelo sistema.

5. Testando o roteamento

O traceroute revela cada salto entre a origem e o destino. Ele funciona enviando pacotes com TTL (tempo de vida) crescente. Cada roteador reduz 1 desse TTL e, quando ele chega a zero, o roteador responde — expondo sua posição no caminho. É uma forma elegante de ver onde o tráfego realmente está passando.

Já o tcpdump permite observar o trânsito real na interface. Ao escutar a interface de saída, você confirma se os pacotes estão seguindo o caminho que deveriam. É a ferramenta que tira qualquer dúvida: se o pacote aparece ali, você sabe que sua rota está ativa; se não aparece, a tabela de roteamento ou o firewall estão interferindo.

6. Erros comuns

Gateway fora da rede local ❌:

Host 10.0.1.10/24 com gateway 10.0.2.1.
O host nunca conseguirá enviar pacotes ao gateway, porque ele acredita que 10.0.2.1 está fora da sua rede local e tentará encontrar outro gateway que não existe.

Gateway correto ✅:

Host 10.0.1.10/24 com gateway 10.0.1.1.
O gateway está na mesma sub-rede; a ARP resolve seu endereço e o tráfego flui.

Rotas sobrepostas ❌:

ip route add 192.168.0.0/16 via 10.10.0.1
ip route add 192.168.1.0/24 via 10.20.0.1

A segunda rota é mais específica e substitui parte da primeira silenciosamente. O administrador pode achar que todo o /16 vai para 10.10.0.1, quando na verdade só o restante do /16 irá; o /24 será roteado por outro caminho.

Rotas planejadas ✅:

Especificar claramente o papel de cada rota: prefixos amplos para caminhos gerais, prefixos estreitos para exceções intencionais.

Ausência de rota de retorno ❌:

Rede A sabe enviar para Rede B, mas Rede B envia tudo para o gateway padrão, que não sabe retornar à Rede A.
Resultado: o tráfego “vai”, mas não “volta”.

Caminho bidirecional ✅:

Ambas as redes possuem rotas explícitas uma para a outra — seja diretamente, seja via o mesmo roteador intermediário.

7. Conclusão

Rotas bem definidas tornam a rede previsível: cada salto segue uma lógica clara, e cada decisão pode ser observada com ferramentas simples. Entender esse comportamento remove a sensação de aleatoriedade que muitos iniciantes têm quando veem pacotes atravessando a infraestrutura. À medida que você começa a testar, ajustar e analisar o tráfego, o roteamento passa a se encaixar como uma engrenagem sólida, onde pequenos detalhes — como máscaras, rotas específicas e gateways corretos — fazem toda a diferença.

Com essa base consistente, o próximo tema ganha clareza: NAT, que depende totalmente de um roteamento correto para funcionar e é justamente onde muitos erros aparecem quando a fundação não está bem estabelecida.

(2/8) IPv4 e IPv6: Conceitos, Configuração e Testes

Levi Gomes — Mon, 08 Dec 2025 19:03:57 +0000

1. Introdução

Antes de pensar em roteamento, firewall ou qualquer outro serviço, tudo começa pelo endereçamento. É aqui que uma máquina “descobre” onde ela está dentro da rede e como alcançar o resto do mundo. Se esse ponto ficar nebuloso, o restante desmorona. Por isso, este artigo mergulha no básico sem enrolação: entender como IPv4 e IPv6 organizam o espaço de endereços e como colocar isso para funcionar no Linux de forma direta.

2. Conceitos fundamentais de IPv4

O IPv4 organiza a rede dividindo o espaço de endereços em blocos. A ideia de máscara de rede surgiu exatamente para isso: separar o que é “parte da rede” e o que é “parte dos hosts”. Por exemplo, uma máscara /24 diz que os primeiros 24 bits identificam a rede, e os 8 restantes ficam para as máquinas. Essa separação é o que permite que o sistema entenda se dois endereços estão na mesma rede local ou se precisam passar por um roteador.

O padrão CIDR simplifica essa notação e evita a antiga confusão das classes (A, B, C). Com CIDR, você é livre para definir redes do tamanho que quiser, desde um /8 gigantesco até um /30 quase individual. Essa flexibilidade foi crucial para organizar melhor os endereços conforme o IPv4 foi se aproximando da saturação.

Além disso, cada rede tem um endereço de broadcast, usado para enviar mensagens para todos os hosts ao mesmo tempo — útil para protocolos como ARP. E, claro, sempre existe um gateway padrão, o endereço do roteador que sabe para onde mandar tudo que não pertence à rede local. Sem esse gateway, a máquina vive isolada: conversa com os vizinhos, mas nunca alcança nada além.

3. Conceitos fundamentais de IPv6

O IPv6 surgiu para resolver a limitação de endereços e propor uma rede muito mais organizada. Nele, cada interface recebe automaticamente um endereço link-local (fe80::/10). Esse endereço sempre existe e serve para comunicação dentro do mesmo segmento, especialmente para descoberta de vizinhos — o equivalente ao ARP, só que bem mais limpo.

A partir daí, entram os endereços globais (válidos na internet) e os endereços ULA (fd00::/8), que são equivalentes ao “IPv6 privado”. Ambos são definidos por prefixos, que substituem a velha ideia de máscara. Assim como no IPv4, o prefixo determina o tamanho da rede, mas agora o espaço é tão amplo que você não precisa se preocupar com desperdício.

E o mais interessante é o mecanismo de autoconfiguração. No IPv6, o roteador pode anunciar o prefixo da rede usando RA (Router Advertisement), e os hosts conseguem montar seus próprios endereços sem precisar de servidor DHCP. Esse processo se chama SLAAC (Stateless Address Autoconfiguration). Quando você quer controle mais rígido — como registrar cada máquina — entra o DHCPv6, que complementa ou substitui o SLAAC. Nada impede usar os dois juntos, mas é importante saber que cada abordagem mexe de um jeito diferente no fluxo da rede.

4. Fluxo de comunicação (diagrama)

Quando um host precisa enviar um pacote, ele realiza primeiro uma decisão local de alcance: compara o endereço de destino com a sua própria configuração de rede (IP e máscara). Se o destino estiver dentro do mesmo prefixo, o pacote é entregue diretamente ao host de destino por meio de resolução de endereço (ARP). Caso contrário, o pacote é encaminhado ao gateway configurado na interface, que se torna o primeiro salto para alcançar redes externas. Essa decisão é puramente local ao host e antecede qualquer mecanismo de roteamento entre roteadores.

A figura ilustra o processo inicial de decisão feito por um host ao enviar um pacote. Primeiro, o host compara o endereço de destino com sua própria configuração de IP e máscara. Se o destino estiver no mesmo prefixo, a entrega é direta e depende apenas da resolução de endereço (ARP). Caso o endereço pertença a outra rede, o host não tenta descobrir o caminho por conta própria: ele encaminha o pacote ao gateway configurado, que se torna o primeiro salto para alcançar redes externas.

5. Configuração no Linux

Roteador DMZ/LAN:

auto lo
iface lo inet loopback

# WAN (via DHCP)
auto eth0
iface eth0 inet dhcp
iface eth0 inet6 auto

# DMZ – 10.10.0.0/24
auto eth1
iface eth1 inet static
    address 10.10.0.1
    netmask 255.255.255.0

iface eth1 inet6 static
    address fd00:a1b2::1
    netmask 64

# LAN INTERNA – 192.168.0.0/16
auto eth2
iface eth2 inet static
    address 192.168.0.1
    netmask 255.255.0.0

iface eth2 inet6 static
    address fd00:192::1
    netmask 64

# Ativar roteamento
post-up sysctl -w net.ipv4.ip_forward=1
post-up sysctl -w net.ipv6.conf.all.forwarding=1

Roteador LAN/Convidados:

auto lo
iface lo inet loopback

# LAN INTERNA – 192.168.0.0/16
auto eth0
iface eth0 inet static
    address 192.168.0.2
    netmask 255.255.0.0
    gateway 192.168.0.1

iface eth0 inet6 static
    address fd00:192::2
    netmask 64
    gateway fd00:192::1

# CONVIDADOS – 172.30.10.0/24
auto eth1
iface eth1 inet static
    address 172.30.10.1
    netmask 255.255.255.0

iface eth1 inet6 static
    address fd00:172::1
    netmask 64

# Ativar roteamento
post-up sysctl -w net.ipv4.ip_forward=1
post-up sysctl -w net.ipv6.conf.all.forwarding=1

6. Testes

O ping (e o ping6) são ferramentas básicas para testar conectividade. Eles enviam mensagens ICMP e esperam resposta. Se chegar, ótimo: há comunicação. Se não chegar, você sabe que existe algum bloqueio, rota errada ou interface mal configurada. É o primeiro degrau da análise.

Os comandos ip -4 addr e ip -6 addr mostram exatamente quais endereços suas interfaces receberam. Isso evita surpresas, especialmente no IPv6, onde você pode acabar com múltiplos endereços — estático, SLAAC, temporário — e nem sempre perceber que está usando o errado.

Já o traceroute (e seu equivalente IPv6) revela o caminho que os pacotes percorrem até o destino. Cada salto (hop) é um roteador no meio do caminho. Ele ajuda a diagnosticar onde o tráfego está sendo interrompido ou desviado. Em redes internas ou simples, o trajeto é curto; em redes maiores, entender esse mapa faz toda a diferença.

7. Erros comuns

Um erro frequente é ativar IPv6 estático e SLAAC ao mesmo tempo sem saber o efeito disso. A máquina pode acabar com vários endereços e, pior, usar um inesperado na hora de enviar pacotes. Outro problema clássico é configurar o gateway IPv6 como se fosse IPv4: no IPv6, o gateway precisa ser sempre um endereço link-local, e isso confunde quem está começando.

Também é comum usar prefixos errados, especialmente quando se está migrando de IPv4. No IPv6, praticamente toda rede interna usa /64. Colocar /80 ou /112 porque “parece suficiente” quebra recursos básicos da rede, incluindo SLAAC.
E claro: máscaras incorretas no IPv4 levam a rotas mal calculadas, hosts que não conversam entre si e diagnósticos que parecem mágicos — mas não são.

8. Conclusão

Com IPv4 e IPv6 bem configurados, o resto da rede deixa de ser um labirinto. Nos próximos capítulos, tudo começa a se encaixar: roteamento, NAT, DNS, DHCP… e cada parte depende diretamente de um endereçamento sólido e bem planejado.

(1/8) Fundamentos, Objetivos e Arquitetura da Infraestrutura de Rede

Levi Gomes — Mon, 08 Dec 2025 19:01:47 +0000

1. Contexto e Motivação

A administração de redes em Linux permanece como um dos pilares mais sólidos tanto para estudantes de ciência da computação quanto para empresas que buscam autonomia na própria infraestrutura. Mesmo com a popularização de serviços gerenciados e nuvens públicas, entender como uma rede opera por baixo dos panos continua sendo uma habilidade diferencial: facilita o diagnóstico, reduz custos, fortalece a segurança e forma profissionais mais completos.

Esta série tem o objetivo de construir, passo a passo, uma infraestrutura de rede funcional usando apenas Linux — não como um tutorial solto de comandos, mas como uma explicação estruturada, onde cada decisão técnica está amarrada a uma justificativa conceitual e a um padrão arquitetural adotado no mundo real.

2. Objetivos da série

A proposta central é dupla:

Ensinar redes “de verdade”, e não só o mínimo para funcionar.
Cada etapa — endereçamento, roteamento, NAT, DNS, DHCP, firewall — será explorada tanto como tecnologia quanto como parte de uma arquitetura coerente.
Relacionar a prática com boas práticas profissionais.

A série será útil para estudantes que querem entender profundamente por que as coisas funcionam, profissionais que precisam estruturar serviços internos de forma robusta e equipes pequenas que buscam implantar redes internas previsíveis e seguras.

Assim, cada configuração será acompanhada de explicações sobre isolamento de redes, padronização de faixas, segurança mínima aceitável, práticas de DMZ, logging e testes reais.

3. O que será construído

Vamos propor e implementar uma arquitetura típica de empresas pequenas ou ambientes de laboratório — suficiente para ilustrar decisões reais, mas simples o bastante para ser montada em qualquer computador usando máquinas virtuais.

A série completa abordará:

IPv4 e IPv6
roteamento entre sub-redes
NAT e exposição controlada de serviços
DNS interno
DHCP
firewall e políticas de isolamento
testes integrados, troubleshooting e validação da infraestrutura

Cada tema será tratado como um bloco independente, mas que se conecta aos demais para formar a infraestrutura final.

4. Planejando a infraestrutura fictícia

Antes de configurar qualquer serviço, definimos um cenário representativo de um ambiente corporativo pequeno com três zonas:

DMZ — onde ficam serviços expostos parcialmente ao público (web, e-mail, APIs).
LAN interna — onde trabalham usuários, aplicações internas e serviços administrativos.
Rede de convidados — rede isolada, sem acesso à LAN, usada por dispositivos temporários.

Essa separação segue um padrão amplamente utilizado: “dividir para controlar”.
Ao compartimentar funções de rede, diminuímos superfícies de ataque, facilitamos diagnóstico e deixamos regras de firewall mais legíveis.

5. Ambiente do laboratório

Toda a infraestrutura será construída sobre Linux, usando ferramentas nativas e amplamente utilizadas em ambientes profissionais.

Ferramentas usadas ao longo da série:

iproute2 — gerenciamento moderno de interfaces, rotas, ARP e tabelas.
bind9 — servidor DNS autoritativo e recursivo.
tcpdump — inspeção de pacotes para testes e debugging.
iptables/nftables — filtragem e NAT.
isc-dhcp-server — servidor DHCP simples e confiável.

A maioria dos comandos e configs funcionará da mesma forma em Ubuntu Server, Debian e derivados, que são bons alvos para laboratório.

6. Arquitetura da rede fictícia

Essa arquitetura é simples, mas permite explorar múltiplas sub-redes, roteamento interno, NAT só no ponto correto, DNS com zonas internas e firewall contextualizado com a função de cada rede.

7. Faixas de rede definidas

Para evitar sobreposição e manter estrutura clara, usaremos:

DMZ: 10.10.0.0/24
LAN interna: 192.168.0.0/16
Convidados: 172.30.10.0/24
IPv6: fd00:a1b2::/64

A escolha cobre os três blocos privados do IPv4 (A, B e C) e uma faixa local IPv6 com notação ULAs, que são adequadas para laboratórios e redes internas persistentes.

8. Organização dos arquivos de configuração

A ideia aqui é manter tudo limpo e fácil de entender. O arquivo /etc/network/interfaces vai ser nosso ponto de partida: é onde deixamos definidas as interfaces, seus endereços e as rotas que entram automaticamente quando a máquina sobe. Nada espalhado, nada perdido em scripts obscuros.

Os serviços que exigem configurações próprias — como DNS e DHCP — ficam separados, cada um no seu canto. Isso ajuda a visualizar melhor o papel de cada peça da rede sem transformar um único arquivo em um bloco confuso.

E, ao longo dos artigos, sempre que um conceito aparecer, ele virá acompanhado do comando que o materializa. A leitura fica natural: você entende a ideia, vê como ela se aplica e segue adiante sem tropeçar em camadas desnecessárias.

9. Conclusão e próximos passos

Este artigo definiu o cenário, os objetivos e os padrões que vamos seguir ao longo da série.
A partir do próximo artigo, começamos pela base de qualquer rede: IPv4 e IPv6, incluindo máscaras, CIDR, gateways, endereços link-local, diferenciação entre endereços locais e globais, e testes essenciais.

DEV Community: Levi Gomes

(8/8) Testes Finais, Troubleshooting e Encerramento

1. Objetivo

2. Checklist final

3. Encerramento: teoria aplicada e próximos passos

(7/8) Firewall: Estrutura, Fluxo e Políticas Reais

1. Motivação

2. Fluxo do kernel (diagrama)

3. Conceitos

4. Regras essenciais

5. Implementando DMZ, LAN e convidados

6. Logging

7. Testes

8. Erros comuns

9. Conclusão

(6/8) DHCP: IPv4, IPv6, Reservas e Boas Práticas

1. Introdução

2. Arquitetura do DHCP

3. Configuração do servidor (isc-dhcp)

4. Reservas - como planejar e por que usar

5. Testes práticos

6. Erros comuns e como reconhecê-los

7. Conclusão

(5/8) DNS: Resolver, Autoritativo e Zona Interna

1. Introdução

2. Hierarquia do DNS

3. Entendendo uma consulta real com dig

4. Montando um DNS interno com Bind9

5. Reverse DNS (PTR) — quando faz sentido

6. Testando corretamente

7. Problemas frequentes e como identificá-los

8. Conclusão

(4/8) NAT: Entendendo SNAT, DNAT e MASQUERADE

1. Por que NAT existe

2. Tipos de NAT

3. A tabela de estado (conceito chave)

Tráfego de saída:

Tráfego de retorno:

4. Configurações no Linux

Cenário 1 — Saída padrão para a Internet (MASQUERADE):

Cenário 2 — Saída com IP público fixo (SNAT):

Cenário 3 — DNAT simples para um servidor web interno:

Cenário 4 — Redirecionar SSH externo para um bastion host

Cenário 5 — Dois serviços internos compartilhando o mesmo IP público

Cenário 6 — SNAT específico para um host ou serviço interno

5. Testes

6. Erros comuns

7. Conclusão

(3/8) Roteamento: Conceitos, Rotas Estáticas e Fluxo

1. Introdução

2. Conceitos essenciais

3. Diagrama do fluxo

4. Configuração de rotas

5. Testando o roteamento

6. Erros comuns

Gateway fora da rede local ❌:

Gateway correto ✅:

Rotas sobrepostas ❌:

Rotas planejadas ✅:

Ausência de rota de retorno ❌:

Caminho bidirecional ✅:

7. Conclusão

(2/8) IPv4 e IPv6: Conceitos, Configuração e Testes

1. Introdução

2. Conceitos fundamentais de IPv4

3. Conceitos fundamentais de IPv6

4. Fluxo de comunicação (diagrama)

5. Configuração no Linux

6. Testes

7. Erros comuns

8. Conclusão

(1/8) Fundamentos, Objetivos e Arquitetura da Infraestrutura de Rede

1. Contexto e Motivação

2. Objetivos da série

3. O que será construído

4. Planejando a infraestrutura fictícia

5. Ambiente do laboratório

6. Arquitetura da rede fictícia

7. Faixas de rede definidas

8. Organização dos arquivos de configuração

3. Entendendo uma consulta real com `dig`