Copiar o /32 do túnel não encaminha a sub-rede do escritório
O endereço que a VPN entrega ao adaptador descreve o link, não o destino. Adicione o prefixo do recurso ao perfil e deixe a rota padrão em paz.
A VPN conecta, a interface mostra um endereço com máscara de trinta e dois bits e o servidor do escritório continua inalcançável. O próximo passo costuma ser reutilizar essa máscara em uma rota, com a teoria de que a interface descreve o que o túnel pode alcançar. Não descreve. Esse endereço descreve a extremidade local de um link ponto a ponto, e o destino que lhe importa fica em outro prefixo do outro lado.
Duas coisas diferentes estão sendo confundidas: o endereço que o túnel lhe deu e a rede que você quer alcançar por meio dele.
Dois endereços, duas tarefas
Em um túnel ponto a ponto, o endereço do cliente costuma ser um único endereço de host porque há exatamente um par na outra extremidade do link. Não há segmento compartilhado nem ARP, então uma máscara que pareceria absurda no Ethernet aqui é completamente normal.
O prefixo de destino é um fato sobre a rede do escritório, não sobre o túnel. Se você precisa de um servidor, a rota é uma rota de host para esse servidor. Se precisa da sub-rede inteira do escritório, a rota é a sub-rede. Nenhuma das duas respostas pode ser lida na interface, e escolher uma porque ela apareceu ao lado do endereço do túnel é como uma configuração que funciona se quebra.
| What you need to reach | What to install |
|---|---|
| One server, nothing else | A host route for that address |
| The office subnet | A route for the subnet prefix |
| Everything in the private space | Only if the requirement says so, and only with the owner's approval |
Essa terceira linha é onde o otimismo vira interrupção. Encaminhar toda uma faixa privada para um túnel que serve apenas um site empurra tráfego não relacionado para um caminho que não consegue entregá-lo, e as falhas resultantes parecem uma VPN quebrada, e não uma rota larga demais.
Escolha o prefixo a partir do requisito
Escreva o requisito como uma frase antes de tocar em um perfil: quais hosts precisam ser alcançáveis e qual é o prefixo mais estreito que os cobre? Um único servidor é uma rota de host. Uma sub-rede é uma rota de sub-rede. Uma faixa de sub-redes é um resumo, e um resumo é uma promessa de que todo endereço dentro dele é alcançável, o que raramente é verdade.
Depois confira o número contra o que o escritório realmente usa. Copiar um prefixo de uma mensagem de chat sem confirmá-lo com o plano de endereçamento do site é como uma rota acaba apontando para uma sub-rede que ninguém possui.
Lembre-se também de que uma rota é um caminho, não uma permissão. O gateway ainda decide se o seu cliente pode usar o destino, e um serviço ainda pode recusá-lo. Instalar a rota corretamente faz o pacote chegar lá e não responde nada sobre autorização.
Adicione ao perfil, nunca o substitua
As rotas em um perfil do NetworkManager são uma propriedade de vários valores, e a diferença entre definir e adicionar é um caractere. Use a forma com mais para adicionar uma entrada e manter tudo o que já está salvo.
nmcli connection modify uuid 11111111-2222-4333-8444-555555555555 \
+ipv4.routes "10.40.20.9/32"Sem o mais, a atribuição substitui a lista inteira. Em um perfil que já carrega vários prefixos, isso apaga silenciosamente os que funcionavam, e o sintoma chega depois como um serviço que antes era alcançável a partir deste notebook.
Use o UUID em vez do nome. Os nomes são duplicados após restaurações, e a conexão que você edita pode não ser a que carrega o seu tráfego. Verifique primeiro se já existe uma entrada idêntica, porque acrescentar uma duplicata é desorganizado mesmo quando é inofensivo.
A referência de propriedades de rota documenta o destino, o próximo salto opcional, a métrica e a sintaxe de atributos para a versão instalada. Leia-a antes de adicionar um próximo salto, porque se ele é necessário depende da integração e da topologia, e adivinhá-lo a partir do primeiro endereço de uma listagem de interfaces não é um método.
A rota padrão e o DNS são decisões separadas
Adding an office prefix says nothing about where the rest of your traffic goes. If policy requires ordinary internet traffic to stay outside the tunnel, that is the ipv4.never-default decision, and it belongs to whoever owns the connection policy rather than to whoever is fixing one unreachable server.
As rotas automáticas são a outra coisa que não se deve perturbar de leve. Suprimi-las para resolver uma entrada ausente pode remover várias que funcionam, e quem sugeriu isso normalmente estava olhando outro perfil com outros push.
O DNS tem o seu próprio caminho e as suas próprias falhas. Um nome que resolve para o endereço certo pelo resolver errado, ou um resolver que não consegue responder pela zona privada, vai parecer um problema de roteamento enquanto a rota está perfeita. Teste o endereço e o nome separadamente e depois decida qual camada realmente falhou.
Verifique o que foi aplicado
Uma modificação salva não é uma modificação aplicada. Reconecte pelo ciclo de vida suportado do gerenciador e depois olhe a rota real para o destino pretendido e as regras de política que decidem qual tabela é consultada.
Se o prefixo está lá e a conexão ainda falha, você passou para outro problema: seleção de endereço de origem, uma rota de retorno na extremidade remota ou um serviço que recusa o seu cliente. Cada um desses é um lugar melhor para olhar do que o perfil que você já corrigiu.