Roteamento básico para servidores: tabelas de rotas, rota padrão e rotas estáticas

O que é roteamento em um servidor (e por que você se importa)

Roteamento, no contexto de um servidor, é o processo de decidir por qual interface e para qual próximo salto (next-hop) cada pacote IP deve sair para alcançar um destino. Essa decisão é feita consultando a tabela de rotas. Mesmo um servidor “não roteador” precisa roteamento: ele envia tráfego para redes locais, para outras sub-redes internas e para a Internet.

O ponto central: para cada pacote, o sistema escolhe uma rota com base no destino IP e em regras de prioridade. Se a rota escolhida estiver errada (ou incompleta), você vê sintomas típicos: “consigo pingar o gateway, mas não a rede X”, “o serviço responde para alguns clientes e para outros não”, “o servidor inicia conexão, mas o retorno vem por outro caminho e some”.

Como o sistema escolhe a rota: correspondência de prefixo e prioridade

1) Regra do “prefixo mais específico” (longest prefix match)

Quando existem várias rotas que poderiam servir para um destino, o sistema escolhe a rota com o prefixo mais específico (aquela com a máscara/prefixo mais longo). Exemplo conceitual:

• Rota A: 10.10.0.0/16 via 192.168.1.1
• Rota B: 10.10.20.0/24 via 192.168.2.1

Para o destino 10.10.20.50, a rota B vence porque /24 é mais específico que /16.

2) Métrica (metric) e custo

Se duas rotas tiverem o mesmo prefixo, o sistema usa um critério de desempate, normalmente a métrica (quanto menor, melhor). A métrica pode ser configurada manualmente ou atribuída automaticamente (por exemplo, com base na interface).

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

Em alguns sistemas, rotas com mesma especificidade e mesma métrica podem resultar em ECMP (balanceamento por múltiplos caminhos). Em servidores, isso pode ser desejável ou causar confusão se você não espera tráfego saindo por interfaces diferentes.

3) Rota padrão (default route)

A rota padrão é usada quando nenhuma rota mais específica casa com o destino. Em IPv4, é 0.0.0.0/0; em IPv6, ::/0. Ela normalmente aponta para o gateway “para fora” (Internet ou backbone).

Se a rota padrão estiver ausente ou apontar para o lugar errado, o servidor até pode falar com redes diretamente conectadas, mas falhará para qualquer destino fora delas.

O que existe dentro da tabela de rotas

Uma entrada de rota costuma ter:

• Destino/prefixo: rede ou host (ex.: 172.16.50.0/24 ou 203.0.113.10/32)
• Gateway/next-hop: para onde enviar (ex.: 192.168.10.1). Em rotas “diretas”, pode não existir gateway (on-link).
• Interface: por qual NIC sai (ex.: eth0, ens192)
• Métrica: preferência entre rotas equivalentes
• Escopo/flags: indica se é link-local, host, etc. (varia por SO)

Exemplo de tabela (Linux, formato típico do ip route)

default via 192.168.10.1 dev eth0 metric 100
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.50 metric 100
10.20.0.0/16 via 192.168.10.2 dev eth0 metric 200
10.20.30.0/24 via 192.168.10.3 dev eth0 metric 50

Interpretação rápida:

• Para qualquer destino “desconhecido”, usa 192.168.10.1 (default).
• Para 192.168.10.0/24, sai direto pela eth0 (rede conectada).
• Para 10.20.30.0/24, prefere via 192.168.10.3 (métrica 50) em vez de cair na rota mais ampla 10.20.0.0/16 (métrica 200), além de ser mais específica.

Rotas estáticas: quando e por que usar

Rotas estáticas são rotas configuradas manualmente para alcançar redes específicas por um gateway específico. Em servidores, elas são comuns quando:

• Você tem múltiplos caminhos (ex.: rede interna e rede de backup) e quer controlar por onde o tráfego passa.
• Você precisa alcançar uma rede interna que não está atrás do gateway padrão.
• Você quer evitar que tráfego interno “vaze” para a rota default.

Passo a passo prático (Linux): adicionando e testando uma rota estática

