Instruction 03-vpn-binding-kill-switches-and-leak: Reading

VPN privacy is a path-enforcement problem, not merely a tunnel-status problem. An application can report that it is bound to a VPN address while another subsystem still uses the ordinary uplink. Conversely, a host default route can point through a VPN while a policy-routing rule, container namespace, explicit proxy, IPv6 route, or privileged application selects another path. Treat application binding, route selection, and packet filtering as separate controls. Binding narrows where a socket may originate or listen. Routing determines the candidate path. A host packet filter enforces whether the selected path is permitted. Defense in depth uses all three where practical, but the packet filter is normally the final fail-closed control.

A useful kill-switch design begins with an explicit traffic inventory. Identify the protected process or service identity, the tunnel interface, the VPN endpoint address and port, DNS resolvers, local management networks, and any intentionally reachable LAN services. Start from deny-by-default for protected egress, then add narrow allowances. The VPN control-plane exception must normally use the physical uplink so the tunnel can be created. That exception should be limited to the actual endpoint, transport, and port rather than allowing arbitrary Internet traffic. Protected data traffic is then allowed only through the tunnel. If the endpoint is named rather than addressed directly, bootstrap DNS becomes part of the threat model and must be handled deliberately.

Binding to a VPN address is helpful but incomplete. If software cannot create a socket after the address disappears, it may fail safely; however, implementations differ, long-lived sockets may behave differently, and a restarted application may choose another address unless policy prevents it. Binding only IPv4 does not constrain IPv6. Binding a service listener also answers an inbound-exposure question, which is different from controlling outbound connections. Interface-based binding can be stronger on supported systems, but it may require privileges and still should not replace egress enforcement.

Verification must test both success and failure. While the VPN is healthy, inspect the selected route, local source address, resolver path, IPv4 behavior, IPv6 behavior, and application-specific proxy settings. Then remove the modeled VPN path and confirm that protected traffic stops rather than moving to the uplink. Repeat after application restart, VPN restart, address changes, and host reboot. Containers and virtual machines need separate inspection because they may have their own routes and packet-filter traversal. Browser WebRTC, encrypted DNS, and extension-managed proxies can also behave differently from ordinary command-line traffic. A public IP-check page is only one observation; it does not prove that DNS, IPv6, alternate processes, or failure transitions are protected. The lab below is deliberately a local policy simulation. It teaches test design without changing routes, interfaces, DNS, or host enforcement, and its report must not be represented as proof that the real host is leak-free.