Guia Definitivo de Networking no Linux: Da Resolução de Nomes e DHCP à Engenharia de Rotas L3 e Inspeção de Sockets TCP

Introdução

A administração de redes em ambientes Linux exige o domínio sobre o comportamento do Subsistema de Networking do Kernel (net/core). Falhas em serviços críticos frequentemente derivam de interpretações incorretas sobre como o sistema operacional resolve nomes, solicita concessões dinâmicas (DHCP), toma decisões no subsistema de roteamento L3 ou processa quadros e segmentos nas Camadas 2 e 4.

Neste artigo, abordamos a configuração completa da infraestrutura de rede no Linux: resolução local e DNS, clientes DHCP, provimento estático, manipulação avançada de tabela de rotas (métricas e escopos) e o troubleshooting de baixo nível via arping e tcpdump.

1. Resolução de Nomes, Identificação do Host e DNS

Antes que qualquer fluxo IP seja estabelecido, o sistema operacional precisa determinar sua própria identidade (hostname) e o mecanismo de resolução de nomes para endereços IP.

A. Identificação do Host (/etc/hostname e /etc/hosts)

O arquivo /etc/hostname define o nome do sistema no kernel, enquanto o /etc/hosts provê a tabela estática de resolução local sem necessidade de consultas a servidores DNS externos.

# cat /etc/hostname

srv-app-01.lab.local

# cat /etc/hosts

127.0.0.1       localhost

127.0.1.1       srv-app-01.lab.local srv-app-01

198.51.100.50   db-primary.lab.local db-primary

Mecânica de Consulta (/etc/nsswitch.conf):

A ordem em que o Linux resolve nomes é ditada pelo arquivo /etc/nsswitch.conf na diretiva hosts::

# grep hosts /etc/nsswitch.conf

hosts:          files dns

A sequência files dns instrui a biblioteca C (glibc) a consultar primeiro o arquivo local (/etc/hosts) e, caso o nome não seja encontrado, submeter uma requisição recursiva aos servidores declarados no /etc/resolv.conf.

B. Servidores de Nome e Resolução Recursiva (/etc/resolv.conf)

A indicação dos resolvedores DNS ocorre no arquivo /etc/resolv.conf:

# cat /etc/resolv.conf

domain lab.local

search lab.local Corp.local

nameserver 1.1.1.1

nameserver 8.8.8.8

+-----------------------+-----------------------------------------------------------------------+

| Diretiva Declarada    | Comportamento Operacional no Resolver                                 |

+-----------------------+-----------------------------------------------------------------------+

| domain lab.local      | Define o domínio local padrão do host.                                |

| search lab.local ...  | Sufixos anexados automaticamente em consultas de nomes curtos.        |

| nameserver 1.1.1.1    | IP do DNS Resolver Primário (consultado sequencialmente).             |

| nameserver 8.8.8.8    | IP do DNS Resolver Secundário (failover em caso de timeout no 1º).    |

+-----------------------+-----------------------------------------------------------------------+

2. Provimento de Interface: DHCP vs. Configuração Estática

A. Atribuição Dinâmica via DHCP (ifupdown + dhclient)

Para configurar uma interface para obter parâmetros de rede (IP, Máscara, Gateway, DNS e NTP) dinamicamente via DHCP, declara-se no /etc/network/interfaces:

auto eth0

iface eth0 inet dhcp

Para forçar a renovação da concessão via CLI ou depurar o processo DORA:

# dhclient -v eth0

DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3

DHCPOFFER of 198.51.100.10 from 198.51.100.1

DHCPREQUEST for 198.51.100.10 on eth0 to 255.255.255.255 port 67

DHCPACK of 198.51.100.10 from 198.51.100.1

Verificação de Sucesso: A recepção do quadro DHCPACK confirma a concessão. O dhclient automaticamente atribui o IP à interface, grava os resolvedores recebidos no /etc/resolv.conf e injeta a rota padrão no kernel.

B. Configuração Estática Persistente (/etc/network/interfaces) e Runtime (iproute2)

Para ambientes de servidores onde o IP deve ser fixo:

# cat /etc/network/interfaces

auto eth0