Cenário: servidor em 192.168.10.50/24 (eth0). Gateway padrão 192.168.10.1. Existe uma rede interna 10.60.0.0/16 acessível via roteador 192.168.10.2.

1. Verifique a tabela atual:

   ip route

2. Adicione a rota estática:

   sudo ip route add 10.60.0.0/16 via 192.168.10.2 dev eth0

3. Confirme que a rota entrou:

   ip route show 10.60.0.0/16

4. Teste qual rota será usada para um IP específico (muito útil para “entender a escolha”):

   ip route get 10.60.12.34

5. Teste conectividade (ex.: ping/traceroute) e observe o caminho:

   ping -c 3 10.60.12.34
   traceroute -n 10.60.12.34

Observação importante: o comando acima adiciona a rota “na hora”. Para persistir após reboot, você precisa configurar no gerenciador de rede/distribuição (o método varia). O objetivo aqui é dominar o raciocínio e o teste.

Rota para host específico (/32) e para “forçar” um destino

Às vezes você quer que apenas um IP específico use um caminho diferente (ex.: um storage, um parceiro, um bastion). Use rota host:

sudo ip route add 203.0.113.10/32 via 192.168.10.254 dev eth0

Isso não muda o resto do tráfego, apenas o destino 203.0.113.10.

Multi-homing (duas interfaces): o básico que causa a maioria dos incidentes

Multi-homing é quando o servidor tem duas (ou mais) interfaces com redes diferentes, por exemplo:

• eth0: rede de usuários/Internet (192.168.10.50/24, gateway 192.168.10.1)
• eth1: rede de backend/armazenamento (10.0.0.50/24, gateway 10.0.0.1 ou sem gateway)

Isso é comum em servidores com rede de gerenciamento separada, rede de replicação, rede de backup, etc.

Armadilha 1: duas rotas padrão ao mesmo tempo

Se você configurar default route em eth0 e também em eth1, o sistema terá duas saídas possíveis para “qualquer lugar”. A escolha pode depender de métrica, ordem de inserção, ou até variar com mudanças de link. Sintomas:

• Conexões “às vezes funcionam, às vezes não”.
• Serviços respondem com IP de origem inesperado.
• Tráfego de saída vai por uma interface, mas o retorno chega por outra e é descartado por firewalls no caminho.

Regra prática: em geral, mantenha uma única rota default para o tráfego geral e use rotas específicas para redes internas que devem sair pela outra interface.

Armadilha 2: o retorno sai pelo caminho “errado” (assimetria)

Assimetria acontece quando o pacote de ida usa um caminho e o pacote de volta usa outro. Isso pode quebrar:

• Firewalls stateful no caminho (eles esperam ver ida e volta pelo mesmo lado).
• NAT em algum roteador (a volta não encontra o estado).
• Políticas de roteamento do cliente (ele responde para outro gateway).

Exemplo típico em multi-homing: um cliente acessa o servidor pelo IP da eth1 (10.0.0.50), mas o servidor responde usando a rota default da eth0. O cliente recebe resposta com origem 10.0.0.50, mas vinda por um caminho inesperado, ou a resposta nem chega.

Política simples: prioridade por métrica e rotas específicas

Sem entrar em roteamento por política avançada, dá para resolver muitos casos com:

• Default apenas na interface “principal” (ex.: eth0).
• Rotas estáticas para redes que devem sair pela outra interface (ex.: rede de storage, rede de backup, rede de replicação).
• Métricas para preferir um gateway quando houver redundância (dois gateways para a mesma rede).

Exemplo: preferir o roteador A para a rede 10.50.0.0/16, mas manter o roteador B como fallback:

sudo ip route add 10.50.0.0/16 via 192.168.10.2 metric 50
sudo ip route add 10.50.0.0/16 via 192.168.10.3 metric 200

Se 192.168.10.2 ficar indisponível (ou a rota for removida), a segunda pode assumir.

Diagnóstico prático: “alcança a rede, mas não recebe resposta”

