How to setup access from server network to client network in OpenVPN (iroute doesn't work)?

Question

linux

There is such a scheme:

Client and server are routers with OpenWRT and OpenVPN installed.
Server settings (network 192.168.1.0 ) :

option dev 'tun'
  option server '10.0.100.0 255.255.255.0'
  option keepalive '10 60'
  option verb '3'
  option mssfix '1420'
  option ca '/lib/uci/upload/cbid.openvpn.Example_routed_multiclient_server.ca'
  option key '/lib/uci/upload/cbid.openvpn.Example_routed_multiclient_server.key'
  option dh '/lib/uci/upload/cbid.openvpn.Example_routed_multiclient_server.dh'
  option cert '/lib/uci/upload/cbid.openvpn.Example_routed_multiclient_server.cert'
  option enabled '1'
option client_config_dir '/etc/openvpn/ccd'
option log '/var/log/openvpn.log'
option proto 'tcp'

+ Client CCD config:
iroute 192.168.0.0 255.255.255.0
Client settings (192.168.0.0 ) :

config openvpn 'client_tun'
        option nobind '1'
        option float '1'
        option client '1'
option tls-client '1'
option proto 'tcp'
option resolv-retry 'infinite'
        option reneg_sec '0'
        option dev 'tun'
        option verb '3'
        option persist_tun '1'
        option persist_key '1'
        option remote_cert_tls 'server'
        option remote 'server.ru'
        option ca '/lib/uci/upload/cbid.openvpn.client_tun.ca'
        option cert '/lib/uci/upload/cbid.openvpn.client_tun.cert'
        option key '/lib/uci/upload/cbid.openvpn.client_tun.key'
        option enabled '1'
option log '/var/log/openvpn.log'

The task was such that from the server network it was possible to have access to computers on the client network. But that doesn't happen. The tunnel is established, the client receives the tun address 10.0.100.6, and it can be accessed from the server itself or from the server's network using this address. But there are no answers at 192.168.0.x.
Also, mwan3 is installed on the server, with balancing of two providers.
Routes on the server look like this:

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         109-x-x-x.w 0.0.0.0         UG    9      0        0 eth0.2
default         95-x-x-x.dyna 0.0.0.0         UG    10     0        0 pppoe-wan2
10.0.100.0      10.0.100.2      255.255.255.0   UG    0      0        0 tun0
10.0.100.2      *               255.255.255.255 UH    0      0        0 tun0
95.x.x.x      *               255.255.255.255 UH    0      0        0 pppoe-wan2
109.x.x.0   *               255.255.255.192 U     9      0        0 eth0.2
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1

Those. route to 192.168.0.0 is not visible.
The openvpn server logs indicate that the route is applied:

Fri Dec 18 22:57:23 2015 TCPv4_SERVER link remote: 217.y.y.y:53515
Fri Dec 18 22:57:23 2015 217.y.y.y:53515 TLS: Initial packet from 217.y.y.y:53515, sid=3b512b2d ccb4f1b3
Fri Dec 18 22:57:26 2015 217.y.y.y:53515 VERIFY OK: depth=1, /C=RU/ST=Saint-Petersburg/L=Saint-Petersburg/O=SITE/OU=Flat/CN=SITE_CA/name=FlatK/[email protected]
Fri Dec 18 22:57:26 2015 217.y.y.y:53515 VERIFY OK: depth=0, /C=RU/ST=Saint-Petersburg/L=Saint-Petersburg/O=SITE/OU=Flat/CN=client1/name=Client/[email protected]
Fri Dec 18 22:57:27 2015 217.y.y.y:53515 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Dec 18 22:57:27 2015 217.y.y.y:53515 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Dec 18 22:57:27 2015 217.y.y.y:53515 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Dec 18 22:57:27 2015 217.y.y.y:53515 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Dec 18 22:57:28 2015 217.y.y.y:53515 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Dec 18 22:57:28 2015 217.y.y.y:53515 [client1] Peer Connection Initiated with 217.y.y.y:53515
Fri Dec 18 22:57:28 2015 client1/217.y.y.y:53515 OPTIONS IMPORT: reading client specific options from: /etc/openvpn/ccd/client1
Fri Dec 18 22:57:28 2015 client1/217.y.y.y:53515 MULTI: Learn: 10.0.100.6 -> client1/217.y.y.y:53515
Fri Dec 18 22:57:28 2015 client1/217.y.y.y:53515 MULTI: primary virtual IP for client1/217.y.y.y:53515: 10.0.100.6
Fri Dec 18 22:57:28 2015 client1/217.y.y.y:53515 <b>MULTI: internal route 192.168.0.0/24 -> client1/217.y.y.y:53515</b>
Fri Dec 18 22:57:28 2015 client1/217.y.y.y:53515 <b>MULTI: Learn: 192.168.0.0/24 -> client1/217.y.y.y:53515</b>
Fri Dec 18 22:57:30 2015 client1/217.y.y.y:53515 PUSH: Received control message: 'PUSH_REQUEST'
Fri Dec 18 22:57:30 2015 client1/217.y.y.y:53515 SENT CONTROL [client1]: 'PUSH_REPLY,route 10.0.100.1,topology net30,ping 10,ping-restart 60,ifconfig 10.0.100.6 10.0.100.5' (status=1)
Fri Dec 18 22:57:30 2015 client1/217.y.y.y:53515 PUSH: Received control message: 'PUSH_REQUEST'
Fri Dec 18 22:57:30 2015 client1/217.y.y.y:53515 SENT CONTROL [client1]: 'PUSH_REPLY,route 10.0.100.1,topology net30,ping 10,ping-restart 60,ifconfig 10.0.100.6 10.0.100.5' (status=1)

I tried to add a route with the following command:

route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.0.100.2 tun0

routings became like this:

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         109-x-x-x.w 0.0.0.0         UG    9      0        0 eth0.2
default         95-x-x-x.dyna 0.0.0.0         UG    10     0        0 pppoe-wan2
10.0.100.0      10.0.100.2      255.255.255.0   UG    0      0        0 tun0
10.0.100.2      *               255.255.255.255 UH    0      0        0 tun0
95.x.x.x      *               255.255.255.255 UH    0      0        0 pppoe-wan2
109.x.x.x   *               255.255.255.192 U     9      0        0 eth0.2
192.168.0.0     10.0.100.2      255.255.255.0   UG    0      0        0 tun0
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1

But still no access.
Deleted the route and tried another command
ip ro add 192.168.0.0/24 dev tun0
got:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         109.x.x.x   0.0.0.0         UG        0 0          0 eth0.2
0.0.0.0         95.x.x.x      0.0.0.0         UG        0 0          0 pppoe-wan2
10.0.100.0      10.0.100.2      255.255.255.0   UG        0 0          0 tun0
10.0.100.2      0.0.0.0         255.255.255.255 UH        0 0          0 tun0
95.x.x.x      0.0.0.0         255.255.255.255 UH        0 0          0 pppoe-wan2
109.x.x.x   0.0.0.0         255.255.255.192 U         0 0          0 eth0.2
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 br-lan
192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1

Still no access.
Moreover, even with prescribed routes, if you try to do a traceroute on ip 192.168.0.x, you can see that the packets go to the network of the provider 109.xxx

# traceroute 192.168.0.1
traceroute to 192.168.0.1 (192.168.0.1), 30 hops max, 38 byte packets
 1  172.x.x.1 (172.x.x.1)  1.190 ms  0.032 ms  0.466 ms
^C

# traceroute ya.ru
traceroute to ya.ru (213.180.204.3), 30 hops max, 38 byte packets
 1  172.x.x.1 (172.x.x.1)  1.098 ms  0.038 ms  0.355 ms
 2  172.x.x.y (172.x.x.y)  1.157 ms  0.916 ms  0.891 ms
^C

What could be wrong? In which direction to dig?
PS. Just in case, another network settings config:

config interface 'loopback'
  option ifname 'lo'
  option proto 'static'
  option ipaddr '127.0.0.1'
  option netmask '255.0.0.0'

config interface 'lan'
  option type 'bridge'
  option proto 'static'
  option netmask '255.255.255.0'
  option _orig_ifname 'eth0.1 wlan0'
  option _orig_bridge 'true'
  option ifname 'eth0.1 eth1'
  option ipaddr '192.168.1.1'
  option dns '192.168.1.1 8.8.8.8'

config switch
  option name 'rtl8366rb'
  option reset '1'
  option enable_vlan '1'
  option enable_vlan4k '1'

config switch_vlan
  option device 'rtl8366rb'
  option vlan '1'
  option ports '2 3 4 5t'

config switch_vlan
  option device 'rtl8366rb'
  option vlan '2'
  option ports '0 5t'

config interface 'wan1'
  option ifname 'eth0.2'
  option _orig_ifname 'eth0.2'
  option _orig_bridge 'false'
  option proto 'dhcp'
  option hostname 'fuck'
  option metric '9'

config interface '3g'
  option proto '3g'

config interface 'guest'
  option proto 'static'
  option ipaddr '10.0.0.1'
  option netmask '255.255.255.0'

config switch_vlan
  option device 'rtl8366rb'
  option vlan '3'
  option ports '1 5t'

config interface 'wan2'
  option proto 'pppoe'
  option ifname 'eth0.3'
  option username 'ptn'
  option password 'ptn'
  option metric '10'

config interface 'lan_2_1'
  option proto 'static'
  option ifname 'eth1'
  option ipaddr '192.168.2.1'
  option netmask '255.255.255.0'

config interface 'vpn'
  option proto 'none'
  option ifname 'tun0'
  option metric '99'

Answer 1

In order for packets for the network 192.168.0 to go through the VPN, you need to add https://openvpn.net/index.php/open-source/document...
to the server config.

--iroute network [netmask]
Generate an internal route to a specific client. The netmask parameter, if omitted, defaults to 255.255.255.255.
This directive can be used to route a fixed subnet from the server to a particular client, regardless of where the client is connecting from. Remember that you must also add the route to the system routing table as well (such as by using the --route directive) . The reason why two routes are needed is that the --route directive routes the packet from the kernel to OpenVPN. Once in OpenVPN, the --iroute directive routes to the specific client.
This option must be specified either in a client instance config file using --client-config-dir or dynamically generated using a --client-connect script.
The --iroute directive also has an important interaction with --push "route ...". --iroute essentially defines a subnet which is owned by a particular client (we will call this client A). If you would like other clients to be able to reach A's subnet, you can use --push "route ..." together with --client-to-client to effect this. In order for all clients to see A's subnet, OpenVPN must push this route to all clients EXCEPT for A, since the subnet is already owned by A. OpenVPN accomplishes this by not not pushing a route to a client if it matches one of the client's iroutes.

this will give access from the server to the client's network. For packets to go between the client and server networks, add to the server config
or
to the client config
route 192.168.1.0 255.255.255.0