OpenVPN не восстанавливает маршрут после переподключения к интернету

[vkapas]

Есть OpenVPN сервер на последней Cent OS и клиент на Ubuntu 20. Проблема — на клиенте исчезает доступ в интерент и к OVPN-серверу после разрыва подключения к интернету. При этом у других клиентов на Android всё ОК.

1. Клиент подключается к интернету:

Код: Выделить всё

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.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.1.0     0.0.0.0         255.255.255.0   U     100    0        0 enp0s25

2. Клиент подключается к OpenVPN-серверу:

Код: Выделить всё

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.25       128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.1.1     0.0.0.0         UG    100    0        0 enp0s25
10.8.0.1        10.8.0.25       255.255.255.255 UGH   0      0        0 tun0
10.8.0.25       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
128.0.0.0       10.8.0.25       128.0.0.0       UG    0      0        0 tun0
123.123.123.123   192.168.1.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.1.0     0.0.0.0         255.255.255.0   U     100    0        0 enp0s25

3. Клиент отключается от интернета (не разрывая vpn-соединение), после чего подключается обратно:

Код: Выделить всё

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.25       128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.1.1     0.0.0.0         UG    100    0        0 enp0s25
10.8.0.1        10.8.0.25       255.255.255.255 UGH   0      0        0 tun0
10.8.0.25       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
128.0.0.0       10.8.0.25       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.1.0     0.0.0.0         255.255.255.0   U     100    0        0 enp0s25

То есть после переподключения к сети на клиенте теряется маршрут

Код: Выделить всё

123.123.123.123   192.168.1.1     255.255.255.255 UGH   0      0        0 enp0s25

где 123.123.123.123 — внешний IP сервера.

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

Spoiler

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

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

Spoiler

client
dev tun
proto udp
remote 123.123.123.123 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>

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

Код: Выделить всё

Wed Sep  8 15:59:39 2021 us=751334 Recursive routing detected, drop tun packet to [AF_INET]123.123.123.123:443

Если запускать подключение с --allow-recursive-routing, то в логах уже после разрыва интернета-подключения ничего нового не появляется. При verb 5 добавляется бесконечный RwRwRw, при verb 6 — UDP WRITE [96] to [AF_INET]123.123.123.123:443: P_DATA_V2 kid=0 DATA len=95 и TUN READ [124].

Лог сервера (как и следует ожидать, не меняется уже после обрыва подключения к интернету у клиента):

Код: Выделить всё

