Background<\/h2>\n\n\n\n
The approach was originally developed back in 2011…2014 when I lived in China and maintained several outgoing VPN connections from my Linux server to end points “in the West” so that I could circumvent internet censorship in China [8<\/a>]. With the VPN service described Setting up Dual Stack VPNs<\/a>, it was then possible for me to be in town and to connect the smartphone to my Linux server (in the same town). From there, the connections to sites blocked in China would run over the client VPNs of the Linux server so that I could use Google Maps on my smartphone, for example (which at that time had already been blocked in China).<\/p>\n\n\n\n Routing in Linux follows some very clever approaches which can be combined in mighty ways. Those readers who want to understand all<\/em> of the underlying theory, are encouraged to study the (older) documents [1<\/a>], [2<\/a>], [3<\/a>], even if parts<\/em> of the content might not be relevant any more. Those readers who just want to follow and replicate the approach in this blog, should at least<\/em> study the documents [4<\/a>], [5<\/a>], [6<\/a>].<\/p>\n\n\n\n Apart from that, in order to replicate the approach described here, you should:<\/p>\n\n\n\n The graph below shows the setup on my machine caipirinha.spdns.org with. The 5 VPN services<\/strong> (blue, green color) were already described in blog post Setting up Dual Stack VPNs<\/a>. Now, we have a close look at the 3 VPN clients<\/strong> which use a commercial VPN service (ocker color) in order to connect to VPN end points in 3 different countries (Portugal, Singapore, Thailand).<\/p>\n\n\n\n Routing needs to be enabled on the Linux server. I personally also decided to switch off the privacy extensions on the Linux server, but that is a personal matter of taste:<\/p>\n\n\n\n We now must have a closer look at the concept of the routing table<\/a>. A routing tables basically lists routes to particular network destinations. An example is the routing table main<\/strong> on my Linux server. It reads:<\/p>\n\n\n\n This table has 7 entries, and they have this meaning:<\/p>\n\n\n\n Usually, a routing table should have a default<\/strong> entry which sends all IP traffic that is not explicitly routed to other network interfaces to the default router<\/em> of a network. Otherwise, no meaningful internet access is possible.<\/p>\n\n\n\n A Linux system can have up to 256 routing tables which are defined in \/etc\/iproute2\/rt_tables<\/strong>. They can either be used by their number or by their name. On my Linux server, I have set up 3 additional routing tables, named “Portugal”, “Singapur”, “Thailand”. You can see in the file \/etc\/iproute2\/rt_tables<\/strong> that besides the table main<\/strong>, the tables local<\/strong>, default<\/strong>, and unspec<\/strong> do already exist, but they are not of interest for our purposes.<\/p>\n\n\n\n Right now (before we set up the client VPNs), all 3 routing tables look the same as shown here:<\/p>\n\n\n\n The content of routing tables can be listed with the command ip route list table ${tablename}<\/strong>, and ${tablename}<\/strong> needs to exist in \/etc\/iproute2\/rt_tables<\/strong>. It is important to notice that so far, none of these 3 routing tables have a default route. They only contain the home network and the networks of the 5 VPN services. Right now, these tables are not yet useful. In case you wonder how it comes that these 3 routing tables are populated with their entries. That needs to done either manually or by a script (see next chapter). <\/p>\n\n\n\n Now that we have 3 additional routing tables, we must ensure that the networks of our 5 VPN services are also inserted in these 3 routing tables. Therefore, we modify the configuration files described in the blog post Setting up Dual Stack VPNs<\/a> so that a script runs when the VPN service is started. In the configuration files for the openvpn<\/a> configuration, we insert the statement:<\/p>\n\n\n\n In the configuration files for the WireGuard<\/a> configuration, we insert the statement:<\/p>\n\n\n\n The effect of these statements is that the script \/etc\/openvpn\/start_vpn.sh<\/strong> is executed when the VPN service has been set up. If no arguments are specified, openvpn<\/a> hands over 5 arguments to the scripts (see [9<\/a>], section “–up cmd”). In the WireGuard<\/a> configuration, we have to explicitly specify the arguments, the “%i” means the interface (see [10<\/a>], “PostUp”). In my case, “%i” hence stands for wg0<\/strong>.<\/p>\n\n\n\n The script \/etc\/openvpn\/start_vpn.sh<\/strong> was originally developed for the openvpn<\/a> configuration and therefore intakes all the default arguments that openvpn<\/a> transmits, although only the first and the fourth argument are used. Therefore, in the WireGuard<\/a> configuration, there are two “-” inserted as bogus arguments. That is surely something that can be solved more elegantly.<\/p>\n\n\n\n What does this script do? It essentially writes the same entry that is done automatically in the routing table main<\/strong> to the 3 additional routing tables Portugal<\/strong>, Singapur<\/strong>, and Thailand<\/strong>. It assumes that VPN services have a \/24 network (true in my own case, not necessarily for other setups).<\/p>\n\n\n\n For our experiments, we now also need to allocate 3 dedicated IP addresses to 3 devices in one of the VPN services on the Linux server so that the devices always get the same IP address by the VPN service when they connect (pseudo-static IP configuration). As described in the blog post Setting up Dual Stack VPNs<\/a>, section “Dedicated Configurations”, we can achieve this by creating 3 files with the common names of the devices (gabriel-SM-G991B, gabriel-SM-N960F, gabriel-SM-T580) that were used to create their certificates. I did that for the UDP-based VPN, full tunneling openvpn<\/a>, and the 3 configuration files are listed here:<\/p>\n\n\n\n One can easily identify the respective IPv4 and IPv6 addresses which shall be allocated to the 3 named devices:<\/p>\n\n\n\n Let us not forget that this is the configuration for only one out of the 5 VPN services. If the devices connect to a VPN service different from the UDP-based VPN, full tunneling openvpn<\/a>, then, these configurations do not have any effect.<\/p>\n\n\n\n For the experiments below, we will set up 3 client VPN connections to different countries. As I do not have infrastructure outside of Germany, I use a commercial VPN provider, in my case this is PureVPN\u2122<\/a> (as I once got an affordable 5-years subscription). Choosing a suitable VPN provider is not easy, and I strongly recommend to research test reports and forums which deal with the configuration on Linux before you choose any subscription to a commercial VPN provider. In my case, the provider (PureVPN\u2122<\/a>) offers openvpn<\/a> Linux configuration as a download. I just had to make some modifications as otherwise, the VPN wants to be the default connection for all internet traffic; this is not what we want when we do our own policy routing. I chose the TCP configuration as the UDP configuration, which is normally preferred, did not run in a stable fashion at the time of writing this article. The client configuration files also contain the ca<\/strong>, the certificate<\/strong>, and the key<\/strong> file at the end (not shown here).<\/p>\n\n\n\n I stored these configurations in the files:<\/p>\n\n\n\n Let us discuss some configuration items:<\/p>\n\n\n\n Let’s now look at the start script \/etc\/openvpn\/start_purevpn.sh<\/strong>. This script depends on the installation of the tool library ipcalc<\/strong> as this library eases some computations.<\/p>\n\n\n\n What does this script do? It executes these steps:<\/p>\n\n\n\n Consequently, the script \/etc\/openvpn\/stop_purevpn.sh<\/strong> serves to clean up the entries in the filter<\/strong> table. We do not have to remove the entries in the 3 additional routing tables as they disappear automatically when the VPN connection is disbanded. This script is somewhat smaller:<\/p>\n\n\n\n Now, that we have all these pieces together, we start the 3 client VPNs with the commands:<\/p>\n\n\n\n After some seconds, the 3 client VPN connections should have fully been set up, and the respective network devices tun0<\/strong>, tun1<\/strong>, tun2<\/strong> should exist. Similar to what was described in the blog post Setting up Dual Stack VPNs<\/a>, we must configure network address translation for the 3 client VPNs so that outgoing packets get modified in a way that they have the source IP address of the Linux server for the specific interface over which those packets shall travel. That is done with:<\/p>\n\n\n\n We use MASQUERADE<\/strong> in this case because the IP address of the Linux server can change at each VPN connection, and we do not know the source address beforehand. Otherwise SNAT<\/strong> would be the better option that consumes less CPU power.<\/p>\n\n\n\n Now, we should be able to ping a machine (in this example, Google<\/a>‘s DNS) via each of the 3 client VPN connections, as shown here:<\/p>\n\n\n\n A traceroute to Google<\/a>‘s DNS via the 3 client VPN connections shows us the route the packets travel; the first example shows the route via the default connection (eth0<\/em>):<\/p>\n\n\n\n Finally, we look at the routing tables that have changed after we have established the 3 client VPN connections:<\/p>\n\n\n\n In the routing tables, we can observe the following new items:<\/p>\n\n\n\n Now, we are all set to define routing policies and do our first steps in the field of policy routing<\/strong>.<\/p>\n\n\n\n In the first example, we will “place” each device (gabriel-SM-G991B, gabriel-SM-N960F, gabriel-SM-T580) in a different country. Let us recall that, when each of these devices connects to the Linux server via the UDP-based, full tunneling\u00a0openvpn<\/a>, then each device gets a defined IP address. This allows us to define routing policies based on the IP address [11<\/a>]. In order to modify the routing policy database<\/strong> of the Linux server, we enter the commands:<\/p>\n\n\n\n The resulting routing policy database looks like this:<\/p>\n\n\n\n The number at the beginning of each line in the routing policy database is the priority; this allows us to define routing policies in a defined order. As soon as the selector of a rule matches the a packet, the corresponding action is executed, and no further rules are checked for this packet. [11<\/a>] lists the possible selectors and actions, and we can see that there are a lot of possibilities, especially when we combine different matching criteria. In the case shown here, our rules tell the Linux server the following:<\/p>\n\n\n\nPreconditions<\/h2>\n\n\n\n
\n
Description and Usage<\/h2>\n\n\n\n
![\"\"](\"https:\/\/caipirinha.spdns.org\/wp\/wp-content\/uploads\/VPN-Diagramm-2-1024x576.jpg\")
Enabling Routing<\/h3>\n\n\n\n
# Enable \"loose\" reverse path filtering and prohibit icmp redirects\nsysctl -w net.ipv4.conf.all.rp_filter=2\nsysctl -w net.ipv4.conf.all.send_redirects=0\nsysctl -w net.ipv4.conf.eth0.send_redirects=0\nsysctl -w net.ipv4.icmp_errors_use_inbound_ifaddr=1\n\n# Enable IPv6 routing, but keep SLAAC for eth0\nsysctl -w net.ipv6.conf.eth0.accept_ra=2\nsysctl -w net.ipv6.conf.all.forwarding=1\n\n# Switch off the privacy extensions\nsysctl -w net.ipv6.conf.eth0.use_tempaddr=0<\/code><\/pre>\n\n\n\nRouting Tables<\/h3>\n\n\n\n
caipirinha:~ # ip route list table main<\/strong>\ndefault via 192.168.2.1 dev eth0 proto dhcp\n192.168.2.0\/24 dev eth0 proto kernel scope link src 192.168.2.3\n192.168.10.0\/24 dev tun4 proto kernel scope link src 192.168.10.1\n192.168.11.0\/24 dev tun5 proto kernel scope link src 192.168.11.1\n192.168.12.0\/24 dev tun6 proto kernel scope link src 192.168.12.1\n192.168.13.0\/24 dev tun7 proto kernel scope link src 192.168.13.1\n192.168.14.0\/24 dev wg0 proto kernel scope link src 192.168.14.1<\/code><\/pre>\n\n\n\n\n
#\n# reserved values\n#\n255 local\n254 main\n253 default\n0 unspec\n#\n# local\n#\n#1 inr.ruhep\n\n240 Portugal\n241 Singapur\n242 Thailand<\/code><\/pre>\n\n\n\ncaipirinha:~ # ip route list table Portugal<\/strong>\n192.168.2.0\/24 dev eth0 proto kernel scope link src 192.168.2.3\n192.168.10.0\/24 via 192.168.10.1 dev tun4\n192.168.11.0\/24 via 192.168.11.1 dev tun5\n192.168.12.0\/24 via 192.168.12.1 dev tun6\n192.168.13.0\/24 via 192.168.13.1 dev tun7\n192.168.14.0\/24 via 192.168.14.1 dev wg0\ncaipirinha:~ # ip route list table Singapur<\/strong>\n192.168.2.0\/24 dev eth0 proto kernel scope link src 192.168.2.3\n192.168.10.0\/24 via 192.168.10.1 dev tun4\n192.168.11.0\/24 via 192.168.11.1 dev tun5\n192.168.12.0\/24 via 192.168.12.1 dev tun6\n192.168.13.0\/24 via 192.168.13.1 dev tun7\n192.168.14.0\/24 via 192.168.14.1 dev wg0\ncaipirinha:~ # ip route list table Thailand<\/strong>\n192.168.2.0\/24 dev eth0 proto kernel scope link src 192.168.2.3\n192.168.10.0\/24 via 192.168.10.1 dev tun4\n192.168.11.0\/24 via 192.168.11.1 dev tun5\n192.168.12.0\/24 via 192.168.12.1 dev tun6\n192.168.13.0\/24 via 192.168.13.1 dev tun7\n192.168.14.0\/24 via 192.168.14.1 dev wg0<\/code><\/pre>\n\n\n\nOpenVPN Server Configuration (Update)<\/h3>\n\n\n\n
up \/etc\/openvpn\/start_vpn.sh<\/code><\/pre>\n\n\n\nPostUp = \/etc\/openvpn\/start_vpn.sh %i - - 192.168.14.1<\/code><\/pre>\n\n\n\n#!\/bin\/bash\n#\n# This script sets the VPN parameters in the routing tables \"Portugal\", \"Singapur\" and \"Thailand\" once the server has been started successfully.\n\n# Set the correct PATH environment\nPATH='\/sbin:\/usr\/sbin:\/bin:\/usr\/bin'\n\nVPN_DEV=\"${1}\"\nVPN_SRC=\"${4}\"\nVPN_NET=$(echo \"${VPN_SRC}\" | cut -d . -f 1-3)\".0\/24\"\n\nfor TABLE in Portugal Singapur Thailand; do\n ip route add ${VPN_NET} dev ${VPN_DEV} via ${VPN_SRC} table ${TABLE}\ndone<\/code><\/pre>\n\n\n\ncaipirinha:~ # cat \/etc\/openvpn\/conf-1194\/gabriel-SM-G991B<\/strong>\n# Spezielle Konfigurationsdatei f\u00fcr Gabriels Galaxy S20 (gabriel-SM-G991B)\n#\n\nifconfig-push 192.168.10.250 255.255.255.0\nifconfig-ipv6-push fd01:0:0:a:0:0:1:fa\/111 fd01:0:0:a::1\ncaipirinha:~ # cat \/etc\/openvpn\/conf-1194\/gabriel-SM-N960F<\/strong>\n# Spezielle Konfigurationsdatei f\u00fcr Gabriels Galaxy Note 9 (gabriel-SM-N960F)\n#\n\nifconfig-push 192.168.10.251 255.255.255.0\nifconfig-ipv6-push fd01:0:0:a:0:0:1:fb\/111 fd01:0:0:a::1\ncaipirinha:~ # cat \/etc\/openvpn\/conf-1194\/gabriel-SM-T580<\/strong>\n# Spezielle Konfigurationsdatei f\u00fcr Gabriels Galaxy Tablet A (gabriel-SM-T580)\n#\n\nifconfig-push 192.168.10.252 255.255.255.0\nifconfig-ipv6-push fd01:0:0:a:0:0:1:fc\/111 fd01:0:0:a::1<\/code><\/pre>\n\n\n\n\n
OpenVPN Client Configuration<\/h3>\n\n\n\n
TCP-based split VPN to Portugal<\/h4>\n\n\n\n
# Konfigurationsdatei f\u00fcr den openVPN-Client auf CAIPIRINHA zur Verbindung nach PureVPN (Portugal)\n\nauth-user-pass \/etc\/openvpn\/purevpn.login\nauth-nocache \nauth-retry nointeract\nclient\ncomp-lzo\ndev tun0\nifconfig-nowarn\nkey-direction 1\nlog \/var\/log\/openvpn_PT.log\nlport 5456\nmute 20\nproto tcp\npersist-key\npersist-tun\nremote pt2-auto-tcp.ptoserver.com 80\nremote-cert-tls server\nroute-nopull\nscript-security 2\nstatus \/var\/run\/openvpn\/status_PT\nup \/etc\/openvpn\/start_purevpn.sh\ndown \/etc\/openvpn\/stop_purevpn.sh\nverb 3\n\n<ca>\n-----BEGIN CERTIFICATE-----\nMIIE6DCCA9CgAwIBAgIJAMjXFoeo5uSlMA0GCSqGSIb3DQEBCwUAMIGoMQswCQYD\n...\n4ZjTr9nMn6WdAHU2\n-----END CERTIFICATE-----\n<\/ca>\n<cert>\n-----BEGIN CERTIFICATE-----\nMIIEnzCCA4egAwIBAgIBAzANBgkqhkiG9w0BAQsFADCBqDELMAkGA1UEBhMCSEsx\n...\n21oww875KisnYdWjHB1FiI+VzQ1\/gyoDsL5kPTJVuu2CoG8=\n-----END CERTIFICATE-----\n<\/cert>\n<key>\n-----BEGIN PRIVATE KEY-----\nMIICdgIBADANBgkqhkiG9w0BAQEFAASCAmAwggJcAgEAAoGBAMbJ8p+L+scQz57g\n...\nd7q7xhec5WHlng==\n-----END PRIVATE KEY-----\n<\/key>\n<tls-auth>\n#\n# 2048 bit OpenVPN static key\n#\n-----BEGIN OpenVPN Static key V1-----\ne30af995f56d07426d9ba1f824730521\n...\ndd94498b4d7133d3729dd214a16b27fb\n-----END OpenVPN Static key V1-----\n<\/tls-auth><\/code><\/pre>\n\n\n\nTCP-based split VPN to Singapore<\/h4>\n\n\n\n
# Konfigurationsdatei f\u00fcr den openVPN-Client auf CAIPIRINHA zur Verbindung nach PureVPN (Singapur)\n\nauth-user-pass \/etc\/openvpn\/purevpn.login\nauth-nocache\nauth-retry nointeract\nclient\ncomp-lzo\ndev tun1\nifconfig-nowarn\nkey-direction 1\nlog \/var\/log\/openvpn_SG.log\nlport 5457\nmute 20\nproto tcp\npersist-key\npersist-tun\nremote sg2-auto-tcp.ptoserver.com 80\nremote-cert-tls server\nroute-nopull\nscript-security 2\nstatus \/var\/run\/openvpn\/status_SG\nup \/etc\/openvpn\/start_purevpn.sh\ndown \/etc\/openvpn\/stop_purevpn.sh\nverb 3\n...<\/code><\/pre>\n\n\n\nTCP-based split VPN to Thailand<\/h4>\n\n\n\n
# Konfigurationsdatei f\u00fcr den openVPN-Client auf CAIPIRINHA zur Verbindung nach PureVPN (Thailand)\n\nauth-user-pass \/etc\/openvpn\/purevpn.login\nauth-nocache\nauth-retry nointeract\nclient\ncomp-lzo\ndev tun2\nifconfig-nowarn\nkey-direction 1\nlog \/var\/log\/openvpn_TH.log\nlport 5458\nmute 20\nproto tcp\npersist-key\npersist-tun\nremote th2-auto-tcp.ptoserver.com 80\nremote-cert-tls server\nroute-nopull\nscript-security 2\nstatus \/var\/run\/openvpn\/status_TH\nup \/etc\/openvpn\/start_purevpn.sh\ndown \/etc\/openvpn\/stop_purevpn.sh\nverb 3\n...<\/code><\/pre>\n\n\n\n\n
\n
#!\/bin\/bash\n#\n# This script sets the VPN parameters in the routing tables \"main\", \"Portugal\", \"Singapur\" and \"Thailand\" once the connection has been successfully established.\n# This script requires the tool \"ipcalc\" which needs to be installed on the target system.\n\n# Set the correct PATH environment\nPATH='\/sbin:\/usr\/sbin:\/bin:\/usr\/bin'\n\nVPN_DEV=$1\nVPN_SRC=$4\nVPN_MSK=$5\n\nVPN_GW=$(ipcalc ${VPN_SRC}\/${VPN_MSK} | sed -n 's\/^HostMin:\\s*\\([0-9]\\{1,3\\}\\.[0-9]\\{1,3\\}\\.[0-9]\\{1,3\\}\\.[0-9]\\{1,3\\}\\).*\/\\1\/p')\nVPN_NET=$(ipcalc ${VPN_SRC}\/${VPN_MSK} | sed -n 's\/^Network:\\s*\\([0-9]\\{1,3\\}\\.[0-9]\\{1,3\\}\\.[0-9]\\{1,3\\}\\.[0-9]\\{1,3\\}\\\/[0-9]\\{1,2\\}\\).*\/\\1\/p')\n\ncase \"${VPN_DEV}\" in\n \"tun0\") ROUTING_TABLE='Portugal';;\n \"tun1\") ROUTING_TABLE='Singapur';;\n \"tun2\") ROUTING_TABLE='Thailand';;\nesac\n\niptables -t filter -A INPUT -i ${VPN_DEV} -m state --state NEW,INVALID -j DROP\niptables -t filter -A FORWARD -i ${VPN_DEV} -m state --state NEW,INVALID -j DROP\n\nip route add ${VPN_NET} dev ${VPN_DEV} proto kernel scope link src ${VPN_SRC} table ${ROUTING_TABLE}\nip route replace default dev ${VPN_DEV} via ${VPN_GW} table ${ROUTING_TABLE}<\/code><\/pre>\n\n\n\n\n
#!\/bin\/bash\n#\n# This script removes some routing table entries when the connection is terminated.\n\n# Set the correct PATH environment\nPATH='\/sbin:\/usr\/sbin:\/bin:\/usr\/bin'\n\nVPN_DEV=$1\n\niptables -t filter -D INPUT -i ${VPN_DEV} -m state --state NEW,INVALID -j DROP\niptables -t filter -D FORWARD -i ${VPN_DEV} -m state --state NEW,INVALID -j DROP<\/code><\/pre>\n\n\n\nsystemctl start openvpn@client_PT\nsystemctl start openvpn@client_SG\nsystemctl start openvpn@client_TH<\/code><\/pre>\n\n\n\niptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE\niptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE\niptables -t nat -A POSTROUTING -o tun2 -j MASQUERADE<\/code><\/pre>\n\n\n\ncaipirinha:~ # ping -c 3 -I tun0 8.8.8.8<\/strong>\nPING 8.8.8.8 (8.8.8.8) from 172.17.66.34 tun0: 56(84) bytes of data.\n64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=57.7 ms\n64 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=54.5 ms\n64 bytes from 8.8.8.8: icmp_seq=3 ttl=119 time=54.7 ms\n\n--- 8.8.8.8 ping statistics ---\n3 packets transmitted, 3 received, 0% packet loss, time 2003ms\nrtt min\/avg\/max\/mdev = 54.516\/55.649\/57.727\/1.483 ms\ncaipirinha:~ # ping -c 3 -I tun1 8.8.8.8<\/strong>\nPING 8.8.8.8 (8.8.8.8) from 10.12.42.41 tun1: 56(84) bytes of data.\n64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=249 ms\n64 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=247 ms\n64 bytes from 8.8.8.8: icmp_seq=3 ttl=58 time=247 ms\n\n--- 8.8.8.8 ping statistics ---\n3 packets transmitted, 3 received, 0% packet loss, time 2002ms\nrtt min\/avg\/max\/mdev = 247.120\/247.972\/249.111\/1.015 ms\ncaipirinha:~ # ping -c 3 -I tun2 8.8.8.8<\/strong>\nPING 8.8.8.8 (8.8.8.8) from 10.31.6.38 tun2: 56(84) bytes of data.\n64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=13.9 ms\n64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=14.2 ms\n64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=22.6 ms\n\n--- 8.8.8.8 ping statistics ---\n3 packets transmitted, 3 received, 0% packet loss, time 2001ms\nrtt min\/avg\/max\/mdev = 13.910\/16.934\/22.641\/4.039 ms\n<\/code><\/pre>\n\n\n\ncaipirinha:~ # traceroute -i eth0 8.8.8.8<\/strong>\ntraceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets\n 1 Router-EZ (192.168.2.1) 3.039 ms 2.962 ms 2.927 ms\n 2 fra1813aihr002.versatel.de (62.214.63.145) 15.440 ms 16.978 ms 18.866 ms\n 3 62.72.71.113 (62.72.71.113) 16.116 ms 19.534 ms 19.506 ms\n 4 89.246.109.249 (89.246.109.249) 24.717 ms 25.460 ms 24.659 ms\n 5 72.14.204.148 (72.14.204.148) 20.530 ms 20.602 ms 89.246.109.250 (89.246.109.250) 24.573 ms\n 6 * * *\n 7 dns.google (8.8.8.8) 20.265 ms 16.966 ms 14.751 ms\ncaipirinha:~ # traceroute -i tun0 8.8.8.8<\/strong>\ntraceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets\n 1 10.96.10.33 (10.96.10.33) 50.579 ms 101.574 ms 102.216 ms\n 2 91.205.230.65 (91.205.230.65) 121.175 ms 121.171 ms 151.320 ms\n 3 cr1.lis1.edgoo.net (193.163.151.1) 102.156 ms 102.155 ms 102.150 ms\n 4 Google.AS15169.gigapix.pt (193.136.250.20) 102.145 ms 103.099 ms 103.145 ms\n 5 74.125.245.100 (74.125.245.100) 103.166 ms 74.125.245.118 (74.125.245.118) 103.156 ms 74.125.245.117 (74.125.245.117) 103.071 ms\n 6 142.250.237.83 (142.250.237.83) 120.681 ms 142.250.237.29 (142.250.237.29) 149.742 ms 142.251.55.151 (142.251.55.151) 110.302 ms\n 7 74.125.242.161 (74.125.242.161) 108.651 ms 108.170.253.241 (108.170.253.241) 108.594 ms 108.170.235.178 (108.170.235.178) 108.426 ms\n 8 74.125.242.161 (74.125.242.161) 108.450 ms 108.429 ms 142.250.239.27 (142.250.239.27) 107.505 ms\n 9 142.251.54.149 (142.251.54.149) 107.406 ms 142.251.60.115 (142.251.60.115) 108.446 ms 142.251.54.151 (142.251.54.151) 157.613 ms\n10 dns.google (8.8.8.8) 107.380 ms 89.640 ms 73.506 ms\ncaipirinha:~ # traceroute -i tun1 8.8.8.8<\/strong>\ntraceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets\n 1 10.12.34.1 (10.12.34.1) 295.583 ms 561.820 ms 625.195 ms\n 2 146.70.67.65 (146.70.67.65) 687.601 ms 793.792 ms 825.806 ms\n 3 193.27.15.178 (193.27.15.178) 1130.988 ms 1198.522 ms 1260.560 ms\n 4 37.120.220.218 (37.120.220.218) 1383.152 ms 37.120.220.230 (37.120.220.230) 825.525 ms 37.120.220.218 (37.120.220.218) 925.081 ms\n 5 103.231.152.50 (103.231.152.50) 1061.923 ms 1061.945 ms 15169.sgw.equinix.com (27.111.228.150) 993.095 ms\n 6 108.170.240.225 (108.170.240.225) 1320.654 ms 74.125.242.33 (74.125.242.33) 1164.303 ms 108.170.254.225 (108.170.254.225) 1008.590 ms\n 7 74.125.251.205 (74.125.251.205) 1009.043 ms 74.125.251.207 (74.125.251.207) 993.251 ms 142.251.49.191 (142.251.49.191) 969.879 ms\n 8 dns.google (8.8.8.8) 1001.502 ms 1065.558 ms 1073.731 ms\ncaipirinha:~ # traceroute -i tun2 8.8.8.8<\/strong>\ntraceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets\n 1 10.31.3.33 (10.31.3.33) 189.134 ms 399.914 ms 399.941 ms\n 2 * * *\n 3 * * *\n 4 * * *\n 5 198.84.50.182.static-corp.jastel.co.th (182.50.84.198) 411.679 ms 411.729 ms 411.662 ms\n 6 72.14.222.138 (72.14.222.138) 433.761 ms 74.125.48.212 (74.125.48.212) 444.509 ms 72.14.223.80 (72.14.223.80) 444.554 ms\n 7 108.170.250.17 (108.170.250.17) 647.768 ms * 108.170.249.225 (108.170.249.225) 439.883 ms\n 8 142.250.62.59 (142.250.62.59) 635.318 ms 142.251.224.15 (142.251.224.15) 417.842 ms dns.google (8.8.8.8) 600.600 ms<\/code><\/pre>\n\n\n\ncaipirinha:~ # ip route list table main<\/strong>\ndefault via 192.168.2.1 dev eth0 proto dhcp\n10.12.42.32\/27 dev tun1 proto kernel scope link src 10.12.42.41\n10.31.6.32\/27 dev tun2 proto kernel scope link src 10.31.6.38\n172.17.66.32\/27 dev tun0 proto kernel scope link src 172.17.66.34\n192.168.2.0\/24 dev eth0 proto kernel scope link src 192.168.2.3\n192.168.10.0\/24 dev tun4 proto kernel scope link src 192.168.10.1\n192.168.11.0\/24 dev tun5 proto kernel scope link src 192.168.11.1\n192.168.12.0\/24 dev tun6 proto kernel scope link src 192.168.12.1\n192.168.13.0\/24 dev tun7 proto kernel scope link src 192.168.13.1\n192.168.14.0\/24 dev wg0 proto kernel scope link src 192.168.14.1\ncaipirinha:~ # ip route list table Portugal<\/strong>\ndefault via 172.17.66.33 dev tun0\n172.17.66.32\/27 dev tun0 proto kernel scope link src 172.17.66.34\n192.168.2.0\/24 dev eth0 proto kernel scope link src 192.168.2.3\n192.168.10.0\/24 via 192.168.10.1 dev tun4\n192.168.11.0\/24 via 192.168.11.1 dev tun5\n192.168.12.0\/24 via 192.168.12.1 dev tun6\n192.168.13.0\/24 via 192.168.13.1 dev tun7\n192.168.14.0\/24 via 192.168.14.1 dev wg0\ncaipirinha:~ # ip route list table Singapur<\/strong>\ndefault via 10.12.42.33 dev tun1\n10.12.42.32\/27 dev tun1 proto kernel scope link src 10.12.42.41\n192.168.2.0\/24 dev eth0 proto kernel scope link src 192.168.2.3\n192.168.10.0\/24 via 192.168.10.1 dev tun4\n192.168.11.0\/24 via 192.168.11.1 dev tun5\n192.168.12.0\/24 via 192.168.12.1 dev tun6\n192.168.13.0\/24 via 192.168.13.1 dev tun7\n192.168.14.0\/24 via 192.168.14.1 dev wg0\ncaipirinha:~ # ip route list table Thailand<\/strong>\ndefault via 10.31.6.33 dev tun2\n10.31.6.32\/27 dev tun2 proto kernel scope link src 10.31.6.38\n192.168.2.0\/24 dev eth0 proto kernel scope link src 192.168.2.3\n192.168.10.0\/24 via 192.168.10.1 dev tun4\n192.168.11.0\/24 via 192.168.11.1 dev tun5\n192.168.12.0\/24 via 192.168.12.1 dev tun6\n192.168.13.0\/24 via 192.168.13.1 dev tun7\n192.168.14.0\/24 via 192.168.14.1 dev wg0<\/code><\/pre>\n\n\n\n\n
Routing Policies<\/h3>\n\n\n\n
Simple Policy Routing<\/h4>\n\n\n\n
ip rule add from 192.168.10.250\/32 table Portugal priority 2000\nip rule add from 192.168.10.251\/32 table Singapur priority 2000\nip rule add from 192.168.10.252\/32 table Thailand priority 2000<\/code><\/pre>\n\n\n\ncaipirinha:~ # ip rule list<\/strong>\n0: from all lookup local\n2000: from 192.168.10.250 lookup Portugal\n2000: from 192.168.10.251 lookup Singapur\n2000: from 192.168.10.252 lookup Thailand\n32766: from all lookup main\n32767: from all lookup default<\/code><\/pre>\n\n\n\n\n