LINUX.ORG.RU
Форум — Admin  

Теряется маршрут к OVPN-серверу после разрыва интернет-подключения

 , ,


0

1

По характеру работы приходится часто подключаться к разным сетям, и в таком режиме оказалось совершенно невозможно работать через OpenVPN, через который пропускается весь интернет-трафик.

Проблема в том, что после даже кратковременного разрыва интернет-подключения доступ в интернет (а также и к OVPN-серверу) исчезает, и не восстанавливается, пока OVPN-подключение не будет разорвано.

1. До подключения к OpenVPN 

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    100    0        0 enp0s25
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 enp0s25
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 enp0s25

2. После подключения к OpenVPN 

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.5        128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.0.1     0.0.0.0         UG    100    0        0 enp0s25
10.8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun0
10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
128.0.0.0       10.8.0.5        128.0.0.0       UG    0      0        0 tun0
10.20.30.40     192.168.0.1     255.255.255.255 UGH   0      0        0 enp0s25
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 enp0s25
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 enp0s25

3. После переподключения к интернету 

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.5        128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.0.1     0.0.0.0         UG    100    0        0 enp0s25
10.8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun0
10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
128.0.0.0       10.8.0.5        128.0.0.0       UG    0      0        0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 enp0s25
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 enp0s25

— исчез маршрут к OpenVPN-серверу 

10.20.30.40     192.168.0.1     255.255.255.255 UGH   0      0        0 enp0s25

Лог клиента после восстановления доступа в интернет выглядит вот так: 

Sat Oct 30 00:13:28 2021 us=753080 Recursive routing detected, drop tun packet to [AF_INET]10.20.30.40:443
Sat Oct 30 00:13:28 2021 us=753105 Recursive routing detected, drop tun packet to [AF_INET]10.20.30.40:443
Sat Oct 30 00:13:28 2021 us=753128 Recursive routing detected, drop tun packet to [AF_INET]10.20.30.40:443

Лог сервера после исчезновения маршрута у клиента, очевидно, никак не меняется.

Конфигурация клиента: 

client
dev tun
proto udp
remote 10.20.30.40 443
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
remote-cert-tls server
cipher AES-256-GCM
auth SHA256
key-direction 1
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
verb 4
<ca>
…
</ca>
<cert>
…
</cert>
<key>
…
</key>
<tls-crypt>
…
</tls-crypt>

Конфигурация сервера: 

port 443
proto udp
dev tun
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/server.crt
key /etc/openvpn/server/server.key
dh none
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
keepalive 10 120
tls-crypt /etc/openvpn/server/ta.key
auth SHA256
cipher AES-256-GCM
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3
explicit-exit-notify 1

Клиент — Ubuntu 20 (воспроизводится на чистой системе), сервер — Oracle Linux 8. Клиенты на Android с этим же сервером через официальный клиент OpenVPN работают без проблем.

P.S. Отличным решением могло бы быть использование OpenVPN через GUI, но, увы, NetworkManager игнорирует route net_gateway.


# cat /etc/NetworkManager/dispatcher.d/route.sh

#!/bin/bash

IFDEV="wlp3s0"
#IFDEV="enp14s0u1"

if [[ "$1" == "$IFDEV" ]] && [[ "$2" == "up" ]];
then
    ip route add 1.2.3.4/32 via "$IP4_GATEWAY" dev "$1"
fi
ValdikSS ★★★★★
()
Ответ на: комментарий от ValdikSS

Может лучше в скрипте проверять, не запущен ли openvpn-клиент, и если запущен, то при up-интерфейса, перезапускать openvpn-клиент? А то получается, что при правке remote в конфиге openvpn, нужно и в route.sh не забыть поправить.

mky ★★★★★
()
Ответ на: комментарий от anc

redirect-gateway

И что?

Исчезает крайне полезный маршрут. 

10.20.30.40     192.168.0.1     255.255.255.255 UGH   0      0        0 enp0s25

IMHO есть смысл явно указать клиенту, что нужно добавить маршрут до сервера. Пологаться на «искусственный интелект» клиента openvpn нельзя.

Хорошо бы посмотреть более подробные логи при переподключении.

Почему удаляется маршрут до remote_host ?

Почему не появляется маршрут до remote_host?

Интересный пост OpenVPN recursive routing

vel ★★★★★
()
Ответ на: комментарий от vel

Почему в конфиге сервера не используется push «route remote_host 255.255.255.255 net_gateway» ?

redirect-gateway

И что?

То что он, в том числе, делает «route remote_host 255.255.255.255 net_gateway»

Почему удаляется маршрут до remote_host ?

Видимо вот по этому «приходится часто подключаться к разным сетям»

Почему не появляется маршрут до remote_host?

Видимо потому что не рестартили ovpn.

anc ★★★★★
()
Ответ на: комментарий от vel

Ну в общем решений два (а по сути одно) - заправлять маршрут на openvpn через хуки NetworkManager как посоветовали тут Теряется маршрут к OVPN-серверу после разрыва интернет-подключения (комментарий) или в настройках соединения доопределять дополнительный маршрут.

