[remram]

You can do this with ssh (and socat or mkfifo):

  # receiver
  socat UNIX-RECV:/tmp/foobar - | my-command

  # sender
  my-command | ssh host socat - UNIX-SENDTO:/tmp/foobar

You can relay through any other SSH server if your target is behind a firewall or subject to NAT (for example the public service ssh-j.com). This is end-to-end encrypted (SSH inside SSH):

  # receiver
  ssh [e-mail] -N -R ssh:22:localhost:22
  socat UNIX-RECV:/tmp/foobar - | my command

  # sender
  my-command | ssh -J [e-mail] ssh socat - UNIX-SENDTO:/tmp/foobar

(originally posted on the thread for "beam": https://news.ycombinator.com/item?id=42593135)

[kragen]

This doesn't do most of what dumbpipe claims to do: it doesn't use QUIC, doesn't avoid using relays when possible, doesn't pick a relay for you, and doesn't keep your devices connected as network connections change. It also depends on you doing the ssh key management out-of-band, while dumbpipe appears to put the keys into random ASCII strings.

WireGuard is more similar.

[nightfly]

Wireguard doesn't do most of those either

[kragen]

That's true, just some.

[cakealert]

First sentence after following the link this topic is about:

  Dumb pipe punches through NATs, using on-the-fly node identifiers. It even keeps your machines connected as network conditions change.

[nine_k]

You can simplify things even more by running https://www.tarsnap.com/spiped.html

It doesn't even assume ssh.

[cyberge99]

Similar with iroh.

[rfl890]

You could also set up a wg server, have both clients connect to it and then pass data between the two IPs. There's still a central relay passing data around, NAT or no NAT.

[bb88]

After getting burnt on wireguard a few times now, I'm not keen on using it anymore.

I want less magic, not more impenetrable ip table rulesets (in linux at least).

[tetha]

Having run servers on OpenVPN, IPSec and Wireguard.. Wireguard is very mundane software.

I still get the chills at the deep and arcane configuration litanies you have to dictate over calls to get a tunnel configured. And sometimes, if you had to integrate different implementations of IPSec with each other, it just wouldn't work and eventually you'd figure out that one or two parameters on one side are just wrong.

And if you don't want to manage IPTables/nftables manually to firewall the traffic from the VPN (which is ugly, I agree), ufw or firewalld introduced forwarding rule management (route, and policies) recently.

[throitallaway]

Yes, the initial setup and troubleshooting of IPSec can be a nightmare. I've spent hours on bridges with people getting it up and running properly.

Wireguard is a damn simple breath of fresh air. There's so little to configure and go wrong. The mental model took a little bit of time click for me (every endpoint is a peer, it's not client/server) but after that it was a breeze.

[icedchai]

Wireguard is so much simpler than those other options. IPSec is a mess.

[BLKNSLVR]

Interested to know how you've been burnt by wireguard; what did it not do that you were expecting? What failures have you experienced with it that were the fault of wireguard?

I've been using it (fairly simply, mind you) and it's been pretty solid for a number of years, and was as administrative relief in comparison to OpenVPN which I'd been using before wireguard existed. Single UDP port usage makes me query your comment about impenetrable IP table rulesets.

(OpenVPN was great for it's time too, the sales reps at the company where I introduced it loved the ability to work from the road, way back early 2000's)

[jerf]

"Interested to know how you've been burnt by wireguard; what did it not do that you were expecting?"

Speaking just for myself, I expected it to be as easy to set up as Tailscale. Not to be set up in exactly the same manner as Tailscale, I understand they are not identical technologies, but I expected the difficulty to be within spitting distance of each other.

Instead I fussed with Wireguard for a few days without it ever working for even the simplest case and had Tailscale up and running in 5 minutes.

I think I recognize the pattern; it's one that has plagued Linux networking in general for decades. The internet is full of "this guy's configuration file that worked once", and then people banging on that without understanding, and the entire internet is just people banging on things they don't understand, 80% of which are for obsolete versions of obsolete features in obsolete kernels, until the search engines are so flooded with these things that if there is a perfect and beautiful guide to understanding exactly how this all works together and gives the necessary understanding to fix the problems yourself it's too buried to ever find. It also doesn't help that these networking technologies are some of the worst when it comes to error messages and diagnosis. Was I one character away from functionality, or was my entire approach fundamentally flawed and I was miles from it working? Who's to say, it all equally silently fails to work in the end.

[wadadadad]

Out of curiosity, what references were you looking at for the setup?

[bb88]

I mistyped that. It was tailscale not wireguard.

Tailscale changes your dns lookups, adds a bunch of iptables, and then unfortunately broke features without adding them to the changelog (because security I guess).

While wireguard has more of a maintenance overhead tracking public and private keys and ip addresses, it does less magic -- and I really just want things to work these days.

[actinium226]

Never knew about ssh-j.com. Neat.

[ndyg]

The approach you describe requires host to have an open ssh port you can access. quic + nat hole punching works around this.

[defraudbah]

you need an ssh server and an open port, different protocol etc