Por que route-nopull sozinho deixa o servidor de arquivos inacessível
Ignorar as rotas empurradas é só metade de um túnel dividido. Escolha o dono da rota, acrescente o prefixo do escritório à mão e teste três fluxos antes de dar o caso por resolvido.
O servidor de arquivos abre bem, e a videochamada na janela ao lado começa a falhar. Nada está lento e nenhum MTU está errado: seu cliente aceitou a lista de rotas que o servidor entregou, então cada pacote agora sai pela firewall do escritório. A correção não é mais uma flag de ajuste, mas uma decisão sobre quem é dono da tabela de rotas do cliente. Essa decisão pertence a um único lugar, e os modos de falha abaixo dizem qual lugar você escolheu de fato.
Decida quem é dono da tabela de rotas
Há três donos possíveis. O servidor pode empurrar rotas e um gateway padrão, e então o cliente instala o que lhe dizem e vira um túnel completo. O perfil do cliente pode assumir a propriedade descartando os empurrões e carregando suas próprias linhas de rota. Um gerenciador de conexões de desktop também pode ser dono da decisão por meio das suas próprias propriedades de rota e rota padrão.
Cada escolha falha de um jeito diferente, e é por isso que vale ler a tabela antes de editar um perfil. A linha que combina com o seu sintoma é o dono que você realmente tem.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
Escolha uma e anote. Misturar duas deixa um host cujo caminho padrão contradiz a própria documentação, e o próximo engenheiro não consegue saber qual camada venceu. Apague o perdedor de forma explícita.
route-nopull filtra empurrões, não acrescenta rotas
route-nopull pertence ao perfil do cliente, e sua ordem nesse arquivo é irrelevante porque ele só descarta valores que vêm do servidor. Ele descarta as rotas empurradas, incluindo uma rota padrão empurrada, enquanto o túnel ainda sobe normalmente.
A consequência que as pessoas deixam passar é que as opções DHCP empurradas vão junto. As configurações de DNS enviadas pelo servidor também são descartadas, então os nomes internos deixam de resolver mesmo que o túnel esteja saudável e o servidor seja alcançável pelo endereço.
Isso deixa um túnel sem caminho para o prefixo do escritório a menos que você acrescente um: route-nopull seguido de route 10.30.0.0 255.255.0.0 no mesmo perfil. Essa linha carrega um endereço e uma máscara; não nomeia um próximo salto.
Uma forma alternativa acrescenta um token de gateway, route 10.30.0.0 255.255.0.0 vpn_gateway, que aponta a entrada para o túnel pelo nome. Os importadores diferem quanto a traduzir essa variante, então inspecione a conexão salva se a entrada faltar na tabela do kernel.
Verifique com consultas de rota, não com ping
Um ping diz que algo respondeu. Uma consulta de rota diz qual interface o kernel escolheria, e essa é a pergunta que você realmente fez. Quatro comandos curtos separam uma rota ausente de uma rota que aponta para o dispositivo errado.
Leia o que o túnel instalou com ip route show dev tun0. Nenhuma saída significa zero rotas, o que não é um túnel dividido que funcione, e é o resultado habitual de acrescentar o filtro sem a linha explícita.
Depois verifique um endereço do escritório com ip route get 10.30.5.7, e um endereço de internet comum com ip route get 1.1.1.1. O segundo deve nomear a interface física; se nomear o túnel, o empurrão não foi filtrado de forma alguma.
Por fim leia ip rule, porque uma regra de política deixada por uma tentativa anterior pode sobrepor a tabela que você acabou de corrigir. Um perfil correto com uma regra obsoleta em cima parece exatamente um perfil quebrado. Apague a regra que você acrescentou da última vez antes de acrescentar outra.
Sub-redes sobrepostas parecem um túnel quebrado
Duas faixas privadas podem ser idênticas do ponto de vista do cliente, e é aí que um túnel dividido é culpado por algo que não causou. Se o escritório distribui o mesmo prefixo que seu roteador de casa usa, a rota do túnel cobre o roteador e a rede da casa parece desaparecer.
Compare o endereço na sua própria interface com a rota que o perfil instala, usando uma listagem de endereços simples antes de mudar qualquer coisa. A sobreposição é real, e nenhuma opção de perfil a resolve. O que você pode corrigir é a nomenclatura, para que a próxima pessoa veja duas faixas em vez de uma.
As correções honestas são renumerar um lado ou traduzir endereços no escritório. Fixar uma única rota de host no roteador funciona até o endereço do roteador mudar, e então vira um segundo mistério em cima do primeiro.
Faça a decisão sobreviver a uma reconexão
Entradas digitadas à mão não sobrevivem a uma reconexão, e um gerenciador de conexões reconstrói a tabela a cada início do perfil. Coloque a decisão onde a conexão é criada, seja o perfil ou as configurações salvas do gerenciador. Depois reinicie a conexão uma vez de propósito, em vez de descobrir o comportamento durante uma chamada. Um perfil que só funciona até a próxima reconexão não está terminado.
Exercite três caminhos ao mesmo tempo: um host do escritório pelo endereço literal, o mesmo host pelo nome, e um site público comum. O do meio depende do serviço de nomes que você configurou depois de descartar as opções DNS empurradas, e é ele que falha em silêncio.