iface eth0 inet static

    address 198.51.100.10/24

    gateway 198.51.100.1

    dns-nameservers 1.1.1.1 8.8.8.8

Para aplicar e validar alterações sem reiniciar:

# ifdown eth0 && ifup eth0

# ip -4 addr show dev eth0

3. Gerenciamento Avançado de Rotas, Gateways e Métricas

O subsistema de roteamento do Linux toma decisões de encaminhamento baseando-se na Regra do Prefixo Mais Específico (Longest Prefix Match - LPM) e, em caso de empate de prefixo, no valor da Métrica.

A. Adição de Rotas Estáticas via IP e via Interface

Rotas podem ser apontadas para um Next-Hop IP ou diretamente para uma Interface:

# ip route add 203.0.113.0/24 via 198.51.100.254 dev eth0

# ip route add 192.0.2.0/24 dev eth0

+------------------------------------+------------------------------------------------------------------+

| Tipo de Configuração de Rota       | Caso de Uso Recomenda e Comportamento da Pilha                   |

+------------------------------------+------------------------------------------------------------------+

| Via IP Next-Hop                    | Obrigatório em Redes Multi-Acesso (Ethernet/VLANs). O kernel     |

| (via 198.51.100.254)               | precisa do IP para resolver o MAC do gateway via ARP.            |

+------------------------------------+------------------------------------------------------------------+

| Via Interface Direta               | Exclusivo para Links Ponto-a-Ponto (GRE, IPsec, PPPoE). Em redes |

| (dev eth0)                         | Ethernet, força ARP Broadcast para CADA IP de destino na rota.   |

+------------------------------------+------------------------------------------------------------------+

B. Métricas de Rota no Linux vs. Distância Administrativa (AD)

É crucial distinguir a Métrica no Linux do conceito de Distância Administrativa (AD) encontrado em roteadores corporativos (Cisco/MikroTik):

• Distância Administrativa (AD / Route Preference): Utilizada pelos roteadores para decidir qual fonte de roteamento (BGP=20, OSPF=110, Estática=1) deve popular a Routing Information Base (RIB).

• 
  

• Métrica no Linux: É o custo de desempate utilizado dentro da tabela de roteamento do kernel para rotas com o mesmo prefixo exatamente idêntico. O menor valor de métrica tem prioridade de escolha.

• 
  

C. Configuração de Multi-Homing, Redundância e Failover de Gateways

Em cenários onde um servidor possui duas interfaces conectadas a provedores ou redes distintas, atribui-se métricas diferentes para estabelecer prioridade e failover:

# ip route add default via 198.51.100.1 dev eth0 metric 10

# ip route add default via 203.0.113.1 dev eth1 metric 20

Inspecionando a tabela de roteamento ativa no kernel:

# ip route show

default via 198.51.100.1 dev eth0 proto static metric 10

default via 203.0.113.1 dev eth1 proto static metric 20

198.51.100.0/24 dev eth0 proto kernel scope link src 198.51.100.10

203.0.113.0/24 dev eth1 proto kernel scope link src 203.0.113.10

Análise de Decisão do Kernel:

1. O kernel avalia as duas rotas padrão (0.0.0.0/0).

2. Como a máscara é idêntica (/0), o critério de desempate recai sobre a métrica.

3. A rota via eth0 com metric 10 é selecionada para todo o tráfego de saída. Caso a interface eth0 perca o link (LOWER_UP off), o kernel desativa a rota e passa a utilizar a rota via eth1 (metric 20).

4. Troubleshooting de Adjacência L2 com arping

Com a camada L3 configurada, valida-se a conectividade L2 via arping (RFC 826), que injeta quadros Ethernet usando raw sockets (AF_PACKET).

Cenário A: Teste Inter-VLAN sem Proxy ARP (L3 Boundary)

# arping -I eth0 -c 3 192.0.2.1

ARPING 192.0.2.1 from 198.51.100.10 eth0

Sent 3 probes (3 broadcast(s))

Received 0 response(s)

Análise do Resultado:

• O envio ocorre para o MAC de broadcast ff:ff:ff:ff:ff:ff.

