Carregar o Openvpn Config no boot e montar o drive de rede não funcionará no Debian

3

Eu tenho este script:

#! /bin/sh
# /etc/init.d/vpnscript

### BEGIN INIT INFO

# Short-Description: Simple script to start a program at boot 
# Description:       A simple script from http://www.stuffaboutcode.comwhich    will start / stop a program a boot / shutdown.
### END INIT INFO

# If you want a command to always run, put it here

# Carry out specific functions when asked to by the system
case "$1" 
in start)
echo "Connecting to OPENVPN"
# Connect to the VPN
sudo openvpn /etc/openvpn/connection1.ovpn
sudo mount -a
;;
stop)
echo "Stopping OPENVPN"
# Disconnect
killall openvpn
;;
*)
echo "Usage: /etc/init.d/vpnscript {start|stop}"
exit 1
;;
esac

A parte Openvpn funciona bem, mas se ele tentar usar sudo mount -a , o processo começa a não fazer nada (ou esperar por algo, não sei).

Existe outra maneira de fazer o que eu quero ou algo está errado com o meu script? Eu sou um iniciante em scripts de shell.

Algumas notas:

  • Eu tentei usar o modo Debian de iniciar o OpenVPN ( /etc/default/openvpn ), mas isso não inicializou, então tentei desta forma.

  • O principal mount -a do sistema acontece antes do OpenVPN iniciar, e eu tenho uma entrada em /etc/fstab que se refere a uma unidade de rede através da conexão OpenVPN.

  • O servidor executa o Openmediavault 3.0.

por Sebastian G. 27.01.2017 / 15:16

2 respostas

2

O problema básico que você está vendo é que o OpenVPN permanece em execução - portanto, o sudo openvpn /etc/openvpn/connection1.ovpn nunca retorna. Seu script, portanto, nunca chega à próxima linha. (Também: scripts init são executados como root, então não deve haver um sudo ). Então, trivialmente, você precisa adicionar um e comercial ( & ) ao final dessa linha ou, melhor ainda, dar ao OpenVPN a opção --daemon (mas leia os documentos do OpenVPN sobre as limitações disso).

É claro que você deve apenas usar a maneira de o Debian ativar uma VPN: em Jessie, seria systemctl enable [email protected] . Pré-jessie, ou no Jessie sem systemd, que estaria editando /etc/default/openvpn e alterando a linha AUTOSTART . (Provavelmente você precisará alterar a extensão de .ovpn para .conf também).

Então você encontrará o próximo problema: o OpenVPN retornará antes da VPN. Mas você não pode iniciar a montagem até que a VPN esteja realmente passando tráfego. A maneira mais fácil que encontrei para consertar isso é um serviço systemd que pinga a extremidade remota da VPN:

$ cat vpn-really-up.service
[Unit]
Description=Ping Einstein to make sure the VPN is really up
[email protected] 
[email protected] 

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/ping -c 2 -w 300 192.168.X.Y
TimeoutStartSec=330

Claro, você pode usar essa linha de ping em um script init.d também. (Observe que isso pode não ser a melhor maneira de fazer isso, por exemplo, talvez um comando --route-up seja melhor, não tenho certeza se eles não existiam quando eu configurá-lo ou se Eu não sabia sobre eles. Minha máquina está realmente executando testes.)

Em seguida, você pode criar unidades de montagem systemd para o seu sistema de arquivos (note que este também depende dnsmasq, porque eu uso isso para obter alguns domínios encaminhados para um servidor DNS através da VPN, para que os nomes internos funcionem):

$ cat mnt-Einstein-music.mount 
[Unit]
Description=/mnt/Einstein/music
Requires=dnsmasq.service vpn-really-up.service
After=dnsmasq.service vpn-really-up.service remote-fs-pre.target

[Mount]
Where=/mnt/Einstein/music
What=Einstein.home:/srv/music
Options=nosuid,nodev,intr,rsize=4096,wsize=4096,nfsvers=3,fsc
Type=nfs
TimeoutSec=180s

[Install]
WantedBy=multi-user.target

(Montar em uso também funcionaria e é bem fácil com o systemd - veja man 5 systemd.automount ).

Por fim, seu destino de parada precisa ser corrigido: você deve desmontar os sistemas de arquivos antes de interromper a VPN. Caso contrário, sua máquina irá travar na reinicialização / desligamento. E você deve testar se funciona - caso contrário, você vai ssh para a máquina um dia e reiniciá-lo, e tem que fazer uma viagem não planejada para apertar o botão de reset.

PS: Eu também tenho este arquivo:

$ cat [email protected]/local-after-ifup.conf 
[Unit]
Requires=networking.service
After=networking.service

... meu palpite está em um ponto que era necessário para garantir que o OpenVPN (e, portanto, todos os sistemas de arquivos sobre VPNs) fossem interrompidos antes que o systemd parasse as interfaces de rede.

    
por 27.01.2017 / 16:51
0

Atualização breve.

OPENVPN funciona bem agora, obrigado.

A última coisa que preciso para conseguir um trabalho é:

$ cat mnt-SHAREDNAS.mount 
[Unit]
Description=/mnt/SHAREDNAS
Requires=vpn-really-up.service
After=vpn-really-up.service remote-fs-pre.target

[Mount]
Where=/mnt/SHAREDNAS
What=//192.168.50.10/Users/RsyncNAS/SharedNASData
Options=uid=root,credentials=/root/.smbcredentials,iocharset=utf8,sec=ntlm   0       0
Type=cifs
TimeoutSec=180s

[Install]
WantedBy=multi-user.target

Mas monte retornos com     erro (22): argumento inválido.

Então, minha pergunta é: qual é o caminho certo para transformar essa linha fstab abaixo em um arquivo .mount correto:

//192.168.50.10/Users/RsyncNAS/SharedNASData  /media/SHAREDNAS  cifs   uid=root,credentials=/root/.smbcredentials,iocharset=utf8,sec=ntlm   0       0
    
por 01.02.2017 / 16:07