169.254 por VPN: o endereço nunca foi roteável
Um destino link-local é descartado antes de chegar ao túnel, portanto acrescentar rotas só amplia a falha. Escolha entre corrigir a sub-rede e montar uma ponte.
Você adiciona a rota, o túnel sobe e, mesmo assim, o ping para o outro lado morre com perda total em vez de «network unreachable». Essa diferença importa, porque desvia o olhar da tabela de rotas para o próprio endereço. Um destino 169.254 é link-local, e seu alcance termina no primeiro salto por projeto, não por configuração errada.
A decisão que se segue é estreita e vale a pena tomar explicitamente: corrigir a sub-rede do lado do servidor ou estender o segmento da camada 2 para que o endereço volte a fazer sentido local. Todo o resto, incluindo uma rota mais ampla, só faz a mesma falha valer para mais destinos.
O endereço não é sem rota: ele é não roteável
Endereços IPv4 link-local se atribuem sozinhos quando nada melhor responde; daí vem o endereçamento privado automático do Windows e o equivalente em outros sistemas. A faixa é usada em cada enlace ao mesmo tempo, e é justamente por isso que funciona: dois hosts no mesmo segmento conversam sem qualquer coordenação.
Essa mesma propriedade é o motivo pelo qual um roteador não deve encaminhar esses pacotes entre redes. Receber um pacote endereçado a um destino link-local e enviá-lo por outra interface criaria ambiguidade, porque o «local» do emissor e o «local» do receptor são lugares diferentes. Nenhuma consulta decide qual dos dois o emissor quis dizer. O encaminhamento aqui não é uma opção de política que o administrador possa ligar; a classe de endereço a exclui.
Assim, um gateway que instala 169.254.1.10 como alcançável pelo túnel pede ao kernel algo que o formato do endereço proíbe. O pacote é descartado muito antes de chegar ao host remoto, e nenhuma precisão de rota muda esse resultado.
Por que um túnel torna visível o problema de alcance
Uma interface TUN transporta pacotes IP entre dois pares e não tem nenhum segmento compartilhado atrás. Não há difusão, nem ARP para o outro lado, nem descoberta de vizinhos que resolva um destino link-local em um endereço de camada de enlace.
Os sintomas batem quando você sabe o que procurar. A rota está na tabela, o ping informa perda total em vez de rede inalcançável, e a tabela de vizinhos mostra uma entrada incompleta ou falha. Uma captura no túnel mostra o pacote saindo, o que leva as pessoas a olhar a ponta remota em vez da classe de endereço.
No Windows há um segundo sintoma, aparentemente sem relação, com a mesma raiz: um adaptador que ficou só com endereço link-local não tem gateway utilizável, então a identificação de rede não consegue classificar a conexão e o perfil do firewall cai em público. O túnel não é a causa; o endereço é.
Decida com três perguntas
A escolha entre corrigir a sub-rede e fazer a ponte do enlace depende de três condições, e qualquer uma delas pode resolvê-la antes de abrir um arquivo de configuração.
| Question | If yes | If no |
|---|---|---|
| Can the far-side host be given a routable address? | Change the host or fix DHCP and route normally | Continue to the next question |
| Does the device accept a static address at all? | Assign one from the site's real prefix | Bridging is the only remaining option |
| Can you accept broadcast crossing the tunnel? | A bridge is viable for a small segment | Replace the device or accept no remote access |
A maioria dos casos para na primeira pergunta. Um host com endereço link-local geralmente significa que o DHCP não respondeu, que um cabo ou uma VLAN estão errados, ou que alguém digitou o endereço à mão. Corrigir isso é mais barato que qualquer trabalho no túnel e elimina o problema para todos os clientes futuros, não apenas este.
Verifique o lado do servidor antes de supor qualquer coisa. Execute ip addr show e ip route no host, e arp -n ou route print -4 no cliente, para ver se o prefixo existe de fato ou se apenas uma entrada antiga o afirma.
Quanto custa uma ponte quando ela é a resposta certa
Fazer ponte de um adaptador físico com um adaptador TAP torna o cliente remoto parte do domínio de difusão local. A difusão e a descoberta de vizinhos então funcionam, e um endereço link-local volta a fazer sentido porque o cliente é realmente local naquele enlace.
Os custos são reais e devem ser ditos antes de alguém aceitar. O tráfego de difusão atravessa o túnel, o cliente fica exposto ao segmento local para qualquer finalidade e não apenas aos serviços de que precisa, e o servidor agora precisa encaminhar quadros em vez de rotear pacotes. É uma troca razoável para uma bancada de laboratório ou um dispositivo sem caminho de configuração roteável, e um padrão ruim para acesso remoto.
Quando fizer a ponte, as duas metades são necessárias: a ponte no servidor e uma rota no perfil do cliente dizendo quais destinos estão do outro lado. A ponte sozinha deixa o cliente adivinhando, e a rota sozinha não corrige uma classe de endereço.