OpenVPN 3 Linux: leia um erro D-Bus antes de reverter

As falhas do OpenVPN 3 Linux chegam como um erro de método D-Bus com um nome desconhecido anexado, e a tentação é retroceder um pacote e esperar. O cliente não é um único programa: uma interface de linha de comandos fala pelo barramento com serviços que detêm os perfis, as sessões, o motor VPN e as alterações de rede privilegiadas. Decidir qual desses cinco detém a chamada que falha é a maior parte do diagnóstico, e custa um comando em vez de uma reversão. O que se segue é essa decisão, na ordem em que as falhas costumam aparecer.

Cinco responsáveis por trás de um comando

Cinco processos importam, e cada um tem o seu próprio nome de barramento: a interface que aceita o seu comando, o gestor de configuração que guarda os perfis e a sua política de acesso, o gestor de sessões que detém o tempo de vida das sessões, o backend que executa a ligação através do OpenVPN 3 Core Engine, e o serviço de configuração de rede que instala a interface, as rotas e as definições de DNS. Um erro que nomeia um objeto de configuração não é, portanto, um erro do backend, e um backend que não arranca não é uma falha de autenticação. Classificar a mensagem numa dessas linhas tem de acontecer antes de se mudar seja o que for, porque cada passo posterior depende de qual linha é verdadeira. Adivinhar a linha é a forma como uma correção curta se transforma numa tarde de trabalho com pacotes.

Pergunte ao barramento de sistema que serviços estão presentes antes de perguntar qualquer outra coisa, e confirme depois que as peças instaladas concordam numa versão. O OpenVPN 3 Linux registra esses serviços como unidades de sistema, por isso o barramento a consultar é o de sistema, a consulta de versão exige autoridade administrativa, e uma listagem feita com --user lê a sua sessão de início de sessão, onde as unidades nunca aparecem. Os serviços ativam-se a pedido e alguns terminam quando estão inativos, por isso um serviço em falta antes do seu primeiro pedido simplesmente ainda não foi questionado sobre nada. Os três comandos abaixo respondem sobre presença, versão e estado das unidades sem abrir uma sessão VPN.

sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'

O que cada lista realmente prova

As vistas do próprio cliente são a prova mais barata disponível, e cada uma delas prova menos do que parece. Um perfil na lista de configuração mostra que um perfil está importado e nada sobre se alguém pode ligar-se com ele. Uma sessão na lista de sessões mostra que existe um objeto de sessão e nada sobre se a autenticação remota terminou.

openvpn3 configs-list
openvpn3 sessions-list

Os caminhos de objeto nessas saídas identificam objetos geridos no barramento e não ficheiros, por isso não podem ser editados, e um caminho registado antes fica desatualizado no momento em que essa sessão se desliga. Reutilizar um das suas notas produz erros "no such object" que nada têm a ver com a VPN. A tabela de etapas abaixo separa o que cada passo de uma ligação estabelece do que deixa em aberto, e é precisamente essa distinção de que depende uma decisão de reversão. Leia a linha que corresponde à sua prova e depois releia o texto do erro.

A chamada de ligação regressa antes de o túnel existir

A chamada de ligação entrega-lhe uma sessão para observar e regressa, e é por isso que uma chamada aparentemente bem-sucedida seguida de silêncio é um estado intermédio normal e não uma contradição. A interface continua a ter de seguir as mudanças de estado e responder a qualquer pedido de interação. Um perfil que precisa de uma credencial e não recebe resposta espera num estado que se parece exatamente com um backend bloqueado. Esse estado de espera merece reconhecimento, porque manda as pessoas para o componente errado.

Enquanto uma tentativa está em curso, vigie a lista de sessões e o registo da própria interface para esse perfil. Uma sessão que nunca sai do seu estado inicial nomeia o componente que parou, e o registo costuma nomeá-lo nas primeiras linhas. Tenha o nome do perfil à mão, pois o comando de registo aceita um perfil e não um caminho de sessão, o que é mais uma razão para reler a lista em vez de reutilizar um caminho.

openvpn3 sessions-list
openvpn3 log --config <profile> --level 6

Ler o registo de um componente sem abrir uma sessão

Quando a interface não relata nada de útil, vá para o componente que registou a falha em vez de iniciar outra ligação. Com um logger systemd-journald configurado, a vista de journal delimitada do administrador lê os eventos de um componente sem tocar na política do barramento nem abrir uma sessão, o que importa porque um diagnóstico que altera o sistema que mede prova muito pouco. Filtre por unidade em vez de por etiqueta syslog: as unidades de serviço individuais não garantem um identificador partilhado, por isso uma consulta por etiqueta pode devolver uma página vazia enquanto a própria unidade registou a falha.

Anote quatro campos antes de pedir ajuda a alguém: o nome completo do erro, o serviço e o objeto envolvidos, o carimbo temporal e as versões dos pacotes instalados. É disso que um mantenedor precisa, e nada disso exige colar um perfil ou uma credencial num pedido de suporte. Alargar a política de acesso ao barramento para silenciar o erro não é um diagnóstico, apaga a fronteira que estava a nomear o componente por si. O conteúdo privado dos perfis fica fora de relatórios partilhados pela mesma razão que as credenciais.

journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>

Corrigir a fronteira que recusou

Cada linha do mapa tem a sua própria correção, e as linhas não se substituem umas às outras. Uma operação negada num perfil é uma questão de política e de propriedade, enquanto um backend que não ativa é uma questão de serviços e de empacotamento. Um servidor que rejeita a autenticação não é nenhum dos dois, por isso mudanças repetidas de palavra-passe não conseguem reparar um problema de ativação local. Escolher a correção errada é a forma como um problema de política se transforma numa reinstalação.

Depois de uma alteração de pacotes, verifique uma instalação coerente e suportada em vez de copiar um binário antigo para o lugar. Uma reversão controlada é uma resposta legítima a uma regressão confirmada, desde que os pacotes permaneçam compatíveis e exista um caminho de volta à manutenção suportada. Estabeleça esse caminho antes de o serviço deixar de arrancar, não depois.

Outra plataforma pode partilhar a mesma biblioteca VPN central sem partilhar os serviços de barramento do Linux, por isso uma falha de aspeto semelhante no Windows não diz nada sobre esta. A visão geral do D-Bus documenta os caminhos de objeto expostos para configurações e sessões, e é essa a parte da arquitetura de que este diagnóstico depende. Leia-a uma vez, e o próximo erro chegará com um componente já ligado a ele.