Qual binário do openvpn está em execução? Verifique o caminho de arranque

Uma solução antiga moveu o executável do OpenVPN para outro sítio e deixou um invólucro shell no caminho original. Meses depois chega uma atualização, e desfazer a solução torna-se um jogo de adivinhação sobre qual ficheiro é realmente o cliente. O nome do comando, o executável configurado no serviço e o próprio inventário de ficheiros do pacote podem apontar para objetos diferentes, e reparar um sem os outros produz um anfitrião que parece arranjado e comporta-se pior.

Comece pelo caminho que o serviço lança

Um terminal e uma unidade systemd não resolvem os executáveis da mesma forma. A shell procura num PATH; a unidade nomeia um caminho, e as sobreposições drop-in podem substituí-lo sem tocar no ficheiro que está a ler. Essa diferença explica a maior parte da confusão nesta tarefa. Também decide para que ficheiro a sua reparação tem de apontar.

Pergunte à unidade o que executa, incluindo as sobreposições drop-in que a alteram, e leia a linha ExecStart resultante em vez do fragmento que assume como autoritativo. Depois siga esse caminho através de qualquer ligação simbólica até ao ficheiro final. Um invólucro que termina com exec num diretório oculto é uma disposição comum destas correções antigas.

Anote o caminho resolvido antes de alterar qualquer coisa.

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

Compare o nome do comando com o caminho do serviço

As duas respostas são frequentemente diferentes, e essa diferença não é automaticamente uma falha. Um plugin do NetworkManager pode lançar o seu próprio caminho, e um contentor pode montar outro.

O que importa é saber que proprietário lança o processo que serve o tráfego. Se a unidade executa /usr/local/sbin/openvpn-wrapper enquanto a sua shell resolve /usr/sbin/openvpn, reparar o segundo ficheiro não muda nada no serviço.

Pergunte que pacote possui cada candidato e depois decida se o ficheiro é gerido pelo pacote ou colocado localmente. Um ficheiro sem pacote proprietário é um ficheiro que alguém colocou ali de propósito, e merece um nome, um proprietário e uma razão antes de ser apagado. O erro inverso também é comum: sobrescrever um ficheiro de pacote com um binário antigo guardado porque uma publicação de fórum usou o mesmo diretório.

Deixe a base de dados de pacotes falar dos ficheiros do pacote

Quando o software veio de um pacote Debian, a base de dados de pacotes pode dizer-lhe se os ficheiros ainda correspondem ao que foi instalado. É uma questão estreita de integridade, não um veredicto de segurança, e a diferença importa quando decide o que reparar. Uma discrepância significa que o ficheiro mudou após a instalação, o que pode ser a sua solução antiga ou uma edição local legítima. A saída não decide qual, por isso leia-a como uma indicação e não como uma conclusão.

Execute a verificação e leia a saída em vez de tratar um resultado vazio como prova de alguma coisa.

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

O manual do dpkg documenta que a verificação compara os ficheiros instalados com metadados registados localmente, usando as somas de verificação guardadas quando existem. Deteta um ficheiro de pacote alterado, e não consegue dizer-lhe se está a ser lançado outro binário em vez dele.

Registe o estado antes de reparar

Reúna o caminho de arranque resolvido, a relação do ficheiro com o pacote, a localização do invólucro e o registo de alterações que o introduziu. Copie o invólucro para um local protegido se contiver trabalho de integração que será necessário mais tarde.

Não cole o conteúdo do invólucro num tópico de suporte antes de o ler, porque estes scripts por vezes transportam credenciais ou detalhes da gateway.

Registe que perfis o serviço usa e quem está ligado enquanto trabalha, porque reiniciar o túnel pode interromper a sessão com que administra o anfitrião.

Verifique o arranque e depois retire o invólucro

Após a reparação, inicie o serviço e confirme que o processo executa o caminho pretendido. Uma consulta de versão feita à mão prova que o ficheiro funciona; não prova que a unidade o use.

Depois volte a ligar um cliente e verifique se o perfil ainda autentica, porque uma troca de binário que ignora as opções originais falhará de uma forma que parece um problema de certificado.

Retire o invólucro deslocado através do mesmo registo de alterações que o introduziu. A reparação concluída indica que executável está em execução, porquê, e que ficheiro foi removido; restaurar um nome de ficheiro e esperar não é a mesma coisa.