Esse endereço de túnel é um par, não uma sub-rede que você pode navegar

O seu cliente liga-se e mostra um par de endereços, ou um único endereço com uma 255.255.255.255 máscara, e a primeira reação é que o servidor entregou algo avariado. Nada está avariado: uma interface tunelada é uma ligação ponto a ponto, e a máscara descreve a extremidade remota dessa única ligação, não uma faixa de vizinhos. Ler o par como local e par explica a máscara estranha, a rota de um único host ao lado e a tabela de vizinhos ausente. O que a mesma leitura não desculpa é um plano de endereços que se sobrepõe à rede do escritório.

Por que a máscara parece errada numa ligação tunelada

Numa interface Ethernet, um endereço e uma máscara afirmam duas coisas: este host possui o endereço, e tudo o que está dentro do prefixo é um vizinho direto. O núcleo deriva uma rota na ligação a partir desses dois factos e depois resolve os endereços de ligação para os vizinhos que considera presentes. Uma interface ponto a ponto mantém a propriedade e descarta os vizinhos, pelo que o segundo endereço na linha do cliente é a extremidade remota e não outro host num segmento partilhado. Não há endereçamento de hardware, tráfego de resolução nem domínio de difusão a que se juntar, e é por isso que a interface se comporta como um tubo com exatamente um destino.

Também por isso uma rota de um único host ao lado de uma máscara larga é normal aqui e não um sintoma. A acessibilidade nesta ligação significa um endereço, e o núcleo regista exatamente isso. Leia os dois endereços em conjunto antes de concluir que a configuração está errada, porque cada um deles sozinho parece um erro.

Duas topologias, duas formas de endereço

A topologia ponto a ponto mais antiga dá a cada cliente um bloco pequeno e usa os dois endereços centrais, pelo que a máscara parece um fragmento de uma rede e não um conjunto. A topologia de sub-rede entrega um endereço do conjunto com a máscara do conjunto e chama ao endereço de túnel do servidor o par. Ambas produzem uma ligação válida, e diferem apenas nos endereços que aparecem no perfil e na máscara que um utilizador provavelmente questionará.

Qualquer que seja a linha que corresponde ao seu cliente, leia primeiro o par, porque nomeia a extremidade remota e, portanto, explica a máscara. Um perfil copiado entre servidores que usam topologias diferentes mostrará a forma errada para a sua nova casa, e essa discrepância é facilmente confundida com uma falha do servidor.

Quando o conjunto e a rede do escritório reclamam os mesmos bits

Como a ligação é encaminhada, o conjunto precisa de um prefixo que não apareça em nenhuma das redes que o servidor consegue alcançar. Partilhe um e o cliente terá uma única rota para um intervalo que significa dois lugares, e a rota instalada mais recentemente decide qual lugar ganha. A falha manifesta-se no cliente, embora a decisão por trás pertença ao plano de endereços. O que os utilizadores relatam é o router local a desaparecer quando o túnel sobe, ou que só alguns hosts do escritório respondem.

Os prefixos que apenas se parecem são outro caso, e comparar octetos a olho não é uma comparação de prefixos. Escreva os dois e conte os bits mascarados: 192.168.4.0/24 contra 192.168.6.0/24 coincidem até ao bit 22 e divergem no bit 23, porque o terceiro octeto lê-se como 00000100 contra 00000110, pelo que essas duas redes são realmente separadas. Coloque 10.8.0.0/24 ao lado de outro 10.8.0.0/24 e todos os 24 bits mascarados coincidem, o que significa que uma rota não pode exprimir os dois lugares. O comprimento da máscara decide onde a comparação para, e a rede instalada em segundo lugar é a que perde.

O que uma ligação encaminhada não pode entregar

A difusão e o multicast não atravessam uma ligação encaminhada, e várias funções conhecidas baseiam-se neles. As listas de navegação, os anúncios de nomes e a descoberta de serviços assumem todos um segmento partilhado, pelo que um servidor de ficheiros pode responder a cada pedido por endereço e mesmo assim nunca aparecer numa lista. A resolução de nomes que depende da difusão local da ligação falha pela mesma razão, e nenhuma edição do perfil altera o que o túnel é capaz de transportar. Se isso importa é uma questão de requisitos, não de encaminhamento.

Um cliente que realmente precisa dessas entregas exige uma interface em ponte, que transporta tramas Ethernet e por isso mantém o domínio de difusão. O custo é uma ligação mais ruidosa, a perda do endereçamento limpo descrito acima e uma superfície de falha muito maior assim que aparecem ciclos. Justifique o requisito antes de mudar, e prefira um serviço de nomes que funcione sobre ligações encaminhadas quando o requisito é apenas sobre nomes.

Ler a interface antes de editar o perfil

Pergunte ao núcleo o que instalou e não o que o perfil parece dizer. A saída de endereços mostra o par que explica a máscara, e a saída de rotas mostra se existe um caminho até ele. Executar ambas contra o dispositivo de túnel leva um momento e resolve a questão.

ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1

Se esses três coincidirem, o perfil faz o que foi configurado para fazer, e o problema restante está noutro sítio. Mude a topologia apenas por um motivo que nomeie uma capacidade em falta, porque uma máscara desconhecida não é um deles.