☰

O script de início do OpenVPN não executa um comando

tag-icon • tag-icon freebsd openvpn
O script de início do OpenVPN não executa um comando

Fundo: Estou configurando o Transmission (v2.93) e o OpenVPN (v2.4.6) em uma prisão (uma prisão do plugin FreeNAS 11.1) e quero adicionar um --upscript ao OpenVPN que solicitará que o Transmission altere sua porta de escuta (usando transmission-remoteo programa).

My openvpn.confcontém o seguinte (entre outros):

verb 4
script-security 2
up /usr/local/etc/openvpn/set_port.sh
up-restart ;only to make the up script be executed on restarts
           ;but disabling this changes nothing

e o set_port.shscript contém (um script mínimo que ainda reproduz o comportamento):

#!/usr/local/bin/bash
/usr/local/bin/transmission-remote --auth rpc_user:rpc_pass -p 6666 2>&1 > output.txt
echo 'the script itself runs: '$(pwd) $(whoami) > status.txt

O script possui todas as permissões (777) e o binário ( transmission-remote) possui todas as permissões. Estou ciente de que o caminho para o binário é na verdade um link virtual, então substituí-o pelo caminho real ( /usr/pbi/transmission-amd64/.sbin/transmission-remote), mas o comportamento que observo é o mesmo.

Problema: quando inicio o OpenVPN ( service openvpn start),o roteiro em sié executado, mas o comando real falha misteriosamente: a porta não está sendo atribuída (verificada examinandoGUI remota de transmissãoe o comando gera uma saída vazia.
O conteúdo dos arquivos de depuração é o seguinte:
output.txtestá vazio (com e semstderrredirecionamento)
status.txtdiz como esperado: the script itself runs: /usr/local/etc/openvpn root.

Porém, quando executo este script manualmente ( ./set_port.sh), o referido comando é concluído com sucesso: output.txtdirá localhost:9091/transmission/rpc/ responded: "success"e a porta será alterada.

o que estou perdendo?

Semelhanteparaessa questão, exceto que não estou recebendo nenhuma mensagem de "permissão negada" - parece que o comando nem foi executado (se eu echo $(<that command>) > file.txtreceber um arquivo vazio).
Estetambém está um pouco relacionado, mas o OP está perguntando --client-connecte eventualmente resolve o problema escrevendo caminhos completos para os programas que deseja executar - isso não ajudou no meu caso (mas se eu estiver echo $(ls /usr/local/bin) > log.txt, a lista de binários está correta).

Atualizara pedido de @roaima. Eu mudei set_port.shpara o seguinte:

#!/usr/local/bin/bash
exec >debug.txt 2>&1
set -x
echo script is running
/usr/pbi/transmission-amd64/.sbin/transmission-remote  --auth rpc_user:rpc_pass -p 6666 2>&1 > output.txt

depois enxaguado e repetido. O debug.txtarquivo continha estas linhas:

+ echo script is running
script is running
+ /usr/pbi/transmission-amd64/.sbin/transmission-remote --auth rpc_user:rpc_pass -p 12345
/usr/local/etc/openvpn/test.sh: line 5:  6795 Segmentation fault      /usr/pbi/transmission-amd64/.sbin/transmission-remote --auth rpc_user:rpc_pass -p 12345 2>&1 > output.txt

Responder1

Olhando para a linha

/usr/local/etc/openvpn/test.sh: line 5:  6795 Segmentation fault      /usr/pbi/transmission-amd64/.sbin/transmission-remote --auth rpc_user:rpc_pass -p 12345 2>&1 > output.txt

Parece que seus executáveis ​​possuem bibliotecas incompatíveis. Verifique novamente como você construiu seu chroot. (Eu não uso o FreeBSD há anos e anos, então não posso lhe dar dicas sobre como fazer isso, desculpe.)

Responder2

Não tenho ideia da incompatibilidade de biblioteca que está acontecendo aqui, principalmente que tudo acontece em uma "prisão de plugins" do FreeNAS e não sei como ela está configurada. No entanto, consegui contornar o problema para atingir o objetivo de fazer com que o OpenVPN configure a transmissão na rota.
Observação: a resposta a seguir NÃO resolve o problema de falha de segmentação, portanto não vou marcá-la como aceita.

A solução é baseada na seguinte observação: embora transmission-remotetenha falhado se for chamado pelo OpenVPN, ele funcionou perfeitamente se cronchamado:

  1. Deixe openvpn.confcomo está.

  2. Em set_port.sh, em vez de chamar transmission-remote, armazene o número da porta em um arquivo - por exemplo, assim: echo $port > $path/port-id(daqui em diante assumirei que a variável pathleva à pasta onde armazenamos os scripts, etc.)

  3. Faça um novo script, vamos chamá-lo de actually_set.sh, com o seguinte:

#!/usr/local/bin/bash
if [ -f $path/port-id ]; then
  port=$(cat $path/port-id)
  rm $path/port-id
  transmission-remote -n 'rpc_user:rpc_pass' -p $port
fi
  1. Defina cronpara chamar o script acima a cada minuto. Coloquei o seguinte no meu crontab:
    * * * * * /usr/local/etc/openvpn/ports/tp_setter.sh

Responder3

Se você definir seu verbnível como 3-4, provavelmente verá avisos sobre scripts que não estão sendo executados. Por padrão, o OpenVPN 2.2+ chama apenas alguns recursos integrados. Você precisa relaxar isso usandoscript-security:

--script-security level

Esta diretiva oferece controle em nível de política sobre o uso de programas e scripts externos pelo OpenVPN. Valores de nível mais baixo são mais restritivos, valores mais altos são mais permissivos.

Configurações de nível:

0-- Estritamente nenhuma chamada de programas externos.
1-- (Padrão) Chame apenas executáveis ​​integrados, como ifconfig, ip, route ou netsh.
2-- Permite a chamada de executáveis ​​integrados e scripts definidos pelo usuário.
3-- Permitir que senhas sejam passadas para scripts por meio de variáveis ​​ambientais (potencialmente inseguras).

Você precisa ter certeza de ter script-securitydefinido como 2 ou 3 (2 se não precisar enviar senhas para o script, 3 caso contrário).

informação relacionada