O Que São Vias Locais

Vias locais na prática

O que são vias locais? É uma forma simples de dizer que uma rede tem um caminho direto para alcançar determinados endereços sem precisar passar por um roteador de borda ou gateway padrão. Quando você configura uma interface de rede, o sistema operacional automaticamente cria uma rota local correspondente à sub-rede dessa interface. Se sua máquina tem o IP 192.168.1.10/24 na eth0, o kernel já adiciona sozinho uma rota para 192.168.1.0/24 via eth0. Isso funciona porque as vias locais dizem ao sistema: "para endereços dentro desse bloco, use diretamente essa interface — não encaminhe nada".

Essa é a parte que a maioria dos tutoriais pega leve demais. A rota local não é só uma linha automática na tabela de roteamento. Ela convive com as outras rotas e, às vezes, entra em conflito direto com elas.

Como as vias locais se comportam no dia a dia

Na Linux, você vê isso rodando `ip route show`. A linha com o escopo `link` é a via local. Todo endereço IP atribuído a uma interface gera uma dessas linhas, com o prefixo correspondente ao tamanho do seu máscarade rede. A prioridade padrão desse tipo de rota é 0, o mais alto possível, então nunca é substituída por uma rota de escopo `universe` ou `host` de outro gateway. Isso garante que o tráfego de egresso sempre saia pela interface certa quando o destino está no mesmo segmento. Isso parece óbvio, mas aqui vai algo que eu aprendi na marra depois de perder duas horas debugging. Você pode ter dois IPs no mesmo host pertencentes a sub-redes diferentes. Um na eth0 e outro na eth1, por exemplo. Quando um pacote sai de um desses IPs e o destino está no outro segmento, o roteamentolookup pode criar confusão se o reverse path filtering estiver ativo. O kernel verifica se o caminho de volta para a origem do pacote seria válido pela interface de chegada, e se não for, descarta o pacote. Eu tive um caso em que um servidor com dois IPs em sub-redes /24 diferentes não conseguia se comunicar com um switch gerenciável porque o filter estava como strict (rfc3967=2). A solução foi colocar o valor para 1 no parâmetro `rp_filter` daquela interface, que ativa o loose mode. Sem isso, os pacotes simplesmente sumiam e não havia log algum no iptables ou no dmesg indicando o problema.

Pitfalls comuns

A primeira armadilha é achar que adicionar um segundo IP na mesma interface resolve tudo. Não resolve. O sistema vai criar uma segunda via local, sim, mas o tráfego de egresso ainda vai usar o primeiro IP como source address a menos que você configure policy routing com regras baseadas em origem. Isso é diferente de simplesmente colocar dois IPs no mesmo interface. Se você precisa de dua source addresses diferentes para traffic direcionado a sub-redes distintas, precisa de tables de roteamento secundárias e regras `ip rule`. A segunda armadilha é mais sutil e acontece com Docker ou containers. Quando o Docker cria a bridge docker0, ele adiciona uma rota local para a subnet 172.17.0.0/16. Se por algum motivo essa rota some — o que pode acontecer em certas configurações de rede empresarial com DHCP complexo —, os containers perdem conectividade externa sem que o host pareça ter qualquer problema visível. A dica prática aqui é monitorar a saída do `ip route` e não confiar apenas no fato de que `ping` funciona intermitentemente.

Outro ponto que ninguém menciona frequentemente: vias locais não são estáticas em redes com IPv6. O protocolo NDP gera automaticamente routes do tipo `link` para o seu link-local e para o seu ULA, mas isso depende inteiramente do estado da interface. Se a interface cai e sobe rapidamente, essas rotas podem ficar dessincronizadas por alguns segundos até o NDP regenerá-las. Em ambientes com alta disponibilidade exigindo failover rápido, esse gap pode causar perda de pacotes na faixa de 2 a 5 segundos.

Workarounds para cenários reais

Se você precisa de controle fino sobre qual IP de origem é usado para atingir determinada sub-rede, policy routing é o caminho. Crie uma tabela de roteamento dedicada, adicione a rota local nela, e use `ip rule` para direcionar o tráfego baseado no source address. Isso funciona tanto em Linux quanto em BSDs, com sintaxe ligeiramente diferente. Em Linux, o comando básico seria algo como criar uma entrada em `/etc/iproute2/rt_tables`, adicionar a rota com `ip route add` especificando a tabela, e depois adicionar a regra com `ip rule add from table `. Se o problema é o reverse path filtering causando drop de pacotes em configurações multi-homed, a verificação deve ser feita antes de qualquer outra coisa. Olhe o valor atual com `sysctl net.ipv4.conf.all.rp_filter` e por interface com `sysctl net.ipv4.conf..rp_filter`. Mude para loose mode (1) se o padrão for strict (2). Faça isso permanentemente no `/etc/sysctl.conf` para não perder a configuração após reboot.

Existe ainda um cenário onde vias locais simplesmente não vão te ajudar: quando você precisa rotear tráfego entre duas sub-redes no mesmo host sem passar pelo gateway padrão externo. Nesse caso, a solução não é brigar com as vias locais existentes, mas configurar NAPT ou IP masquerading na bridge interna, ou simplesmente garantir que a rota de destino aponte para a interface correta com métrica adequada.

O que as vias locais não fazem

Elas não fazem tradução de endereço. Não filtram tráfego por padrão — para isso você precisa de iptables/nftables. Elas também não criam túneis nem criptografia. Tudo que uma via local faz é direcionar o pacote para a interface correta com base no destino. É funcionalidade de camada 3 pura, sem surpresas. Se algo além disso está acontecendo na sua rede, a causa não está nas vias locais em si, mas sim em como o restante da stack de rede está configurada ao redor delas.