Nastishka ★★★★★
()
Ответ на: комментарий от anc

Пробовал и так и так. Сколько бы времени не прошло после подключения — маршруты не меняются.

vkapas
() автор топика
Ответ на: комментарий от ValdikSS

Спасибо! Решение рабочее.

Не получилось только сделать, что скрипт срабатывал на оба интерфейса, и Wi-Fi и Ethernet, не хватает опыта. Если просто записать их как 

IFDEV="wlp3s0"
IFDEV="enp0s25"
то применяется только к последнему в списке.

vkapas
() автор топика
Ответ на: комментарий от Nastishka

Сложность в том, что подключение идёт и через Ehternet и через Wi-Fi, причём сети разные, в каждой прописывать замучаешься.

А кроме того ещё есть дополнительные маршруты, которые отдаются со стороны OpenVPN-сервера.

vkapas
() автор топика
Ответ на: комментарий от vkapas 
#!/bin/bash

IFDEV1="wlp3s0"
IFDEV2="enp0s25"
ROUTEIP="1.2.3.4/32"

if [[ "$1" == "$IFDEV1" ]] || [[ "$1" == "$IFDEV2" ]]; then
    if [[ "$2" == "up" ]]; then
        ip route add "$ROUTEIP" via "$IP4_GATEWAY" dev "$1"
    fi
fi
ValdikSS ★★★★★
()
Ответ на: комментарий от mky

Спасибо, интересная идея.

И, да, действительно, OpenVPN-сервер раздаёт ещё кое-какие маршруты, и править их и там и здесь не хотелось бы. В итоге создал для openvpn-подключения сервис systemd, а в скрипт ValdikSS добавил его перезапуск при поднятии интерфейса (вместо добавления маршрута). Осталось только понять, как прописать условие на оба интерфейса.

vkapas
() автор топика
Ответ на: комментарий от ValdikSS

То, что нужно, ещё раз спасибо за помощь.

vkapas
() автор топика
Ответ на: комментарий от vel

Настраивал по инструкции DO, где этого не было, да и сам никогда раньше такое в конфиг не добавлял. В интернетах пишут, что в такой конструкции нет необходимости при наличии push "redirect-gateway def1".

На всякий случай проверил — с push "route 10.20.30.40 255.255.255.255 net_gateway" маршрут также не восстанавливается.

vkapas
() автор топика
Ответ на: комментарий от vel

Спасибо за ссылку. Вспомнил даже, что как и автор того поста тоже как-то ставил на этой системе dhcp-сервер для разовой задачи, но проблема, увы, воспроизводится даже на чистой Ubuntu 20.04.

/var/log/syslog выглядит так (в 02:14:00 подключение к OpenVPN, через 10 секунд дисконнект интерфейса, ещё через 15 подключение интерфейса, в 02:17:00 дисконнект OpenVPN. Здесь лог не поместился, целиком я выложил его сюда):

