Onde fica a rota no OpenVPN: no cliente ou no servidor?
Uma rota nua na configuração do servidor altera o servidor, não o cliente. Escolha o arquivo do cliente, um push global ou um push por cliente e verifique o que chegou.
Você adiciona route 10.60.0.0 255.255.255.0 à configuração do servidor, reinicia, reconecta um notebook, e a sub-rede continua inacessível a partir desse notebook. A linha foi aceita, o serviço iniciou limpo e nada no log parece errado. O que aconteceu é que a rota foi instalada na máquina que você editou: o gateway agora acredita que consegue alcançar esse prefixo, enquanto o cliente nunca foi informado de nada. O posicionamento é toda a questão, e há quatro lugares onde a mesma linha pode viver.
Os quatro lugares e quem recebe cada um
Uma rota pode ser adicionada pela configuração do próprio cliente, oferecida a todos os clientes por meio de um push global, oferecida a um único cliente por um arquivo específico, ou escrita no próprio contexto de roteamento do servidor.
Esses quatro casos usam sintaxe quase idêntica e produzem resultados completamente diferentes. Os três primeiros afetam o que um cliente envia para o túnel; o quarto afeta como o servidor alcança uma rede, o que é útil quando o próprio servidor precisa de um caminho e prejudicial quando é confundido com distribuição.
Decida qual dos quatro você quer antes de escrever a linha e depois confirme o destinatário.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
Por que a rota nua no servidor surpreende as pessoas
A configuração do servidor é onde os administradores olham primeiro, e uma diretiva de rota ali é lida como uma afirmação sobre a rede VPN. Não é. OpenVPN a trata como uma instalação local de rota na máquina que executa o daemon, exatamente o mesmo tipo de mudança que você faria com ip route e depois esqueceria.
A distribuição exige que a rota seja enviada por push, e o push exige que o cliente a puxe. Um cliente iniciado com as opções puxadas desativadas ignora a oferta por completo. Verifique as duas pontas desse aperto de mão antes de reescrever o arquivo do servidor, porque o log do servidor não vai reclamar: do lado dele, a oferta foi enviada. Uma rota aceita também só entra em vigor na próxima conexão, nunca na sessão em que você já está.
Quando você vê as duas como operações separadas, a falha deixa de ser misteriosa: o servidor alcança o prefixo, o cliente não, e as duas afirmações são verdadeiras ao mesmo tempo.
Arquivos por cliente e a identidade com que coincidem
Um arquivo específico de cliente é nomeado segundo a identidade autenticada pelo servidor, que por padrão é o nome comum do certificado. Um nome de conexão amigável em um cliente de desktop não é esse valor, e uma divergência produz um arquivo que nunca é lido.
Verifique o diretório que o servidor realmente usa e depois confirme que o nome do arquivo corresponde exatamente à identidade autenticada, incluindo maiúsculas e minúsculas.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Dentro desse arquivo a rota ainda precisa ser enviada por push, porque o contexto por cliente é um conjunto de opções aplicadas à sessão daquele cliente, não uma tabela de roteamento local. Uma rota nua ali tem o mesmo problema que uma rota nua no arquivo global.
O arquivo do próprio cliente e a ferramenta que o gerencia
Uma rota colocada na configuração do cliente é instalada quando aquele cliente se conecta e removida quando se desconecta, que é o ciclo de vida correto para um destino estático.
Se um gerenciador de rede é dono do perfil, ele pode importar essas opções uma vez e depois manter a própria cópia. Editar depois o arquivo baixado não muda nada, o que é uma causa comum de "a rota está lá mas não se aplica".
Verifique o perfil ativo em vez do arquivo que você baixou, e verifique as configurações importadas que o gerenciador exibe. Depois conecte e pergunte ao sistema qual caminho um endereço específico usa, em vez de supor que o túnel ganhou porque a rota existia em um arquivo de texto.
Verifique no cliente e depois confira o caminho de volta
Pergunte à própria tabela de roteamento do cliente pelo destino, não à do servidor. Uma consulta para um único host dentro do prefixo basta para mostrar a interface e o próximo salto que serão usados.
ip route get 10.60.0.10Se a consulta aponta para o túnel, a distribuição funcionou e o problema restante está em outro lugar. Se aponta para o gateway padrão, a rota não foi instalada, foi filtrada por uma opção do lado do cliente, ou pertence a um perfil que o cliente não usa.
Suponha que a distribuição funcionou e ainda assim nada responde: então verifique o encaminhamento no gateway, a rota de volta do outro lado e qualquer firewall entre eles. Uma rota escolhe um caminho, ela não concede acesso.