O OpenVPN diz active (exited)? Encontre a instância que você iniciou

Você verifica o túnel, executa systemctl status openvpn e obtém active (exited) sem Main PID e com uma lista de processos vazia. A leitura natural é que o serviço iniciou e morreu, então você abre a unit, encontra /bin/true e conclui que o pacote está quebrado. No empacotamento Debian esse estado é o wrapper trabalhando como projetado, e o túnel vive em uma das units de instância que ele inicia. A unit agregada nunca dirá qual instância a construiu.

O que active (exited) realmente significa nesta unit

A unit empacotada é uma tarefa única: seu ExecStart é /bin/true, e RemainAfterExit=yes é o que mantém uma unit concluída reportada como active (exited). Retire essa diretiva e a mesma tarefa /bin/true bem-sucedida termina em inactive (dead), exatamente o estado que as pessoas esperam e leem errado na direção oposta. O comando é apenas um marcador, e a unit informa sobre trabalho que outras units realizam. Nada nesse arranjo está quebrado, e substituir /bin/true muda o contrato de empacotamento, não o túnel.

O wrapper delega. Ele inicia as units de instância fornecidas pela configuração do pacote ou pelo gerador systemd, e é por isso que uma lista de processos vazia não prova nada sobre o túnel. Quando nenhuma instância está selecionada, o wrapper ainda tem sucesso e ainda não inicia nada. O estado responde se o wrapper rodou, não se existe um túnel.

Leia as três linhas da saída de status em vez da palavra entre parênteses. Loaded nomeia o arquivo de unit que o systemd leu, Active carrega o carimbo de tempo da última execução bem-sucedida, e a ausência de Main PID combina com uma tarefa única concluída. Essas três linhas são também como distinguir este wrapper de um serviço que caiu um segundo após iniciar.

Liste as units antes de ler o status de novo

Pergunte ao systemd o que existe antes de perguntar o que está rodando. Um modelo pode estar instalado enquanto nenhuma instância é criada, e apenas uma unit criada carrega um túnel. Comece pelo conjunto carregado:

systemctl list-units 'openvpn*'

Essa lista é o que o systemd carregou neste momento, e é a coisa mais próxima de um inventário de túneis. Arquivos de unit instalados respondem outra pergunta, e essa lista ainda mostra um modelo quando nada foi criado:

systemctl list-unit-files 'openvpn*'

Leia as duas listas juntas, porque um modelo na segunda e uma instância na primeira são respostas diferentes. Um modelo que existe e uma instância que roda não são o mesmo fato, e só o segundo significa um túnel. Os arranjos de pacote também variam entre distribuições e versões do OpenVPN. Um modelo openvpn@ mais antigo, um par separado de client e server e um wrapper de distribuição podem ser todos legítimos no próprio empacotamento.

Adapte-se à sua máquina e não ao tutorial que você encontrou. O nome da instância na saída de outra pessoa pode ser office enquanto o seu é home ou work. O que se transfere é o método, não a string.

Siga o nome da instância até o arquivo que ela lê

No modelo client upstream o diretório de trabalho da unit é /etc/openvpn/client e o comando dela pega %i.conf dali, então openvpn-client@office lê /etc/openvpn/client/office.conf. Confirme esse mapeamento na unit instalada em vez de confiar no exemplo, porque o modelo que você tem pode ser mais antigo ou uma reescrita da distribuição:

systemctl cat [email protected]

Leia os drop-in que aparecem no fim dessa saída, porque um arquivo sob .d/ pode mudar o ExecStart, o diretório de trabalho ou o caminho de configuração. Um perfil que você baixou como office.ovpn não é o arquivo que a instância abre. Essa lacuna é a razão comum de um erro nomear um caminho que você nunca editou.

Caminhos relativos dentro do perfil são a próxima armadilha. Mover o arquivo principal enquanto as referências ca, cert e key continuam relativas troca um erro de arquivo ausente por outro erro de arquivo ausente. O segundo aponta um arquivo que você tinha certeza que existia, e por isso o diretório do perfil importa mais que o nome do arquivo.

Inicie-a e depois leia o journal dessa instância

Inicie a instância que você acabou de inspecionar, porque o log da unit agregada não conterá os erros do túnel. Depois leia o journal desta inicialização e procure nessa ordem um erro de configuração, um erro de acesso a arquivo e um erro de conexão, porque cada um falha em um estágio diferente do início.

sudo systemctl start [email protected]
journalctl -u [email protected] -b

Iniciar e habilitar são decisões separadas: start executa a unit agora, enable prepara o próximo boot e enable --now faz as duas coisas em um passo. daemon-reload relê as definições de unit e não reinicia um processo em execução nem aplica um perfil editado. Depois de mudar o perfil, reinicie a instância, porque é isso que relê o arquivo.

Não coloque um segundo gerenciador no mesmo túnel

O NetworkManager e os gerenciadores de sessão do OpenVPN 3 têm o próprio estado de conexão, e uma instância systemd ao lado de um deles coloca dois donos no mesmo túnel. O sintoma é um túnel que sobe e é substituído segundos depois, ou um que se recusa a ficar parado. Escolha o gerenciador que a sua distribuição documenta para a área de trabalho e use o systemd deliberadamente em um servidor.

Verifique se já existe um dono antes de iniciar uma instância. Quando um applet da área de trabalho mostra a conexão, a instância que você inicia compete com ele em vez de completá-lo. Desative o gerenciador que você não usa em vez de executar os dois e esperar que a ordem se mantenha. Esse conflito também explica journals em que um túnel é estabelecido e depois desfeito por um processo que você nunca iniciou.

Responda à pergunta original com o nome da instância, o arquivo que ela leu e a linha de journal que falhou. As notas do OpenVPN sobre integração com o systemd descrevem o arranjo do modelo e o mapeamento de arquivo pelo qual o nome da instância é resolvido.