OpenVPN no Debian está rejeitando conexões e systemd apenas executa / bin / true?

Question

Estou extremamente confuso com isso, e parece completamente errado, mas não tenho ideia de como vou começar do começo.

Eu configurei o openvpn no meu servidor Debian usando este guia . Depois que copiei os arquivos necessários para a área de trabalho do archlinux e tentei executar o script, percebi que a conexão acabou de expirar:

$ openvpn server.ovpn
Thu Aug  2 18:50:29 2018 OpenVPN 2.4.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2018
Thu Aug  2 18:50:29 2018 library versions: OpenSSL 1.1.0h  27 Mar 2018, LZO 2.10
Thu Aug  2 18:50:29 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]<server-ip>:1194
Thu Aug  2 18:50:29 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Thu Aug  2 18:50:29 2018 UDP link local: (not bound)
Thu Aug  2 18:50:29 2018 UDP link remote: [AF_INET]<server-ip>:1194
Thu Aug  2 18:50:29 2018 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Thu Aug  2 18:51:29 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Aug  2 18:51:29 2018 TLS Error: TLS handshake failed
Thu Aug  2 18:51:29 2018 SIGUSR1[soft,tls-error] received, process restarting
Thu Aug  2 18:51:29 2018 Restart pause, 5 second(s)
^CThu Aug  2 18:51:32 2018 SIGINT[hard,init_instance] received, process exiting

Eu pensei que poderia ser um problema de firewall, então decidi abandonar temporariamente o firewall enquanto testava isso, mas não tive sorte (fiz isso no meu cliente e no meu servidor):

$ sudo iptables -L -v
Chain INPUT (policy ACCEPT 15 packets, 1056 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 8 packets, 768 bytes)
 pkts bytes target     prot opt in     out     source               destination

Eu decidi me certificar de que estava realmente tentando fazer uma conexão, então eu abri o wireshark e vi isso:

1   <my-ip>         <server-ip> OpenVPN 56  MessageType: P_CONTROL_HARD_RESET_CLIENT_V2
2   <server-ip>     <my-ip>     ICMP    84  Destination unreachable (Port unreachable)
3   <my-ip>         <server-ip> OpenVPN 56  MessageType: P_CONTROL_HARD_RESET_CLIENT_V2
4   <server-ip>     <my-ip>     ICMP    84  Destination unreachable (Port unreachable)
15  <my-ip>         <server-ip> OpenVPN 56  MessageType: P_CONTROL_HARD_RESET_CLIENT_V2
16  <server-ip>     <my-ip>     ICMP    84  Destination unreachable (Port unreachable)
29  <my-ip>         <server-ip> OpenVPN 56  MessageType: P_CONTROL_HARD_RESET_CLIENT_V2
32  <server-ip>     <my-ip>     ICMP    84  Destination unreachable (Port unreachable)
51  <my-ip>         <server-ip> OpenVPN 56  MessageType: P_CONTROL_HARD_RESET_CLIENT_V2
52  <server-ip>     <my-ip>     ICMP    84  Destination unreachable (Port unreachable)

Desde que eu sei que não há nenhuma regra de firewall bloqueando, eu fui ver se vpn aberta é par, rodando:

$ sudo lsof -i | grep -i vpn
$ sudo ps ax | grep -i vpn
19969 pts/0    S+     0:00 grep -i vpn

Nada volta. Eu verifico o systemd para ter certeza de que ele não travou:

$ systemctl status openvpn
● openvpn.service - OpenVPN service
   Loaded: loaded (/lib/systemd/system/openvpn.service; enabled; vendor preset: enabled)
   Active: active (exited) since Thu 2018-08-02 09:37:24 CDT; 11h ago
  Process: 12769 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 12769 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/openvpn.service

Diz que saiu do sucesso, mas depois notei " ExecStart = / bin / true ". O que o diabo? Eu abro o arquivo de serviço e vejo isto:

$ cat /lib/systemd/system/openvpn.service
# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.

[Unit]
Description=OpenVPN service
After=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecReload=/bin/true
WorkingDirectory=/etc/openvpn

[Install]
WantedBy=multi-user.target

Eu admito, o openvpn é um software complexo que eu não entendo completamente, mas como o ExecStart=/bin/true está correto? Eu tenho dificuldade em acreditar que este é apenas um espaço reservado que de alguma forma entrou em produção desde que alguém muito mais esperto do que eu teria pego agora, mas eu simplesmente não entendo. Qual é o sentido disso e como faço o openvpn esperar para pré-formatar o aperto de mão?

    

Answer 1

I admit, openvpn is a complex piece of software I don't fully understand, but how is ExecStart=/bin/true correct?

Este não é um recurso do OpenVPN, é um recurso do systemd. Na maioria dos sistemas com systemd, o OpenVPN será fornecido com uma unidade modelo e um gerador. Isso permite que seu sistema ofereça suporte a várias instâncias do OpenVPN e que o systemd monitore e controle cada VPN separadamente

Nos sistemas Debian, a unidade modelo que você gostaria de ver está aqui. /lib/systemd/system/[email protected] e o gerador está aqui /lib/systemd/system-generators/openvpn-generator .

Essa unidade de modelo tem um ExecStart como este.

ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status /run/openvpn/%i.status 10 --cd /etc/openvpn --config /etc/openvpn/%i.conf --writepid /run/openvpn/%i.pid

Por exemplo, no meu sistema, tenho algumas configurações de VPN em execução

# systemctl list-units | grep openvpn
openvpn.service                 loaded active exited    OpenVPN service                                                              
[email protected]    loaded active running   OpenVPN connection to zoredachesrv                                              
[email protected]  loaded active running   OpenVPN connection to p2p-to-valiant   

Você pode consultar instâncias openvpn individuais com um comando como systemctl status [email protected] .

Se você acabou de adicionar essa configuração, talvez seja necessário usar systemctl daemon-reload para systemd para reconhecer as novas unidades.

Se a sua configuração é literalmente chamada 'server.conf' e isso não é ofuscado, então você usaria systemctl status [email protected]

Quanto à solução de problemas, sugiro que você verifique se o openvpn está em execução e tem um soquete aberto lsof -ni | grep openvpn . Em seguida, verifique também o que o OpenVPN relatou erros ou qualquer coisa no log do sistema grep openvpn /var/log/syslog | tail -50 . Uma dessas duas coisas deve lhe dar uma dica sobre o que está acontecendo.