I wonder why a VPN is the default solution (with all complications it ensues, some of which you've listed), when a simple SSH tunnel to any server in a sane location does just fine. `ssh server -D12345`, point your applications to socks5 at localhost:12345, and it's done. It's dead simple to only allow/deny those sites that you (don't) need to go through another server, and the traffic is encrypted (and optionally compressed), and looks just like another SSH connection.
I've used many other solutions (including WireGuard, etc.) on and off, but always come back to SSH.
It's easier to detect that someone is using a SOCKS tunnel – from memory, one way it might be exposed is if the packet TTL is incongruous [1] as I don't think SOCKS rewrites those.
At the height of the pandemic I travelled to Denmark for work (on a clinical trial) and had a UK negative covid test to report to the UK government that I hadn't got around to – whose website geo-blocks people reporting covid tests from outside a UK IP address (even if, e.g. you'd just left it and wanted to report a negative test taken the day before). A SOCKS proxy was detected and I got a "we cannot verify you are in the UK" message. A wireguard VPN worked fine.
That's the problem. Not all of them will implement tunneling their own traffic through SOCKS, and there's still other things like DNS that you might also want to go through the tunnel, but can't easily do so. A VPN sits at a lower layer, just looking like a regular network connection, so applications don't need to be aware.
Well, yeah, that's the problem (or the main advantage depending on your viewpoint). The post I was replying to mentioned how painful it is to avoid routing through VPN where it's not needed (although it's pretty easy to do on Linux with network namespaces, and IIRC policy routing, which I've never tried).
I just want to point out the simplest solution which for some reason doesn't seem to be very popular, although it covers most users' use-cases better than a VPN connection does (IMHO).
Don't know about other browsers, but Firefox is able to send DNS requests through socks, whether you're using DNS-over-HTTPS or not.
> SSH is very simple and there’s almost nothing a SSH tunnel can’t do.
You cannot disguise your SSH traffic mimicking HTTPS traffic which help you to bypass DPI solutions.. so its easy to block/filter/log your traffic or even pinpoint you in an adverse environment.
Please expand. How can an Apache server, for instance, know if I’m accessing through and SSH tunnel. And how would that be different on a Wireguard VPN?
Why apache would care? We are talking about DPI solutions, aka deep packet inspection. They are normally deployed inline, and SSH tunnels are so often blocked, that in some solutions you have it one click away from you https://www.sonicwall.com/support/knowledge-base/how-to-bloc.... Other solutions try to make the traffic similar with Apache + Firefox to make it harder to be detectable and blocked by DPI solutions..
there are many implementations of DPI out there, each one with your own set of rules and heuristics... this discussion[1] talks about it, but the short answer is: it depends
If the only thing a web server could do is differentiate tunnel from direct IP connection with or without firewall/NAT, which are ubiquitous, it's an interesting effort, but a tour de force with little gain IMO.
SSH tunneling is encapsulating byte streams in TCP, not TCP (which means "packets with sequence numbers, acknowledgements, and retransmissions") in TCP, and therefore doesn't suffer.
Well the byte stream includes everything you throw in (TCP/UDP/L2), so while the tunnel will not suffer from any signaling issues in the payload flow, the opposite is not true - the internal traffic is affected by any TCP problems on the SSH tunnel so a short blip on the tunnel can cause a cascade of blips depending on whats in there.
I've used many other solutions (including WireGuard, etc.) on and off, but always come back to SSH.