Маршрутизация из локальной сети в OpenVPN

Мне нужно настроить маршрут из нашей локальной сети в нашу VPN. То есть любой изнутри LAN должен иметь возможность связываться с машинами в VPN, , не будучи самим VPN-клиентом . Проблема в том, что я в некотором роде болван, когда дело касается сетей ...

Локальная сеть имеет 8-битный диапазон, 192.168.2.X Сам VPN-сервер находится в другой сети, на 192.168.3.20 (8-бит) Сеть VPN имеет 16-битный диапазон, 10.8.XX

Интерфейс eth0 машины, на которой запущен сервер openvpn, имеет статический IP-адрес 192.168.3.20. Интерфейс tun0 vpn-сервера сам слушает 10.8.0.1

. Мы уже работали над тем, что пакеты до 10.8.xx в локальной сети перенаправляются на сервер:

traceroute to 10.8.0.1 (10.8.0.1), 30 hops max, 60 byte packets
 1  gateway (192.168.2.1)  2.508 ms  2.364 ms  2.325 ms
 2  10.8.0.1 (10.8.0.1)  1.898 ms  1.895 ms  1.911 ms

Так что я уже могу использовать ssh через 10.8 .0.1, это нормально.

Однако, когда я пытаюсь подключиться к клиенту через VPN, результат немного отличается:

traceroute to 10.8.0.178 (10.8.0.178), 30 hops max, 60 byte packets
 1  gateway (192.168.2.1)  2.315 ms  2.152 ms  2.036 ms
 2  192.168.3.20 (192.168.3.20)  1.764 ms  1.760 ms  1.776 ms
 3  * * *
etc...

Что меня немного беспокоит, так это то, что прямой запрос к серверу завершается на 10.8.0.1, хотя я ожидал, что он либо не сработает, либо завершится на 192.168.3.20. Так что, очевидно, я не слишком понимаю, что здесь происходит ...

Исходя из этого, я подумал, что могу решить проблему, перенаправив входящий по eth0 трафик на tun0:

sudo iptables -A FORWARD -i eth0 -o tun0 -d 10.8.0.0/16 -j ACCEPT

Но этого не произошло никакого эффекта. И именно здесь я застрял. Я пробовал несколько вариантов вышеперечисленного, и поигрался с маршрутом в конфигурации OpenVPN, все без каких-либо видимых изменений.

Что интересно, так это то, что активность трассировки фактически отображается в

*VPN log, but I don't understand much of what's going on here either:
Fri Oct 19 11:57:53 2018 us=219532 GET INST BY VIRT: 10.8.0.158 -> y18022c/185.184.117.20:1194 via 10.8.0.158
Fri Oct 19 11:57:53 2018 us=219539 y18022c/185.184.117.20:1194 TUN READ [60]
Fri Oct 19 11:57:53 2018 us=219544 y18022c/185.184.117.20:1194 TLS: tls_pre_encrypt: key_id=0
Fri Oct 19 11:57:53 2018 us=219555 y18022c/185.184.117.20:1194 ENCRYPT IV: 14c0471a 9fe7860f
Fri Oct 19 11:57:53 2018 us=219580 y18022c/185.184.117.20:1194 ENCRYPT FROM: 000000ae fa450000 3cac0400 000b1135 5ec0a803 010a0800 9e98b682 bf00282[more...]
Fri Oct 19 11:57:53 2018 us=219612 y18022c/185.184.117.20:1194 ENCRYPT TO: 14c0471a 9fe7860f 00bbfc72 b50c8915 8390d362 82f0a84c c22803b1 2a7ceca[more...]
Fri Oct 19 11:57:53 2018 us=219622 PO_CTL rwflags=0x0002 ev=4 arg=0x5654a4302150
Fri Oct 19 11:57:53 2018 us=219629 PO_CTL rwflags=0x0000 ev=5 arg=0x5654a4302068
Fri Oct 19 11:57:53 2018 us=219637 I/O WAIT Tr|Tw|Sr|SW [0/63574]
Fri Oct 19 11:57:53 2018 us=219646 PO_WAIT[0,0] fd=4 rev=0x00000004 rwflags=0x0002 arg=0x5654a4302150 
Fri Oct 19 11:57:53 2018 us=219652  event_wait returned 1
Fri Oct 19 11:57:53 2018 us=219658 I/O WAIT status=0x0002
Fri Oct 19 11:57:53 2018 us=219696 y18022c/185.184.117.20:1194 UDPv4 WRITE [101] to [AF_INET]185.184.117.20:1194: P_DATA_V1 kid=0 DATA c15dc78e ddd12705 8c3a860c 9cd9fe1e da29c4b2 14c0471a 9fe7860f 00bbfc7[more...]
Fri Oct 19 11:57:53 2018 us=219707 y18022c/185.184.117.20:1194 UDPv4 write returned 101
Fri Oct 19 11:57:53 2018 us=219715 PO_CTL rwflags=0x0001 ev=4 arg=0x5654a4302150
Fri Oct 19 11:57:53 2018 us=219722 PO_CTL rwflags=0x0001 ev=5 arg=0x5654a4302068
Fri Oct 19 11:57:53 2018 us=219730 I/O WAIT TR|Tw|SR|Sw [0/63574]
Fri Oct 19 11:57:53 2018 us=231770 PO_WAIT[0,0] fd=4 rev=0x00000001 rwflags=0x0001 arg=0x5654a4302150 
Fri Oct 19 11:57:53 2018 us=231782  event_wait returned 1
Fri Oct 19 11:57:53 2018 us=231789 I/O WAIT status=0x0001
Fri Oct 19 11:57:53 2018 us=231799 UDPv4 read returned 53
Fri Oct 19 11:57:53 2018 us=231809 GET INST BY REAL: 185.184.117.20:1194 [succeeded]
Fri Oct 19 11:57:53 2018 us=231837 y18022c/185.184.117.20:1194 UDPv4 READ [53] from [AF_INET]185.184.117.20:1194: P_DATA_V1 kid=0 DATA 1196c495 845bb7fd e61cc8d8 ed4d427a b901d6c8 e81fe5a9 3ab1acce b5687f0[more...]
Fri Oct 19 11:57:53 2018 us=231846 y18022c/185.184.117.20:1194 TLS: tls_pre_decrypt, key_id=0, IP=[AF_INET]185.184.117.20:1194
Fri Oct 19 11:57:53 2018 us=231859 y18022c/185.184.117.20:1194 DECRYPT IV: e81fe5a9 3ab1acce
Fri Oct 19 11:57:53 2018 us=231876 y18022c/185.184.117.20:1194 DECRYPT TO: 00000036 fa2a187b f3641eb4 cb07ed2d 0a981fc7 48
Fri Oct 19 11:57:53 2018 us=231897 y18022c/185.184.117.20:1194 PID_TEST [0] [SSL-0] [>EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE] 0:53 0:54 t=1539943073[0] r=[0,64,15,0,1] sl=[11,53,64,528]
Fri Oct 19 11:57:53 2018 us=231905 y18022c/185.184.117.20:1194 RECEIVED PING PACKET*

. Моя самая большая проблема в том, что я понятия не имею, что именно происходит здесь ... Почему запрос к 10.8.0.1 не проходит через 192.168.3.20? Я имею в виду, было бы логично, что он должен пройти через фактический сервер перед завершением в VPN ...? И когда запросы поступают на eth0 (как видно из 192.168.3.20, отображаемого в трассировке), почему они не перенаправляются на tun0? Сам openVPN что-то здесь блокирует?