• Roteadores descartam broadcasts L2 na interface de entrada. Sem Proxy ARP no gateway (sysctl net.ipv4.conf.eth0.proxy_arp=1), o retorno é 100% de perda.

• Validação na tabela de vizinhos do kernel:

# ip neighbor show dev eth0 192.0.2.1

192.0.2.1 dev eth0 FAILED

Verificação de Sucesso: O estado FAILED confirma falha no domínio L2, descartando bloqueios de firewall L4.

Cenário B: Resolução no Mesmo Domínio L2 Local

# arping -I eth0 -c 3 198.51.100.1

ARPING 198.51.100.1 from 198.51.100.10 eth0

Unicast reply from 198.51.100.1 [20:00:00:00:00:01]  0.250ms

Unicast reply from 198.51.100.1 [20:00:00:00:00:01]  0.248ms

Sent 3 probes (1 broadcast(s), 2 unicast)

Received 3 response(s), 0% packet loss

• O primeiro probe descobre o MAC de destino. Os probes seguintes são otimizados para Unicast L2.

• Checagem da tabela ARP:

# ip neighbor show dev eth0 198.51.100.1

198.51.100.1 dev eth0 lladdr 20:00:00:00:00:01 REACHABLE

5. Inspeção de Fluxo TCP via TCPdump e Análise da Pilha L4

A validação final de conectividade e performance da aplicação é realizada via captura de pacotes na camada de transporte (RFC 793).

Trace de Captura em Sessão SSH Interativa

# tcpdump -nn -i any port 22

02:02:32.565831 IP 198.51.100.10.22 > 203.0.113.50.1155: Flags [P.], seq 193:289, ack 1, win 501, options [nop,nop,TS val 1234567 ecr 7654321], length 96

02:02:32.565890 IP 203.0.113.50.1155 > 198.51.100.10.22: Flags [.], ack 289, win 502, options [nop,nop,TS val 7654322 ecr 1234567,sack 1 {193:289}], length 0

+-----------------------+-----------------------------------------------------------------------+

| Parâmetro / Campo     | Interpretação Técnica na Pilha do Kernel                              |

+-----------------------+-----------------------------------------------------------------------+

| Flags [P.]            | Push Flag (PSH): força a entrega imediata dos dados do buffer à app.  |

| seq 193:289           | Byte inicial e final da sequência transportada no segmento.           |

| win 501               | Receive Window (rwin) informada para controle de fluxo.               |

| TS val / ecr          | TCP Timestamps (RFC 7323): RTT dinâmico e proteção contra PAWS.       |

| options [sack 1 ...]  | Selective ACK (RFC 2018): sinalização de blocos em perda seletiva.    |

| length 96             | Payload real contido na camada de aplicação (289 - 193 = 96 Bytes).   |

+-----------------------+-----------------------------------------------------------------------+

6. Parâmetros de Performance e NIC Hardware Offloading

A. Algoritmo de Nagle vs. TCP_NODELAY

Aplicações de terminal interativo desabilitam o algoritmo de Nagle definindo TCP_NODELAY no socket via setsockopt. Isso força o envio imediato de pequenos pacotes (Push Flag ativa) sem aguardar o preenchimento da janela, garantindo baixa latência na digitação do terminal.

B. Impacto de NIC Hardware Offloading (TSO/GRO)

Aplicações de otimização de placa de rede podem alterar a percepção dos tamanhos de pacotes capturados pelo tcpdump:

# ethtool -k eth0 | grep -E "segmentation|receive-offload"

tcp-segmentation-offload: on

generic-receive-offload: on

• TCP Segmentation Offload (TSO): Repassa a segmentação de buffers grandes (ex: 64 KB) para o hardware da NIC.

• Efeito no TCPdump: Como a captura ocorre na camada de software (netif_receive_skb) antes do envio físico à NIC, pacotes podem aparecer com tamanho superior ao MTU (ex: length 14600).

• Desativação para Diagnóstico Rígido de MTU:

# ethtool -K eth0 tso off gro off

Verificação de Sucesso: A captura pós-desativação passará a registrar unicamente quadros que respeitam a MTU configurada na interface (ex: length 1460 para MTU de 1500 bytes).