сен 08 13:17:53 vpn-srv openvpn[2827143]: 1.2.3.4:46836 TLS: Initial packet from [AF_INET]1.2.3.4:46836, sid=e431b65e eb6208fa                       
сен 08 13:17:53 vpn-srv openvpn[2827143]: 1.2.3.4:46836 VERIFY OK: depth=1, CN=Easy-RSA CA                                                               
сен 08 13:17:53 vpn-srv openvpn[2827143]: 1.2.3.4:46836 VERIFY OK: depth=0, CN=test                                                                      
сен 08 13:17:53 vpn-srv openvpn[2827143]: 1.2.3.4:46836 peer info: IV_VER=2.4.7                                                                          
сен 08 13:17:53 vpn-srv openvpn[2827143]: 1.2.3.4:46836 peer info: IV_PLAT=linux                                                                         
сен 08 13:17:53 vpn-srv openvpn[2827143]: 1.2.3.4:46836 peer info: IV_PROTO=2                                                                            
сен 08 13:17:53 vpn-srv openvpn[2827143]: 1.2.3.4:46836 peer info: IV_NCP=2                                                                              
сен 08 13:17:53 vpn-srv openvpn[2827143]: 1.2.3.4:46836 peer info: IV_LZ4=1
сен 08 13:17:53 vpn-srv openvpn[2827143]: 1.2.3.4:46836 peer info: IV_LZ4v2=1                                                                            
сен 08 13:17:53 vpn-srv openvpn[2827143]: 1.2.3.4:46836 peer info: IV_LZO=1                                                                              
сен 08 13:17:53 vpn-srv openvpn[2827143]: 1.2.3.4:46836 peer info: IV_COMP_STUB=1                                                                        
сен 08 13:17:53 vpn-srv openvpn[2827143]: 1.2.3.4:46836 peer info: IV_COMP_STUBv2=1                                                                      
сен 08 13:17:53 vpn-srv openvpn[2827143]: 1.2.3.4:46836 peer info: IV_TCPNL=1                                                                            
сен 08 13:17:53 vpn-srv openvpn[2827143]: 1.2.3.4:46836 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA                     
сен 08 13:17:53 vpn-srv openvpn[2827143]: 1.2.3.4:46836 [test] Peer Connection Initiated with [AF_INET]1.2.3.4:46836                                 
сен 08 13:17:53 vpn-srv openvpn[2827143]: MULTI: new connection by 1.2.3.4 'test' will cause previous active sessions by this 1.2.3.4 to be dropped.  Remember t
o use the --duplicate-cn option if you want multiple 1.2.3.4s using the same certificate or username to concurrently connect.                                 
сен 08 13:17:53 vpn-srv openvpn[2827143]: MULTI_sva: pool returned IPv4=10.8.0.26, IPv6=(Not enabled)                                                        
сен 08 13:17:53 vpn-srv openvpn[2827143]: MULTI: Learn: 10.8.0.26 -> test/1.2.3.4:46836                                                                  
сен 08 13:17:53 vpn-srv openvpn[2827143]: MULTI: primary virtual IP for test/1.2.3.4:46836: 10.8.0.26                                                     
сен 08 13:17:54 vpn-srv openvpn[2827143]: test/1.2.3.4:46836 PUSH: Received control message: 'PUSH_REQUEST'                                               
сен 08 13:17:54 vpn-srv openvpn[2827143]: test/1.2.3.4:46836 SENT CONTROL [test]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222
.222,dhcp-option DNS 208.67.220.220,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.26 10.8.0.25,peer-id 0,cipher AES-256-GCM' (status=
1)                                                                                                                                                           
сен 08 13:17:54 vpn-srv openvpn[2827143]: test/1.2.3.4:46836 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key                    
сен 08 13:17:54 vpn-srv openvpn[2827143]: test/1.2.3.4:46836 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

Коллеги, подскажите, где я допустил ошибку в настройке OpenVPN?

Нашёл единственную похожую ситуацию, но и там человеку написали, что воспроизвести проблему не удалось, то есть она была где-то на его стороне.

[Minton]

Мне кажется, что проблема действительно не в openVPN, он добавил нужный маршрут на старте своего подключения и не считает нужным проверять его наличие после этого. А маршрут удаляет кто-то ещё при отключении интернета (демон DHCP или NetworkManager или что там ещё может править таблицу маршрутов, несть им числа)
В качестве сурового обходного пути можно добавлять этот маршрут каждый раз при подъёме интерфейса 192.168.1.1 (enp0s25)

[vkapas]

Добрался наконец до тестов — проблема воспроизводится ещё минимум на двух машинах с Ubuntu 20.04 с последними обновлениями, причём одна — чистая, развёрнутая специально для проверки.

Как-то стрёмно это всё. До последнего был уверен, что проблема где-то в конфигурации или кривом обновлении с предыдущей версии Ubuntu. Добавление маршрута руками или скриптами так себе вариант, конечно, в том числе потому что и шлюз и интерфейс часто меняются.

Вообще я изначально настраивал всё для работы через GUI, пока не выяснил, что NetworkManager до сих пор не умеет работать с маршрутами OpenVPN с net_gateway, что для меня тоже стало большим и неприятным сюрпризом.

Блин, не думал, что в Линуксах (точнее, Убунтах) всё так плохо с поддержкой OpenVPN. Если не найдётся простого решения, придётся переходить на какой-нибудь WireGuard.

[Bizdelnick]

Блин, не думал, что в Линуксах (точнее, Убунтах) всё так плохо с поддержкой OpenVPN.

Так проблема в самом openvpn. Кроме него про эти маршруты и не знает никто. Тут только приделывать какой-нибудь хук для передёргивания openvpn при подъёме интерфейса.