Меня это очень смущает, и это кажется совершенно неправильным, но я не знаю, как это сделать, поэтому начну с самого начала.
Я настроил openvpn на своем сервере Debian, используя этот руководство. После того, как я скопировал необходимые файлы на рабочий стол 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
Я решил убедиться, что действительно пытаюсь установить соединение, поэтому открыл wirehark и увидел следующее:
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)
Поскольку я знаю, что это правило не блокирует брандмауэр, я пошел посмотреть, работает ли открытый vpn:
$ 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 ждать, чтобы выполнить рукопожатие?
Я признаю, что openvpn - это сложная программа, которую я не совсем понимаю, но как правильно ExecStart = / bin / true?
На самом деле это не функция OpenVPN, а функция systemd. В большинстве систем с systemd OpenVPN будет поставляться с модулем шаблонов и генератором. Это позволяет вашей системе поддерживать несколько экземпляров OpenVPN, а systemd может отслеживать и контролировать каждую VPN отдельно.
В системах Debian модуль шаблона, на который вы хотели бы взглянуть, находится здесь. /lib/systemd/system/openvpn@.service
, а генератор здесь /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
openvpn@zoredachesrv.service loaded active running OpenVPN connection to zoredachesrv
openvpn@p2p-to-valiant.service loaded active running OpenVPN connection to p2p-to-valiant
Вы можете запросить отдельные экземпляры openvpn с помощью такой команды, как systemctl status openvpn@zoredachesrv.service
.
Если вы только что добавили эту конфигурацию, возможно, вам придется использовать systemctl daemon-reload
чтобы systemd распознал новые блоки.
Если ваша конфигурация буквально названа server.conf и не запутана, вы должны использовать systemctl status openvpn@server.service
Что касается устранения вашей проблемы, я предлагаю вам проверить, работает ли openvpn и есть ли открытый сокет. lsof -ni | grep openvpn
. Затем также проверьте, что OpenVPN сообщает об ошибках или что-либо в вашем системном журнале. grep openvpn /var/log/syslog | tail -50
. Одна из этих двух вещей должна дать вам представление о том, что происходит.
Вот, нетномада может указать решение: https://www.cyberciti.biz/open-source/tip-how-to-use-when-openvpn-systemd-based-server-start-to-refuse-on-boot/