Dois clientes OpenVPN num único host Linux: a quem pertence a rota?

Ambos os perfis relatam ligação e um deles transporta silenciosamente tráfego destinado ao outro. Dois clientes num único host é uma disposição suportada; dois clientes sem dono para cada prefixo não é. O trabalho trata menos de levantar o segundo túnel e mais de decidir que processo pode reclamar que rota. Percorra a ordem abaixo e a configuração decorre das respostas.

Comece por perguntar para que serve o segundo túnel

Três situações parecem idênticas na linha de estado e exigem desenhos diferentes. Uma divisão por destinos envia um prefixo pelo perfil de escritório e outro pelo perfil de laboratório, sem que nenhum reclame uma rota predefinida. Uma divisão por aplicação costuma manter um túnel completo e encaminhar tráfego concreto com regras de política. A comutação por falha mantém exatamente um túnel ativo de cada vez, o que significa que o segundo não deve arrancar automaticamente.

Escreva o caso antes de abrir qualquer ficheiro de configuração, porque essa resposta decide tudo o que vem depois.

A disposição avariada mais comum são dois túneis completos que ambos empurraram uma rota predefinida, onde ganha o que se ligou por último e o primeiro continua a fingir. Esse estado parece intencional visto da linha de estado e desperdiça um dia da tabela de rotas. Nomear o caso primeiro torna-o impossível, não apenas improvável.

Olhe para os pools antes das rotas

Dois servidores podem facilmente distribuir endereços de um só intervalo privado e, quando o fazem, o cliente acaba com duas interfaces dentro de um único prefixo. Nenhum destino pode então ser atribuído a uma interface por endereço, porque ambos parecem igualmente corretos. Renumere um pool em vez de inventar uma regra para desfazer o empate.

Verifique também a rede local, porque uma LAN doméstica ou de escritório que se sobreponha a um intervalo de túnel cria a mesma ambiguidade do outro lado. Compare os endereços do host com ambas as configurações de servidor antes de culpar o cliente. Uma mudança de pool num servidor de laboratório é uma correção de cinco minutos, enquanto um desvio de encaminhamento por política para um prefixo sobreposto é um imposto permanente para todos os que lerem a configuração mais tarde. Decida qual dos dois quer antes de escolher onde intervir.

Duas famílias de endereços significam duas rondas desta verificação. Os pools IPv6 colidem tão silenciosamente como os IPv4.

Dê a cada perfil um dono

Uma instância por perfil, um ficheiro de configuração por instância e um nome que identifique o par. No empacotamento ao estilo Debian, o nome depois do sinal @ seleciona o ficheiro, e é por isso que dois perfis que partilham um nome de instância nunca podem funcionar ambos. Confirme a correspondência a partir da unidade instalada e não de um tutorial.

systemctl cat [email protected]
ip -4 addr show

Depois decida quem instala as rotas, que é uma questão de política e não de sintaxe.

Quando os dois servidores empurrarem conjuntos incompatíveis, ou acrescente route-nopull e liste apenas os prefixos de que cada perfil precisa, ou deixe um conservar a sua rota predefinida e encaminhe o resto com uma regra de política. Dois processos que ambos instalam uma rota predefinida acabam com um só vencedor e ninguém consegue dizer porquê. Assim que os dois túneis transportam tráfego de fontes diferentes, uma resposta pode sair pelo errado, e o padrão que aguenta é uma marca de ligação restaurada nas respostas e encaminhada para a sua própria tabela. Limite as marcas para que os pacotes cifrados dos próprios túneis nunca correspondam a elas.

Verifique por túnel e depois pare um

Quando ambos estiverem ativos, recolha três leituras: o endereço de cada dispositivo de túnel, a rota para um host que viva atrás de cada um e o caminho que um destino fora de ambos tomaria. Uma listagem de rotas comum deixa de descrever a consulta final assim que entram regras em jogo, por isso pergunte ao núcleo o que escolheria realmente. Depois pare uma instância e veja o que desaparece. Se parar a primeira perturbar a segunda, algo continua partilhado entre elas: uma rota, um nome de dispositivo ou uma regra de firewall que ninguém separou.

ip rule show
ip route get 203.0.113.9

Volte a levantar o perfil parado e repita as mesmas verificações, porque um túnel que funciona uma vez após um reinício e nunca mais é um erro de ciclo de vida disfarçado de encaminhamento.

Anote nas notas de implementação qual perfil possui qual prefixo, ao lado dos intervalos de pools. Dois túneis são uma disposição deliberada, e o próximo leitor precisa de ver o limite antes de tocar em qualquer perfil. Sem essa nota, o limite é redescoberto por quem estiver de serviço quando o prefixo partilhado finalmente se quebrar.