*Update*
As per request via PM, I will post my findings.
The above setups can generally work. However there are problems with MTU and fragmentation. If you have followed the diagrams posted above, and you would like to complete the setup to get it working, follow these final steps:
[1] Don't use --> push "redirect gateway def1" on any of your server instances. In fact, just don't push anything. Instead, we will use environment variables from the client.
[2] Add the following lines to your first client config (what do I mean by first client config? I mean -- your PC that you connect from at home will have 2 client instances of openVPN. The first client instance connects to the first hop at country A, the second client instance connects to the second hop at country B)
1st client config:
client
dev tun
proto udp
remote COUNTRY_A_IP 1194
route-nopull
route remote_host 255.255.255.255 net_gateway
route 10.77.2.1 255.255.255.255 10.77.1.1
2nd client config:
client
dev tun
proto udp
remote 10.77.2.1 1194
route 0.0.0.0 128.0.0.0 10.77.2.1
route 128.0.0.0 128.0.0.0 10.77.2.1
each client config will not be complete with the above code. You have to add the rest of the junk such as:
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
ns-cert-type server
comp-lzo
verb 3
ping 10
ping-restart 60
but that will be largely dependent on your own needs, so just modify it as you will.
Due to MTU and fragmentation problems, I have dropped the pursuit of the above method. If OpenVPN allowed a server instance to set "per client" MTU then it would be no problem, since it would be possible to have a larger MTU for the outer layer of tunnel and smaller for the inner.
Consider all of the above frameworks to be abandoned by me, and the framework in the next post to be the most appropriate for the desired outcome as per OP.