Есть такая проблема: 9 точек висят на альтовских p9 (sysv-server) шлюзах, один на suse и один сервер к которому все подключаются на ubuntu. После остановки сервера openvpn на ubuntu автоматом поднимается только suse точки, а на альтах висят и ждут ручной команды (service openvpn restart). Если пропадает только интернет, то точки после возврата связи, соединяются нормально. https://forum.altlinux.org/index.php?topic=45075.new#new Я предполагаю, что проблема в ключах --persist-tun --persist-key Режим запуска на: # ps aux | grep vpn suse /usr/sbin/openvpn --daemon --writepid /var/run/openvpn/server.pid --config /etc/openvpn/server.conf --cd /etc/openvpn alt /usr/sbin/openvpn --config /etc/openvpn/client.conf --daemon --writepid /var/run/openvpn-client.pid --user openvpn --group openvp --persist-tun --persist-key --chroot /var/lib/openvpn Предлагаю убрать ключи persist-tun, persist-key из стартовых скриптов в файлах /etc/rc.d/init.d/openvpn и /etc/net/scripts/create-ovpn, так как они должны назначаться опционально. Аналог проблемы https://www.linux.org.ru/forum/general/13688310
В ALT openvpn запускается по-умолчанию в chroot и под непривилегированным пользователем. Соответсвенно, при запуске клиент: - читает конфигурацию; - создаёт устройство tun/tap; - читает закрытый ключ; - понижает привилегии, уходит в chroot; - поднимает канал на ранее созданном устройстве и с ранее прочитанным ключом. При необходимости перезапустить соединение клиент использует ранее созданное устройство (--persist-tun) и ранее считанный ключ (--persist-key) - т.к. ни создать новое устройство, ни перечитать ключ он уже не может. Это то, что относится к запуску OpenVPN через init-скрипт. Для варианта конфигурации соединения через etcnet ситуация такая же (но, судя по приведённой строке, используется именно init-скрипт). Т.е. - нет, согласно приведённой строке запуска клиента, и -persist-tun, и --persist-key необходимы - т.к. используется --user и --chroot. Несколько смущает значение --group - но, скорее, это опечатка в тексте, а не в конфигурации. В остальном - надо смотреть на конфигурации сервера и клиентов. keepalive на сервере точно установлен? Чисто наугад - в строке для _клиента_ Suse указано использование конфигурации 'server.conf'. В серверной конфигурации keepalive должен быть. Если конфигурация для Suse переделана из серверной - то там keepalive может и быть. В типовой клиентской конфигурации, наоборот, keepalive нет - т.к. эти настройки передаются клиенту с сервера. И, если на сервере Ubuntu в конфигурации сервера keepalive _нет_, то получится ровно описанная ситуация - клиент Suse обнаружит недоступность сервера и перезапустит канал, клиенты на ALT проверять недоступность сервера не будут. Точнее надо смотреть конфигурации и логи.
Клиентский конфиг client dev tun proto tcp remote 111.111.111.111 resolv-retry infinite keepalive 10 60 nobind user openvpn group openvpn ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/server.crt key /etc/openvpn/keys/server.key status /var/log/ovpngp-status log /var/log/ovpngp.log verb 3 Пришлось делать service restart openvpn Дали конфиг сервера рабочего port 1194 proto tcp dev tun ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/server.crt key /etc/openvpn/keys/server.key dh /etc/openvpn/keys/dh1024.pem server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt client-to-client keepalive 10 120 persist-key persist-tun status openvpn-status.log log openvpn.log log-append openvpn.log verb 3 push "route ..." ... client-config-dir /etc/openvpn/ccd route ... ... Что может быть не так? конфиг клиента suse указан вначале поста
Конфиг с клиента openvpn на Suse 11.3 client dev tun proto tcp remote 111.111.111.111 1194 resolv-retry infinite ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/server.crt key /etc/openvpn/keys/server.key status /var/log/ovpn-status.log log /var/log/ovpn.log verb 3 Несовсем понятно, чем альтовский vpn "хуже" раз после перезапуска сервера не может поднять соединение?
(Ответ для rabochyITs на комментарий #2) > Клиентский конфиг > client > dev tun > proto tcp В случае использования TCP при остановке сервера соединие клиента с ним закрывается - т.е. клиент узнаёт о недоступности сервера сразу. Через connect-retry секунд (по-умолчанию 5) клиент должен начинать пробовать восстановить соединение, выполняя connect-retry-max (unlimited) попыток. Архитектура сети для клиентов ALT и Suse одинаковая? > keepalive 10 60 Это в конфигурации клиента лишнее, клиент получает параметры ping/ping-restart с сервера. Плюс, для туннеля через TCP проерять доступность сервера через ping не требуется, соединение TCP должно при этом разрываться само. > Что может быть не так? конфиг клиента suse указан вначале поста Надо смотреть логи. В нормальной ситуации на стороне клиента должно быть что-то такое: июн 18 15:22:22 : Connection reset, restarting [0] июн 18 15:22:22 : SIGUSR1[soft,connection-reset] received, process restarting июн 18 15:22:22 : Restart pause, 5 second(s) Это был остановлен сервер, и разорвалось соединение. июн 18 15:22:27 : TCP/UDP: Preserving recently used remote address: [AF_INET]11.22.33.44:1194 июн 18 15:22:27 : Socket Buffers: R=[131072->131072] S=[16384->16384] июн 18 15:22:27 : Attempting to establish TCP connection with [AF_INET]11.22.33.44:1194 [nonblock] июн 18 15:22:28 : TCP: connect to [AF_INET]11.22.33.44:1194 failed: Connection refused июн 18 15:22:28 : SIGUSR1[connection failed(soft),init_instance] received, process restarting июн 18 15:22:28 : Restart pause, 5 second(s) Это первая попытка перезапуска. июн 18 15:22:33 : TCP/UDP: Preserving recently used remote address: [AF_INET]11.22.33.44:1194 июн 18 15:22:33 : Socket Buffers: R=[131072->131072] S=[16384->16384] июн 18 15:22:33 : Attempting to establish TCP connection with [AF_INET]11.22.33.44:1194 [nonblock] июн 18 15:22:34 : TCP: connect to [AF_INET]11.22.33.44:1194 failed: Connection refused июн 18 15:22:34 : SIGUSR1[connection failed(soft),init_instance] received, process restarting июн 18 15:22:34 : Restart pause, 5 second(s) Это вторая попытка перезапуска. И ещё через несколько попыток, после включения сервера - восстановление соединения: июн 18 15:22:51 : TCP/UDP: Preserving recently used remote address: [AF_INET]11.22.33.44:1194 июн 18 15:22:51 : Socket Buffers: R=[131072->131072] S=[16384->16384] июн 18 15:22:51 : Attempting to establish TCP connection with [AF_INET]11.22.33.44:1194 [nonblock] июн 18 15:22:52 : TCP connection established with [AF_INET]11.22.33.44:1194 июн 18 15:22:52 : TCP_CLIENT link local: (not bound) июн 18 15:22:52 : TCP_CLIENT link remote: [AF_INET]11.22.33.44:1194 июн 18 15:22:52 : TLS: Initial packet from [AF_INET]11.22.33.44:1194, sid=cf918eab 03be18c9 июн 18 15:22:52 : VERIFY OK: depth=1, C=RU, ... июн 18 15:22:52 : VERIFY OK: depth=0, C=RU, ... июн 18 15:22:52 : Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA июн 18 15:22:52 : [openvpn.server.tld] Peer Connection Initiated with [AF_INET]11.22.33.44:1194 июн 18 15:22:53 : SENT CONTROL [openvpn.openvpn.server]: 'PUSH_REQUEST' (status=1) июн 18 15:22:53 : PUSH: Received control message: 'PUSH_REPLY,route 172.16.1.1,topology net30,ping 10,ping-restart 120,ifconfig 172.16.1.4 172.16.1.5,peer-id 0,cipher AES-256-GCM' июн 18 15:22:53 : OPTIONS IMPORT: timers and/or timeouts modified июн 18 15:22:53 : OPTIONS IMPORT: --ifconfig/up options modified июн 18 15:22:53 : OPTIONS IMPORT: route options modified июн 18 15:22:53 : OPTIONS IMPORT: peer-id set июн 18 15:22:53 : OPTIONS IMPORT: adjusting link_mtu to 1627 июн 18 15:22:53 : OPTIONS IMPORT: data channel crypto options modified июн 18 15:22:53 : Data Channel: using negotiated cipher 'AES-256-GCM' июн 18 15:22:53 : Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key июн 18 15:22:53 : Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key июн 18 15:22:53 : Preserving previous TUN/TAP instance: tun0 июн 18 15:22:53 : Initialization Sequence Completed Имеет смысл смотреть, почему именно клиент не хочет восстановить соединение, и сравнивать картинку с тем, что видно на стороне клиента Suse.
После рестарта клиента с client dev tun proto tcp-client remote 111.111.111.111 1194 resolv-retry infinite ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/sklad.crt key /etc/openvpn/keys/sklad.key status /var/log/ovpngp-status.log log-append /var/log/ovpngp_app.log verb 3 и сохранением стандартных параметров запуска (persist-tun persist-key) в лог пишутся такие ошибки: ... event_wait : Interrupted system call (code=4) /usr/bin/ip route del 192.168.0.0/24 ERROR: Linux route delete command failed: could not execute external program ... https://openvpn.net/community-resources/how-to/ (автоперевод google): Непривилегированный режим (только Linux) В Linux OpenVPN можно запускать совершенно непривилегированно. Эта конфигурация немного сложнее, но обеспечивает лучшую безопасность. Для работы с этой конфигурацией OpenVPN должен быть настроен для использования интерфейса iproute, это делается путем указания --enable-iproute2 для настройки скрипта. Пакет sudo также должен быть доступен в вашей системе. Эта конфигурация использует возможность Linux изменять разрешение устройства tun, чтобы непривилегированный пользователь мог получить к нему доступ. Он также использует sudo для выполнения iproute, чтобы можно было изменить свойства интерфейса и таблицу маршрутизации. Все ли в порядке с чрутами? Могут ли они вызвать "зависание" клиента openvpn на стартеркитах серверов p9 при перезапуске сервера openvpn на другом дистрибутиве? Вот еще попутные ошибки: OpenVPN 2.4.9 x86_64-alt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Nov 17 2020 ... WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. ... NOTE: chroot will be delayed because of --client, --pull, or --up-delay NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay ... GID set to openvpn UID set to openvpn WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Initialization Sequence Completed
(Ответ для rabochyITs на комментарий #5) > После рестарта клиента с .... > сохранением стандартных параметров запуска (persist-tun persist-key) в > лог пишутся такие ошибки: > ... > event_wait : Interrupted system call (code=4) > /usr/bin/ip route del 192.168.0.0/24 > ERROR: Linux route delete command failed: could not execute external program Это при перезапуске клиентом соединения? Откуда берётся этот маршрут, и, _случайно_, с сервера не приходит маршрут на дублирующую локально существующую сеть? И, ещё раз: при перезапуске сервера должно сразу закрываться соединение TCP. В логах при этом будут строки вида Connection reset, restarting [0] SIGUSR1[soft,connection-reset] received, process restarting Restart pause, 5 second(s) Это есть? Клиент точно видит, что сервер перезапустился? С клиентом на Suse сравнивали? > ... > Все ли в порядке с чрутами? Могут ли они вызвать "зависание" клиента openvpn > на стартеркитах серверов p9 при перезапуске сервера openvpn на другом > дистрибутиве? Да, это рабочая конфигурация и проблем вызывать не должна. > > Вот еще попутные ошибки: Здесь нет ошибок. Это диагностические сообщения. > ... > WARNING: No server certificate verification method has been enabled. See > http://openvpn.net/howto.html#mitm for more info. Это следствие 'dh <path>' на сервере, и отсутствия этого ключа на клиенте. > ... > NOTE: chroot will be delayed because of --client, --pull, or --up-delay > NOTE: UID/GID downgrade will be delayed because of --client, --pull, or > --up-delay Да, как и говорилось ранее - при наличии chroot/работе OpenVPN от пользователя сначала идёт инициализация соединения, потом выполняется chroot и понижение привилегий. О чём и говорится. > ... > GID set to openvpn > UID set to openvpn > WARNING: this configuration may cache passwords in memory -- use the > auth-nocache option to prevent this > Initialization Sequence Completed А это, соответственно, завершение настройки соединения и понижение привилегий. И, если на ключ задан пароль - да, этот пароль будет кешироваться в памяти клиента.
> Это при перезапуске клиентом соединения? Да, при перезапуске клиентом, рабочий сервер не так просто перезапустить, когда как минимум 9 точек висит под нагрузкой, проверю отпишусь. > Это есть? Клиент точно видит, что сервер перезапустился? С клиентом на Suse сравнивали? Жду момента, пока настроил тестовых на log-append ... > Откуда берётся этот маршрут, и, _случайно_, с сервера не приходит маршрут на дублирующую локально существующую сеть? Условно говоря, 9 клиентов получают одинаковую конфигурацию роутинга /usr/bin/ip route add 192.168.0.0/24 via ... /usr/bin/ip route add 192.168.1.0/24 via ... ... /usr/bin/ip route add 192.168.0.9/24 via ... Все эти клиенты находятся в этих подсетях, каждый получает по одному дублю команды с сервера openvpn - push "route add своя подсеть via ..." но маршрутизация одной из девяти команд остается неизменной и полученной из локальных настроек (192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1) Клиенты локалных сетей друг друга видят (client-to-client).
> И, ещё раз: при перезапуске сервера должно сразу закрываться соединение TCP. > В логах при этом будут строки вида > Connection reset, restarting [0] > SIGUSR1[soft,connection-reset] received, process restarting > Restart pause, 5 second(s) Легко заставил работать в таком режиме (при перезапуске сервера vpn) клиента vpn. При проверке использовал server_openvpn alt etcnet - client_openvpn alt etcnet. Если убрать из стартовых скриптов клиента параметры --persist-tun ...-key, то ребут сервера openvpn, вообще приводит к падению tun интерфейса на клиенте openvpn. Значит возможно я не прав с правкой стартовых скриптов, но что вызывает неработоспособность канала? Буду изучать дальше проблемку.
(Ответ для rabochyITs на комментарий #7) > > Это при перезапуске клиентом соединения? > > Да, при перезапуске клиентом, ... Т.е. при service openvpn restart? Тогда сообщение о невозможности удалить маршрут - это нормально, извнутри chroot он отдельно не удалится, но при удалении интрефейса tun уйдёт вместе с ним.
(Ответ для rabochyITs на комментарий #8) > ... > Легко заставил работать в таком режиме (при перезапуске сервера vpn) клиента > vpn. При проверке использовал server_openvpn alt etcnet - client_openvpn > alt etcnet. > Если убрать из стартовых скриптов клиента параметры --persist-tun ...-key, > то ребут сервера openvpn, вообще приводит к падению tun интерфейса на > клиенте openvpn. Да, т.к. без --persist-tun при закрытии соединения будет удалено устройство tun, а создать новое после понижения привилегий до пользователя клиент OpenVPN уже не сможет. > Буду изучать дальше проблемку. Есть подозрение, что клиент не определяет момент закрытия TCP-соединения с сервером. Отсюда соединение не перезапускается, т.к. клиент думает, что всё в порядке.
