Переподключение OpenVPN слиента после перезапуска OpenVPN сервера.

[rits]

Есть такая проблема: 9 точек висят на альтовских p9 (sysv-server) шлюзах, один на suse и один сервер к которому все подключаются на ubuntu.
После остановки сервера openvpn на ubuntu автоматом поднимается только suse точки, а на альтах висят и ждут ручной команды (service openvpn restart). Если пропадает только интернет, то точки после возврата связи, соединяются нормально.

Теперь подробно:
Конфиг сервера мне неизвестен, конфиг клиентов alt и suse одинаков.

Код: [Выделить]

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
Режим запуска на:
# 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 openvpn  --persist-tun --persist-key --chroot /var/lib/openvpn

Я предполагаю, что проблема в ключах --persist-tun --persist-key

Кто что думает и как убрать эти ключи из запуска по умолчанию, чтобы они брались из конфига, а не в темную добавлялись?

для справки:

persist-tun — данная опция оставляет без изменения устройства tun/tap при перезапуске OpenVPN.
persist-key — указывает не перечитавать файлы ключей при перезапуске туннеля.

https://bugzilla.altlinux.org/show_bug.cgi?id=40242

[rits]

нашел
# cat /etc/rc.d/init.d/openvpn

...
start_daemon    --pidfile "$PIDFILEBASE-$CHANNEL.pid" \
                                --lockfile "$LOCKFILEBASE-$CHANNEL" -- \
                                $OPENVPNBIN --config "$CONFFILE"  \
                                --daemon --writepid "$PIDFILEBASE-$CHANNEL.pid" \
                                --user "$OPENVPNUSER" --group "$OPENVPNGROUP" \
                                --persist-tun --persist-key \
                                $RUN_CHROOT
...

Может убрать это недоразумение  из стартовых скриптов?
В этом дело или нет проверю позже.
Аналог проблемы https://www.linux.org.ru/forum/general/13688310

[rits]

Еще вопрос:
при старте openvpn из профиля /etc/net/ifaces/tun... командой ifup tun...,
откуда подцепляются параметры по умолчанию?
# ps aux | grep vpn

/usr/sbin/openvpn --dev tun1 --daemon --config /etc/net/ifaces/tun1/ovpnoptions --user openvpn --persist-tun --persist-key --group openvpn --cd /var/lib/openvpn/cache --chroot /var/lib/openvpn --tmp-dir /tmp --writepid /var/run/openvpn-iface-tun1.pid --up /etc/net/scripts/openvpn.action

[rits]

нашел
# tail -n 7 /etc/net/scripts/create-ovpn

$OVPN --dev $NAME --daemon \
   ${PROF_CONFFILE:+ --config $PROF_CONFFILE} $KEY_ARGS $TLSAUTH_ARGS \
   ${OVPN_USER:+ --user $OVPN_USER --persist-tun --persist-key} \
   ${OVPN_GROUP:+ --group $OVPN_GROUP} \
   --cd $OVPNCHROOTDIR/cache --chroot $OVPNCHROOTDIR --tmp-dir /tmp \
   --writepid $OVPNRUNDIR/openvpn-iface-$NAME.pid \
   --up $SCRIPTDIR/openvpn.action

Думаю, это "недоразумение"  --persist-tun --persist-key, вводящее в блуд пользователя, тоже не должно прибиваться гвоздями, а только опционально.

[rits]

Если убрать из стартовых скриптов клиента параметры --persist-tun ...-key, то ребут сервера openvpn, вообще приводит к падению tun интерфейса на клиенте openvpn. Значит возможно я не прав с правкой стартовых скриптов, но что вызывает
неработоспособность канала? Буду изучать дальше проблемку.

https://bugzilla.altlinux.org/show_bug.cgi?id=40242#c8

Nikolay A. Fetisov 2021-06-21 13:21:57 MSK
(Ответ для rabochyITs на комментарий #8)

Да, т.к. без --persist-tun при закрытии соединения будет удалено устройство
tun, а создать новое после понижения привилегий до пользователя клиент
OpenVPN уже не сможет.

Есть подозрение, что клиент не определяет момент закрытия TCP-соединения
с сервером. Отсюда соединение не перезапускается, т.к. клиент думает,
что всё в порядке.

https://bugzilla.altlinux.org/show_bug.cgi?id=40242#c10

[rits]

Решение для клиента vpn по отслеживанию за падением vpn канала.

- создать каталог и скрипт-файл, заполнить и сделать скрипт исполняемым
# mkdir -p /var/adm/crons && touch /var/adm/crons/restart_vpn && chmod +x /var/adm/crons/restart_vpn

- добавить скрипт
# nano -b /var/adm/crons/restart_vpn

Код: [Выделить]

#!/bin/bash
### При отсутствии ответа с хоста через VPN
### перезапустить VPN

# Interfaces TUN
# для управления с помощью etcnet
# ifdown $TUN; sleep 5; ifup $TUN
TUN=tun1

#=# Удаленный адрес для проверки на доступность
srcinet=77.88.8.8
srcvpn=192.168.0.1

# Пинг тест
ping -c 2 $srcinet -W1 &>/dev/null; pinginet=$?
ping -c 2 $srcvpn -W1 &>/dev/null; pingvpn=$?

# Отладочная информация
echo "pinginet  = $pinginet"
echo "pingvpn   = $pingvpn"

# Интернет есть и пинг основного vpn хоста отсутствует
if [[ $pingvpn != 0 ]] && [[ $pinginet = 0 ]]; then
    echo "Restart VPN ..."
# останавливаем сервер и закрывает все tun, запускаем  vpn (/etc/openvpn/client.conf),
# запускаем vpn через etcnet (/etc/net/ifaces/tun...)
    /etc/rc.d/init.d/openvpn stop
    sleep 5
    /etc/rc.d/init.d/openvpn start
    sleep 5
    ifup $TUN
# каталог сохранения логов
logdir="/var/log/"
echo -e "Result_vpn" >> $logdir/restart_vpn
echo -e "pinginet  = $pinginet" >> $logdir/restart_vpn
echo -e "pingvpn   = $pingvpn " >> $logdir/restart_vpn
echo -e "Restart VPN TUN ... `date +%Y-%m-%d_%H-%M-%S`" >> $logdir/restart_vpn
fi

- добавить задание в планировщик
- на время сессии (nano,mcedit) export EDITOR=nano; crontab -e

Код: [Выделить]

#minute (0-59),
#| hour (0-23),
#| | day of the month (1-31),
#| | | month of the year (1-12),
#| | | | day of the week (0-6 with 0=Sunday).
#| | | | | commands
*/3       *       *       *       *       /bin/bash /var/adm/crons/restart_vpn
# перевод строки
как бы работает, но нужно еще погонять в рабочем режиме