Esse é um dos problemas mais comuns em roteamento de servidor. O servidor “manda”, mas a resposta não volta (ou volta por outro caminho e é descartada). Um roteiro de diagnóstico:

1) Descubra qual rota o servidor usa para o destino

ip route get <IP_DESTINO>

Verifique: qual interface, qual gateway, qual IP de origem (src) o sistema escolheu.

2) Verifique se existe rota de volta no outro lado

Se você controla o roteador ou o host remoto, confirme se ele sabe voltar para a rede do servidor. Sintoma clássico: o servidor está em 10.0.0.0/24, o remoto recebe o pacote, mas não tem rota para 10.0.0.0/24 e tenta responder pela rota default para outro lugar.

3) Procure assimetria em multi-homing

Se o servidor tem duas interfaces, confira:

• Qual IP o serviço está usando (bind) e qual IP o cliente está acessando.
• Se a resposta está saindo pela mesma interface por onde entrou.

Uma forma prática de observar é capturar tráfego por interface (exemplo em Linux):

sudo tcpdump -ni eth0 host <IP_CLIENTE>
sudo tcpdump -ni eth1 host <IP_CLIENTE>

Se o SYN entra por eth1 e o SYN/ACK sai por eth0, você achou um forte candidato a problema.

4) Confira rotas específicas que “sequestram” tráfego

Uma rota mais específica pode estar desviando tráfego sem você perceber. Procure por rotas /32, /24 etc. que batem no destino:

ip route show | grep -E '10\.|192\.168\.|172\.'

Depois valide com ip route get para o IP exato.

Exercícios (interpretação e cenários)

Exercício 1: qual rota será escolhida?

Considere a tabela:

default via 192.168.1.1 dev eth0 metric 100
192.168.1.0/24 dev eth0 scope link metric 100
10.0.0.0/8 via 192.168.1.2 dev eth0 metric 100
10.20.30.0/24 via 192.168.1.3 dev eth0 metric 200
10.20.30.40/32 via 192.168.1.4 dev eth0 metric 10

• a) Para 8.8.8.8, qual gateway será usado?
• b) Para 10.9.1.10, qual gateway será usado?
• c) Para 10.20.30.50, qual gateway será usado e por quê (prefixo vs métrica)?
• d) Para 10.20.30.40, qual gateway será usado?

Exercício 2: duas rotas para o mesmo prefixo (métrica)

Tabela:

10.100.0.0/16 via 192.168.10.2 dev eth0 metric 50
10.100.0.0/16 via 192.168.10.3 dev eth0 metric 200

• a) Qual rota é preferida?
• b) Se o roteador 192.168.10.2 parar de encaminhar, o que você espera que aconteça (assumindo que o sistema detecte a indisponibilidade/remova a rota)?

Exercício 3: multi-homing e retorno pelo caminho errado

Cenário:

• eth0: 192.168.10.50/24, default via 192.168.10.1
• eth1: 10.0.0.50/24, sem default
• Cliente: 10.0.0.100/24 (mesma rede da eth1)

O cliente acessa um serviço em 10.0.0.50:443, mas “conecta e trava” (SYN chega, não completa handshake).

• a) Que comando você usaria para verificar por onde o servidor pretende responder ao IP 10.0.0.100?
• b) Se você observar no tcpdump que o SYN entra pela eth1, mas o SYN/ACK sai pela eth0, qual é o problema provável?
• c) Proponha uma correção usando apenas rotas específicas (sem política avançada): que tipo de rota você adicionaria e para qual rede?

Exercício 4: alcança a rede, mas não recebe resposta

Cenário:

• Servidor: 192.168.50.10/24, default via 192.168.50.1
• Existe uma rota estática no servidor: 10.200.0.0/16 via 192.168.50.2
• Você consegue traceroute até 10.200.10.10 passando por 192.168.50.2, mas o ping não responde.

• a) Liste duas causas prováveis relacionadas a roteamento (não firewall) para “ida ok, volta não”.
• b) Que evidência você buscaria no lado remoto/roteador para confirmar falta de rota de retorno?
• c) Usando ip route get 10.200.10.10, o que você espera ver se a rota está correta?