VPN over SSH? The Socks Proxy
blog.gwlab.page
blog.gwlab.page
So I've implemented own client which decouples connections from each other: https://github.com/Snawoot/rsp#performance
Basicly, you get working proxy with speed almost as native connection as soon as you have SSH access somewhere.
Besides that you have to keep pool of steady established SSH sessions in order to start new connection forwarding inside separate SSH session as soon as incoming SOCKS requests coming.
Plain SSH client is neither able to maintain multiple SSH carrier sessions nor keep reserve pool of steady underlying connections.
The multiplexing you can disable on the server-side is a different multiplexing, but also another useful ssh feature.
If you have a workload that involves sort of firing off many commands over ssh one after the other (i.e next command is based on the output of the previous), then you can make them all grab a prenegotiated ssh connection to speed it up.
Basically, I almost always have
ControlPath ~/.ssh/control-%r@%h:%p
ControlPersist 1m
in my ssh configs to take advantage of this in my Makefiles which need to ssh across for various reasons. Ssh commands to a "central location" are great for initializing env vars with AWS keys, instead of encoding them in shell scripts - easiest way to prove your identity is to prove you have your private key.[1] https://www.multipath-tcp.org
SSH Tunneling works with zero config so I use it as well, and rsp solves one of my major gripes with ssh tunnelling.
The only thing I could wish for would be an auto reconnect feature, been thinking about wrapping it in a shell loop to handle it but it requires sudo so I’ve been putting it of, I don’t like having a long running script with sudo.
I've switched all my devices to it and frankly, it's wonderful. Private VPN, tunnel, VLAN, auth, sharing, all-in-one.
One thing I can't get over is that it's pricing is "per user". That makes sense our user-oriented VPNs (dev workstations, home machines, and phones), but doesn't feel like it's oriented towards server use. My end use case is probably 80% securing server connectivity across sites.
Alternatives I've looked at include: ZeroTier, Slack Nebula, OpenVPN Cloud, and PriTunl.
ATM, I'm using ZeroTier for my home use and quite happy with it. I had hopes of being able to deploy something for work as well, which is why I leaned towards ZeroTier. For home use, TailScale's pricing wasn't a concern.
I like ZeroTier because: It was dead simple to set up, the web management UI is good, the "public" networks seemed like they might be nice for CI/CD servers to connect into some infrastructure to deploy (though that didn't work out because CI/CD docker didn't have flags allowing ZeroTier to work, but I did just get SSH over userspace ZeroTier working). It's super easy to set up in all the environments I've looked at.
Then, ZeroTier does have a free tier, with open-source clients for every platform I care about. Yes, they are limited to version 1.x, but maintained nevertheless.
If you're a larger business, the pricing seems... fine? I don't know what their enterprising pricing is like, but the next-highest tier appears to cap at $10k/yr, which seems like a trivial cost to anyone operating at that scale.
Consider also that you don't need to run tailscale on every host -- though you could. Depending on your architecture, a single gateway instance in each VPC could be sufficient. In other words, I could probably scale the two non-enterprise tiers very, very far, at least until you had close to ~500 employees, in which case you probably want to strike a deal for custom support and SAML SSO anyways.
Alternatively, at $LAST_JOB we just ran our own OpenVPN servers and in-house beyondcorp authwalls. There was honestly not a lot of complexity in there. We had <3000 employees.
> That makes sense our user-oriented VPNs (dev workstations, home machines, and phones), but doesn't feel like it's oriented towards server use.
Just to be clear, you don't pay per-server. Just for logins.
> My end use case is probably 80% securing server connectivity across sites.
100% is not by any means an unachievable goal in, say, a quarter or two. Any reason why you don't want that 20% tail?
For example, I can use my desktop at home as an exit node for my phone, so I can configure my network hardware (router, switch, AP) from my phone, from anywhere.
I often travel for work and was having an annoying time with Verizon’s hotspot throttling. 4G LTE should be able to run at ~5Mbps but devices connected to the hotspot get throttled down to an insufferable 400Kbps. This was super annoying and felt like an arbitrary action on Verizon’s part. I found out I could run a SOCKs proxy on my iPhone via a Pythonista script and tunnel hotspot connections through it to fool Verizon’s throttling systems. Worked great, even though the UX of launching a Pythonista script as a service and pointing clients to it was slightly clunky.
# Temporary Firefox session commands.
alias socks-proxy="ssh -D 50000 -N me@some-server"
alias firefox-proxy="firefox -P \"Proxy\""
Then I open two terminals and run `socks-proxy` in the first and `firefox-proxy` in the second. The Firefox profile "Proxy" has to be configured to use the localhost:50000 SOCKS proxy on first run.While we're here, I also have an alias that generates a random profile directory for Firefox in a temporary directory, to use websites that detect ad blockers:
alias firefox-throwaway="firefox -no-remote -profile $(mktemp -d)"I don't use openvpn anymore for work, and instead make do with foxyproxy+ssh. I should probably try to hop from a server with wireguard to help with roaming.
ssh -D8081 localhost
ssh -R8081:localhost:8081 some.remote.server
http_proxy=socks5h://localhost:8081 git clone git@git.corp:foo/bar.git-w local_tun[:remote_tun]
Requests tunnel device forwarding with the specified tun(4) devices between the client (local_tun) and the server (remote_tun).
The devices may be specified by numerical ID or the keyword “any”, which uses the next available tunnel device. If remote_tun is not specified, it defaults to “any”. See also the Tunnel and TunnelDevice directives in ssh_config(5).
If the Tunnel directive is unset, it will be set to the default tunnel mode, which is “point-to-point”. If a different Tunnel forwarding mode it desired, then it should be specified before -w
So really neither term is good. I don't know of a better one, though.
This was a common technique in my halls of residence as an undergraduate -- tunnel OpenVPN over SSH, plug in an secondary Ethernet card to your computer, then bridge the virtual adapter and the new Ethernet adapter. You could then plug in your Xbox/PlayStation into the ethernet adapter and bypass the rather strict filtering that was in place.
One of the newest tricks I haven't written down just yet is tunnelling a TCP port of a different machine than what you connect to over SSH. This is good for connecting to that Windows XP machine you have no control over (since it probably controls some industrial machine) but that you have to provide access to to certain people e.g. for maintenance of the industrial machine. This works reliably for e.g. tunnelling VNC, RDP and even Samba/CIFS for the occasional file transfer (e.g. a new executable file of some industrial control software). If you have no means to do a proper VPN, SSH is installed pretty much everywhere on current OSes (even current Windows 10 ships with an SSH client).
I have an autossh session on my workstation along with the ControlPath trick mentioned elsewhere that meets most of my networking needs when working from home. It's not really practical for high bandwidth applications, but for text based interactoins, ssh -D is wonderful.
https://rumpelsepp.org/blog/ssh-through-websocket/
Further, with socat IP traffic can easily be tunneled (trough websocket :D):
So, yes, VM/router solution will work for TCP connections.
Also there are wrappers which can intercept connect calls to libc from applications on Linux (which is useful if you need to redirect only one application which doesn't support SOCKS proxies): https://linux.die.net/man/8/tsocks
Not nearly everything else, but alot of things use PROXY/HTTP_PROXY for HTTP things which works here too.
I wrote a small gui application for mac/linux to start tunnels and control them via notification area (menu in macos) icon.
Host papa
HostName 192.160.0.1 <-- LAN IP address
User alex
ProxyJump papa_pi
Host papa_pi
HostName 1.2.3.4 <-- public IP address
User piSidenote: does anyone know how Telegram bypasses the WiFi redirect blocks? Was considering writing a Reddit or HTTP-over-Telegram bot but it seems easier to just figure out how they are avoiding blocks.
net result: with tsocks bash or tsocks command, you can control which processes or shells can see the vpn remotes.
tsocks + ssh -D has been my preferred vpn solution for many, many years.
badvpn-tun2socks works with everything I wanted, but it's not as easy to control the processes that go through the VPN. It should be possible with network namespaces or tagging packets with cgroups but it's a pain to get it all set up.
(Also Go programs are famous for bypassing libc.)
i mean, what are they doing? implementing the syscall gate by hand. why would anybody do that?
OpenBSD routing domains make this really easy.
Host myhouse.net
LocalForward 5902 foo:5900
LocalForward 3393 bar:3389
DynamicForward 8083
Host baz
ProxyCommand=nc -X 5 -x localhost:8083 %h %pWith Wireguard I'd have to create routes to route some some destination IPs over the wg interface, which not only needs management to keep up-to-date with DNS changes but also does not have any way to behave differently for routed applications vs unrouted applications.
FoxyProxy? I love that one.
https://addons.mozilla.org/en-US/firefox/addon/foxyproxy-sta...
Thanks in advance.
SOCKS is a very outdated protocol, that's why I wrote an in-depth article about it. The TLDR is kinda like this:
- don't use socks proxy passwords, they're plaintext or work only with pre-shadow BSD 0.x.
- IPv6 doesn't work. TOR socks proxy supports it but no Browser does.
- DNS isn't tunneled (only enforced DNS over TLS is due to http upgrade nature), and TTL of 0 (which is pretty much always everywhere) leads to the ISP / spy agencies being able to correlate your internet connection regardless.
- Most SOCKS implementation if not all that I've seen don't support "bind" correctly and neither work with UDP connection handshakes.
- therefore SOCKS in practice is TCP only, http upgrades will always circumvent a socks proxy because it cannot handle those connections.
- instead of a socks proxy I'd recommend to use a simple https proxy that uses a CONNECT header which has the identical features as a socks proxy in practice, but could be implemented in a way that it is compatible with http3/quic upgrades and websocket upgrades.
Source: The "RFCs" (which are two specs of an already proprietary implemented protocol at the time) and my Implementer's Guide to SOCKS that I posted on HN a while ago and didn't get any traction [1]
[1] https://cookie.engineer/weblog/articles/implementers-guide-t...
Firefox 87.0 on GNU/Linux with an OpenSSH 7.9 SOCKS proxy (-D) does make IPv6 connections from the correct destination address. Is there any other sense in which it does not work? One thing I do is bind on ::1 locally instead of 127.0.0.1
When using SOCKS over SSH and running the SSH client on your local machine, DNS resolution will always happen on you local machine as well (except when using DoH of course)!
Edit: see below