web-dev-qa-db-ja.com

Debian上のOpenVPNは接続を拒否し、systemdは/ bin / trueを実行するだけですか？

私はこれに非常に混乱していて、それは完全に間違っているように見えますが、どうすればよいかわからないので、最初から始めます。

this ガイドを使用して、Debianサーバーにopenvpnを設定しました。必要なファイルをarchlinuxデスクトップにコピーしてスクリプトを実行しようとしたところ、接続がタイムアウトしたことがわかりました。

$ 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

ファイアウォールの問題かもしれないと思ったので、これをテストしている間、ファイアウォールを一時的に削除することにしましたが、運がありません（クライアントとサーバーの両方でこれを実行しました）：

$ 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

実際に接続しようとしていることを確認することにしたので、wiresharkを開いてこれを確認しました。

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)

それをブロックするファイアウォールルールがないことがわかっているので、openvpnが偶数で実行されているかどうかを確認しました。

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

何も戻ってこない。 systemdをチェックして、クラッシュしていないことを確認します。

$ 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

成功したと書いてありますが、「ExecStart =/bin/true」に気づきました。一体何ですか？サービスファイルを開くと、これが表示されます。

$ 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

認めます、openvpnは私が完全には理解していない複雑なソフトウェアですが、ExecStart=/bin/true正しいですか？これは、私が今までに見つけたよりもはるかに賢い人がいるため、これが何らかの形で本番環境に入れられた単なるプレースホルダーであるとは信じがたいのですが、理解できません。これのポイントは何ですか？openvpnにハンドシェイクの実行を待機させるにはどうすればよいですか？

debianopenvpnsystemd
3
Thomas

認めます、openvpnは私が完全に理解していない複雑なソフトウェアですが、ExecStart =/bin/trueはどのように正しいのですか？

これは実際にはOpenVPNの機能ではなく、systemdの機能です。 systemdを使用するほとんどのシステムでは、OpenVPNにはテンプレートユニットとジェネレーターが付属しています。これにより、システムは複数のOpenVPNインスタンスをサポートし、systemdが各VPNを個別に監視および制御できるようになります

Debianシステムでは、見たいテンプレートユニットはここにあります。 /lib/systemd/system/[email protected]、そしてジェネレーターがここにあります/lib/systemd/system-generators/openvpn-generator。

そのテンプレートユニットには、このようなExecStartがあります。

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

たとえば、私のシステムでは、いくつかのVPN構成を実行しています

# 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

systemctl status [email protected]のようなコマンドを使用して、個々のopenvpnインスタンスをクエリできます。

この設定を追加したばかりの場合、systemdが新しいユニットを認識するためにsystemctl daemon-reloadを使用する必要がある場合があります。

構成の名前が文字通り「server.conf」であり、難読化されていない場合は、systemctl status [email protected]を使用します。

問題のトラブルシューティングについては、openvpnが実行されていて、ソケットが開いているかどうかを確認することをお勧めしますlsof -ni | grep openvpn。次に、OpenVPNがシステムログgrep openvpn /var/log/syslog | tail -50にエラーなどを報告したことも確認します。これら2つのうちの1つは、何が起こっているかについてのヒントを与えるはずです。

6
Zoredache