It's very common to use existing VPN protocols for proxying - Google "VPN" and you'll find many commercial services. And the WireGuard white paper mentions pas

It's very common to use existing VPN protocols for proxying - Google "VPN" and you'll find many commercial services. And the WireGuard white paper mentions passing all traffic to a single peer as a possible configuration, so I think it should be usable for it as well, modulo OS compatibility. Which is good, because existing VPN software suffers from the same configuration and security headaches whether it's used for proxying or corporate networks, and non-VPN proxies are an inadequate solution. Web proxies are suboptimal because they only work with web traffic, or even if you use HTTP CONNECT, only TCP. SOCKS is mildly better at a protocol level, with SOCKS5 supporting both TCP and UDP, but still suboptimal if the server end is able to give each client its own IP address (not so common with IPv4 but easy with IPv6), due to the existence of protocols other than TCP and UDP. More importantly in practice, SOCKS clients are typically implemented in userland rather than the kernel, so each individual application needs to be configured to use the tunnel. There is software that lets you use any program with SOCKS by hooking socket API calls, but that's essentially a hack, and has many practical issues. Much nicer to just have the tunnel as a network interface like any other, and let the kernel's network stack work as it was designed - which is usually done with VPN software. VPN also lets one host transparently handle proxying for another, e.g. a router for a home network, or the host in the VM setup I mentioned in my original post.