Nov  3 02:14:11 thinkpad kernel: [  979.844750] e1000e: enp0s25 NIC Link is Down
Nov  3 02:14:12 thinkpad systemd[1]: NetworkManager-dispatcher.service: Succeeded.
Nov  3 02:14:17 thinkpad NetworkManager[1228]: <info>  [1635894857.9393] device (enp0s25): state change: activated -> unavailable (reason 'carrier-changed', sys-iface-state: 'managed')
Nov  3 02:14:17 thinkpad NetworkManager[1228]: <info>  [1635894857.9602] dhcp4 (enp0s25): canceled DHCP transaction
Nov  3 02:14:17 thinkpad NetworkManager[1228]: <info>  [1635894857.9602] dhcp4 (enp0s25): state changed bound -> done
Nov  3 02:14:17 thinkpad avahi-daemon[1221]: Withdrawing address record for 192.168.0.15 on enp0s25.
Nov  3 02:14:17 thinkpad avahi-daemon[1221]: Leaving mDNS multicast group on interface enp0s25.IPv4 with address 192.168.0.15.
Nov  3 02:14:17 thinkpad avahi-daemon[1221]: Interface enp0s25.IPv4 no longer relevant for mDNS.
Nov  3 02:14:17 thinkpad avahi-daemon[1221]: Withdrawing address record for fe80::4525:XXXX:YYYY:ZZZZ on enp0s25.
Nov  3 02:14:17 thinkpad avahi-daemon[1221]: Leaving mDNS multicast group on interface enp0s25.IPv6 with address fe80::4525:XXXX:YYYY:ZZZZ.
Nov  3 02:14:17 thinkpad avahi-daemon[1221]: Interface enp0s25.IPv6 no longer relevant for mDNS.
Nov  3 02:14:17 thinkpad charon: 11[KNL] 192.168.0.15 disappeared from enp0s25
Nov  3 02:14:17 thinkpad charon: 10[KNL] fe80::4525:XXXX:YYYY:ZZZZ disappeared from enp0s25
Nov  3 02:14:17 thinkpad dbus-daemon[1227]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.11' (uid=0 pid=1228 comm="/usr/sbin/NetworkManager --no-daemon " label="unconfined")
Nov  3 02:14:18 thinkpad systemd[1]: Starting Network Manager Script Dispatcher Service...
Nov  3 02:14:18 thinkpad dbus-daemon[1227]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Nov  3 02:14:18 thinkpad systemd[1]: Started Network Manager Script Dispatcher Service.
Nov  3 02:14:25 thinkpad systemd-resolved[983]: Using degraded feature set (UDP) for DNS server 208.67.220.220.
Nov  3 02:14:27 thinkpad systemd-resolved[983]: Using degraded feature set (UDP) for DNS server 208.67.222.222.
Nov  3 02:14:28 thinkpad systemd[1]: NetworkManager-dispatcher.service: Succeeded.
Nov  3 02:14:28 thinkpad kernel: [  996.561729] e1000e: enp0s25 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3316] device (enp0s25): carrier: link connected
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3329] device (enp0s25): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed')
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3383] policy: auto-activating connection 'Wired connection 1' (318986dc-1894-3084-a32b-09e1545bf56b)
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3399] device (enp0s25): Activation: starting connection 'Wired connection 1' (318986dc-1894-3084-a32b-09e1545bf56b)
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3404] device (enp0s25): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3409] manager: NetworkManager state is now CONNECTING
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3412] device (enp0s25): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3420] device (enp0s25): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3424] dhcp4 (enp0s25): activation: beginning transaction (timeout in 45 seconds)
Nov  3 02:14:33 thinkpad charon: 10[KNL] fe80::4525:XXXX:YYYY:ZZZZ appeared on enp0s25
Nov  3 02:14:33 thinkpad avahi-daemon[1221]: Joining mDNS multicast group on interface enp0s25.IPv6 with address fe80::4525:XXXX:YYYY:ZZZZ.
Nov  3 02:14:33 thinkpad avahi-daemon[1221]: New relevant interface enp0s25.IPv6 for mDNS.
Nov  3 02:14:33 thinkpad avahi-daemon[1221]: Registering new address record for fe80::4525:XXXX:YYYY:ZZZZ on enp0s25.*.
Nov  3 02:14:33 thinkpad deja-dup-monito[8769]: Source ID 598 was not found when attempting to remove it
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3608] dhcp4 (enp0s25): option dhcp_lease_time      => '600'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3609] dhcp4 (enp0s25): option domain_name_servers  => '8.8.8.8 8.8.4.4'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3609] dhcp4 (enp0s25): option expiry               => '1635895473'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3609] dhcp4 (enp0s25): option ip_address           => '192.168.0.15'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3609] dhcp4 (enp0s25): option next_server          => '192.168.0.1'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3609] dhcp4 (enp0s25): option requested_broadcast_address => '1'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3609] dhcp4 (enp0s25): option requested_domain_name => '1'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3609] dhcp4 (enp0s25): option requested_domain_name_servers => '1'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3610] dhcp4 (enp0s25): option requested_domain_search => '1'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3610] dhcp4 (enp0s25): option requested_host_name  => '1'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3610] dhcp4 (enp0s25): option requested_interface_mtu => '1'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3610] dhcp4 (enp0s25): option requested_ms_classless_static_routes => '1'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3610] dhcp4 (enp0s25): option requested_nis_domain => '1'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3610] dhcp4 (enp0s25): option requested_nis_servers => '1'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3610] dhcp4 (enp0s25): option requested_ntp_servers => '1'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3610] dhcp4 (enp0s25): option requested_rfc3442_classless_static_routes => '1'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3610] dhcp4 (enp0s25): option requested_root_path  => '1'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3611] dhcp4 (enp0s25): option requested_routers    => '1'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3611] dhcp4 (enp0s25): option requested_static_routes => '1'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3611] dhcp4 (enp0s25): option requested_subnet_mask => '1'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3611] dhcp4 (enp0s25): option requested_time_offset => '1'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3611] dhcp4 (enp0s25): option requested_wpad       => '1'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3611] dhcp4 (enp0s25): option routers              => '192.168.0.1'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3611] dhcp4 (enp0s25): option subnet_mask          => '255.255.255.0'
Nov  3 02:14:33 thinkpad NetworkManager[1228]: <info>  [1635894873.3611] dhcp4 (enp0s25): state changed unknown -> bound
vkapas
() автор топика
Ответ на: комментарий от vkapas

Тебе же выше показали уже скрипт в /etc/NetworkManager/dispather.d, в него приходит всё - в том числе IP шлюза. Всё что надо - добавить маршрут на твой VPN через шлюз. Только убери имя устройства (параметр dev), оставь только адрес шлюза

Nastishka ★★★★★
()
Ответ на: комментарий от vkapas

Напиши в /etc/NetworkManager/dispatcher.d/somefiename

#/bin/bash
[ "$2" == "up" ] || exit 0
echo "$1" | grep "^wl\|^eth\|^enp" || exit 0
/sbin/route add -host <IP-твоего-VPN> gw $IP4_GATEWAY
exit 0

И всё. Разве что одно «но» - если ты на свой VPN ходишь по DNS и сам DNS заправляешь в VPN, то будет больно. Решается указанием IP а не имени в опции remote.

Nastishka ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin