[Linux] system wide traffic routing with exceptions #267
Description
The goal is to get system wide routing working correctly, so that the entry node will bypass it's own VPN session. See:
Tasks
- implement routing as shown in the picture above
- base your changes against
este/fallbackbranch and keep them contained in this module: https://github.com/gnosis/gnosis_vpn-client/blob/este/fallback/gnosis_vpn-root/src/routing/dynamic/linux.rs - document any overall shortcomings/optimization unrelated to the routing setup, so we can fix them later
- use network namespaces or kernel cgroups to achieve the required selective routing
- avoid leveraging specific firewalls
Development setup
- create a user
gnosisvpnthat is part of a newly created groupgnosisvpn - have this baseline config ready:
# file gvpn-staging.toml
version = 4
###
## destinations section - configure available target destinations
[destinations.0x7220CfE91F369bfE79F883c2891e97407D7a4D48]
meta = { location = "USA" }
path = { intermediates = [ "0xFE3AF421afB84EED445c2B8f1892E3984D3e41eA" ] }
[destinations.0xcD9D0E23cD999dFC0D1400D837F8e612DbbbDFAA]
meta = { location = "UK" }
path = { intermediates = [ "0xc00B7d90463394eC29a080393fF09A2ED82a0F86" ] }
[destinations.0x12b78461da59e8317c61bd249ea0dea2aa9527de]
meta = { location = "Brazil" }
path = { intermediates = [ "0x6250eb481b40f4609d32de35bd9b827212713f35" ] }- build the binaries in release mode on
este/workerbranch - copy the worker binary into that users home folder and adjust ownership before running an updated binary:
# from within repository after release build
sudo cp ./target/release/gnosis_vpn-worker /home/gnosisvpn/gnosis_vpn-worker
sudo chown gnosisvpn:gnosisvpn /home/gnosisvpn/gnosis_vpn-worker
sudo RUST_LOG="debug" ./target/release/gnosis_vpn-root -c gvpn-staging.toml --hopr-rpc-provider https://rpc-provider.hoprnet.org --hopr-network rotsee --worker-binary /home/gnosisvpn/gnosis_vpn-worker- keep a watch running on the status alongside the logs for easier insights:
watch ./target/release/gnosis_vpn-ctl status
At this point you can connect via gnosis_vpn-ctl, usually USA exit will work.
Testing the connection with http proxy routing
- connect to a working destination:
./target/release/gnosis_vpn-ctl connect 0x7220cfe91f369bfe79f883c2891e97407d7a4d48 - curl via proxy:
curl --proxy http://10.128.0.1:3128 https://example.com - ping interface:
ping 10.128.0.1
Testing the connection with full system wide routing
- verify that the wireguard session is set up correctly:
# ping wg server from your normal user
# should give elevated round trip times as it uses the session
ping 10.128.0.1- verify that the worker user bypasses the session
# ping outside from your worker user
# should give normal and fast round trip times as it bypasses the session
sudo -u gnosisvpn ping 1.1.1.1- verify that the normal users traffic uses the wireguard session
# ping outside from your normal user
# should give elevated round trip times as it uses the session
ping 1.1.1.1
# curl with longer response time
time curl https://example.com