OpenVPN: IPv4 routed LAN
Sumber: https://backreference.org/2009/11/15/openvpn-and-iroute/
gwA
gwA # cat /etc/openvpn/server.conf # gwA local 172.20.0.1 port 1194 proto udp dev tun topology subnet mode server tls-server ifconfig 10.0.0.1 255.255.255.0 route 192.168.2.0 255.255.255.0 10.0.0.2 route 192.168.3.0 255.255.255.0 10.0.0.3 client-config-dir ccd # snip rest of config
gwA # cat /etc/openvpn/ccd/gwB ifconfig-push 10.0.0.2 255.255.255.0 push "route 192.168.1.0 255.255.255.0 10.0.0.1" iroute 192.168.2.0 255.255.255.0
gwA # cat /etc/openvpn/ccd/gwC ifconfig-push 10.0.0.3 255.255.255.0 push "route 192.168.1.0 255.255.255.0 10.0.0.1" iroute 192.168.3.0 255.255.255.0
gwB
gwB # cat /etc/openvpn/client.conf # gwB remote 172.20.0.1 1194 proto udp dev tun topology subnet # snip rest of config
gwC
gwC # cat /etc/openvpn/client.conf # gwC remote 172.20.0.1 1194 proto udp dev tun topology subnet # snip rest of config
Cek
ping route
Teori
At this point, some background on how OpenVPN works internally is in order. When OpenVPN receives a packet or frame on the tun/tap interface to forward, it encrypts it and encapsulates it into one or more UDP datagrams, which are then sent out to some remote (usually public) IP address where another VPN node will receive it on its public IP, decapsulate and decrypt them, and send them to the local tun/tap interface, where they will be finally seen by the OS. The process also works in the opposite direction of course.
If the IP addresses involved are only those belonging to the VPN, OpenVPN has no trouble to associate a certain VPN IP to the public IP address of a remote VPN peer (as long as the addresses were pushed by the server to the clients and not statically assigned).
However, when non-VPN packets are involved, OpenVPN needs more information. In our A-to-C example, when gwA receives the packet with src=192.168.1.1 and dst=192.168.3.1, the routing table sends it to the tun0 interface, and thus to OpenVPN. Now, how does OpenVPN know behind which remote peer that destination IP is? That is a necessary piece of information it needs in order to know the destination IP to use for the encapsulating UDP packets.
Similarly, in the C-to-A direction, when gwA's OpenVPN sees a packet with src=192.168.3.1 and dst=192.168.1.1, it needs to make sure that it knows how to reach the source address, in order to send replies later. So it's just a different aspect of the same problem.
Since there can be (and there actually is) more than one peer, OpenVPN needs to know which network is behind each peer. You might think (as I naively did) that it should be able to somehow infer that information from the routes in the routing table, for example since gwA has this route in the routing table
192.168.3.0/24 via 10.0.0.3 dev tun0
it could assume that 192.168.3.0/24 is behind 10.0.0.3, and thus use gwC's public IP to send encapsulated traffic destined to 192.168.3.0/24. Well, it seems that it doesn't work that way. You have to explicitly tell OpenVPN which network is behind each client. This is where our iroute directive comes into play.