What is a VPN?

Go: open a terminal on Linux. (On macOS use netstat -rn; on Windows PowerShell use Get-NetRoute. The rest of this lab is Linux-only — it builds a throwaway network to experiment in.)

Do: ask the kernel which route it would use to reach a public address. This sends no packet — it is a lookup, not a connection:

ip route show
ip route get 1.1.1.1

You should see: your routes, then one line naming the interface and gateway that would carry the traffic. On the machine this was written on:

default via 192.168.1.1 dev enp2s0 proto static metric 100
default via 192.168.1.1 dev wlp3s0 proto dhcp src 192.168.1.104 metric 600
192.168.1.0/24 dev enp2s0 proto kernel scope link src 192.168.1.115 metric 100
192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.104 metric 600

1.1.1.1 via 192.168.1.1 dev enp2s0 src 192.168.1.115 uid 70004
    cache

Yours will differ — the gateway and interface names are whatever your network uses.

Note there are two default routes here, because this machine has both ethernet and wifi plugged in. They are not a conflict: metric 100 beats metric 600, so ethernet wins, and the final lookup confirms it chose enp2s0. Lowest metric wins — remember that, because it is how a VPN takes over in step 3.

That gateway is your router, and everything beyond it is your ISP. This single line is what a VPN changes. Not your browser, not your accounts — the route.

If not: ip: command not found means you are not on Linux, or iproute2 is missing (sudo apt install iproute2). If ip route get prints RTNETLINK answers: Network is unreachable, you have no network connection — the rest of the lab still works, because it builds its own.

Go: the same terminal.

Do: create an isolated network namespace — a private, empty network that exists only inside this command and vanishes when it exits. Nothing on your real system is touched. Paste this as one block:

unshare --user --map-root-user --net -- sh -c '
ip link add dummy0 type dummy
ip addr add 10.8.0.2/24 dev dummy0
ip link set dummy0 up
echo "=== BEFORE the VPN route ==="
ip route show
'

You should see: one route and no default. This is a machine that can talk to its own little network and nowhere else:

=== BEFORE the VPN route ===
10.8.0.0/24 dev dummy0 proto kernel scope link src 10.8.0.2

10.8.0.2 is deliberately the kind of address VPN clients hand out. You have just built the interface half of a VPN — without a VPN.

If not: unshare: unshare failed: Operation not permitted means unprivileged user namespaces are disabled on your system. On Debian/Ubuntu check with sysctl kernel.unprivileged_userns_clone. You can still read the rest; the outputs below are complete.

Go: the same terminal.

Do: run it again with one line added — the default route a VPN client installs when it connects:

unshare --user --map-root-user --net -- sh -c '
ip link add dummy0 type dummy
ip addr add 10.8.0.2/24 dev dummy0
ip link set dummy0 up
ip route add default via 10.8.0.1 dev dummy0
echo "=== AFTER adding the VPN default route ==="
ip route show
echo
echo "=== which route wins for a public address? ==="
ip route get 1.1.1.1
'

You should see: a default route appears, and the lookup for a public address now goes through it:

=== AFTER adding the VPN default route ===
default via 10.8.0.1 dev dummy0
10.8.0.0/24 dev dummy0 proto kernel scope link src 10.8.0.2

=== which route wins for a public address? ===
1.1.1.1 via 10.8.0.1 dev dummy0 src 10.8.0.2 uid 0
    cache

That is the entire mechanism. A VPN is one route with a better claim on your traffic than the old one. There is no magic and no anonymity in it — packets that used to go to your router now go to the VPN server instead, which sees exactly what your router used to see.

If not: if ip route get still names your real interface, the ip route add default line did not run — check it is inside the quoted block and that you pasted the whole thing.

Go: the same terminal.

Do: run the tunnel again, and this time also print the resolver configuration:

unshare --user --map-root-user --net -- sh -c '
ip link add dummy0 type dummy
ip addr add 10.8.0.2/24 dev dummy0
ip link set dummy0 up
ip route add default via 10.8.0.1 dev dummy0
echo "routing now goes through the tunnel:"
ip route get 1.1.1.1 | head -1
echo
echo "but the resolver config did not change with it:"
grep -v "^#" /etc/resolv.conf | grep -v "^$" | head -3
'

You should see: the route changed and the DNS settings did not:

routing now goes through the tunnel:
1.1.1.1 via 10.8.0.1 dev dummy0 src 10.8.0.2 uid 0

but the resolver config did not change with it:
nameserver 127.0.0.53
options edns0 trust-ad
search .

🔴 This is a DNS leak, in two lines. Routing and name resolution are separate systems. If a VPN moves your traffic but leaves your resolver pointing at your ISP, then your ISP still receives the name of every site you visit — before any encrypted traffic is sent. The connection is private; the question is not. A VPN that does not also replace your DNS has hidden almost nothing worth hiding.

Your nameserver line will differ. 127.0.0.53 is a local stub that forwards elsewhere — run resolvectl status to see where it actually goes.

If not: if /etc/resolv.conf is missing, your system uses a different resolver stack; try resolvectl status. The point holds either way: nothing you did to the routing table changed it.

Go: the same terminal.

Do: add a second network, as a real machine has for its local LAN, then ask which route a local address uses:

unshare --user --map-root-user --net -- sh -c '
ip link add dummy0 type dummy
ip addr add 10.8.0.2/24 dev dummy0
ip link set dummy0 up
ip route add default via 10.8.0.1 dev dummy0
ip link add lan0 type dummy
ip addr add 192.168.50.2/24 dev lan0
ip link set lan0 up
echo "public address -> tunnel:"
ip route get 1.1.1.1 | head -1
echo "local address  -> NOT the tunnel:"
ip route get 192.168.50.10 | head -1
'

You should see: the public address goes through the tunnel and the local one does not:

public address -> tunnel:
1.1.1.1 via 10.8.0.1 dev dummy0 src 10.8.0.2 uid 0
local address  -> NOT the tunnel:
192.168.50.10 dev lan0 src 192.168.50.2 uid 0

A more specific route always beats a default one, whatever the VPN wants. That is why your printer still works with the VPN on — and it is also "split tunnelling", which some VPN apps offer as a feature. It is not a feature the VPN adds; it is how routing already works. Anything matching a more specific route never enters the tunnel at all.

If not: if both lines name dummy0, the lan0 interface did not come up — check the ip link set lan0 up line is present.