Qual componente realmente detém um limite de rotas do OpenVPN?

Um perfil com duzentas rotas funciona numa máquina e instala quarenta noutra. O motor, a integração que o inicia e o servidor que o alimenta têm voz, e cada um pode parar a lista num ponto diferente. Ler a falha como um único limite leva-o ao ficheiro errado. O mecanismo tem três fases, e a fase que parou deixa provas visíveis quando sabe o que procurar.

Três fases, três limites diferentes

Primeiro o motor analisa a opção e decide se esta versão a compreende. Depois a integração instala o que o motor relata, e o seu próprio código pode limitar ou remodelar a lista. Por fim o servidor decide quantas rotas enviará para uma determinada identidade, antes de qualquer fase do cliente ver alguma coisa. Três fases, três tetos, e apenas um deles é o número no perfil.

Elevar um teto não faz nada pelos outros. Uma rota enviada e rejeitada pode ser uma decisão de política no servidor, uma sobreposição que o cliente resolveu, ou um limite do instalador que descartou o excesso. Cada um desses casos tem uma correção diferente.

Separe os três antes de medir qualquer coisa. Um erro do analisador nomeia um token, um limite do instalador deixa uma tabela de rotas curta, e uma decisão de política não deixa absolutamente nada. As provas dizem-lhe que fase inspecionar primeiro.

O analisador fala primeiro

Uma opção desconhecida falha ruidosamente e cedo, e o texto do erro nomeia o token. Essa é a fase mais fácil de identificar: compare a mensagem exata com a versão instalada do motor, porque uma opção acrescentada numa versão é desconhecida na anterior. Um perfil copiado de uma implementação mais recente é a causa habitual dessa divergência. O analisador nunca ignora em silêncio uma diretiva que não reconhece.

Uma opção aceite não diz nada sobre o resultado. A análise tem sucesso, e a lista ainda pode ser cortada pelo instalador ou nunca ser oferecida pelo servidor. Trate uma análise limpa como permissão para continuar, não como prova.

Anote a cadeia de versão do binário que realmente correu, não da ideia que o gestor de pacotes tem do que está instalado. Esses dois discordam mais vezes do que se espera.

O instalador tem o seu próprio teto

O componente que detém a ativação pode ser um plugin do NetworkManager em vez do binário do motor, e pode impor o seu próprio limite antes de existir qualquer túnel. O seu editor pode mostrar um campo que o motor em execução nunca lê, ou ler um campo que o editor não mostra. Ambas as situações parecem um defeito do cliente visto de fora. Nenhuma delas se corrige editando o perfil.

Conte o que chegou em vez do que foi configurado. O comando ip route show dev tun0 lista as rotas instaladas, e comparar essa contagem com a lista enviada separa uma rota descartada de uma que nunca foi enviada. Uma contagem que corresponde ao envio devolve a suspeita ao servidor.

Uma camada de shell em torno do binário do motor para forçar um número maior tolda as atualizações e transforma a reversão em adivinhação. Também esconde o limite real de quem ler a configuração a seguir.

O servidor decide o que lhe foi oferecido

A política por cliente pode reduzir a lista antes de ser transmitida. Um ficheiro específico do cliente pode acrescentar rotas para uma identidade, ou uma política de grupo pode omiti-las, e o cliente não consegue distinguir uma rota filtrada de uma que nunca foi definida. É essa ambiguidade que torna o registo do servidor importante. Peça a lista de envio efetiva para essa identidade, não o modelo.

Compare o registo do servidor com a lista recebida. A diferença entre os dois é a camada de política, e é normalmente menor do que o perfil sugere.

Quando o desenho o permite, resuma as redes contíguas e elimine as entradas obsoletas. Menos rotas e mais amplas resolvem mais casos do que um teto mais alto.

Altere o número no lugar certo

Use a definição documentada do componente que realmente detém o limite. Se o campo faltar no plugin, verifique se o plugin é anterior à funcionalidade ou se outra base detém as rotas. Depois documente as versões do motor, do plugin e do servidor ao lado do valor escolhido. A atualização seguinte reabre a questão, e a nota é o que a torna respondível.

Teste novamente após qualquer atualização de qualquer um dos três. Um limite elevado no lugar certo desloca-se na mesma quando o componente que o aplica muda. O registo de versões é a única coisa que torna esse deslocamento previsível.