| ▲ | remram 6 days ago |
| 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 top-secret@ssh-j.com -N -R ssh:22:localhost:22
socat UNIX-RECV:/tmp/foobar - | my command
# sender
my-command | ssh -J top-secret@ssh-j.com ssh socat - UNIX-SENDTO:/tmp/foobar
(originally posted on the thread for "beam": https://news.ycombinator.com/item?id=42593135) |
|
| ▲ | kragen 6 days ago | parent | next [-] |
| 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. |
| |
|
| ▲ | cakealert 6 days ago | parent | prev | next [-] |
| 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 6 days ago | parent | prev | next [-] |
| You can simplify things even more by running https://www.tarsnap.com/spiped.html It doesn't even assume ssh. |
| |
|
| ▲ | rfl890 6 days ago | parent | prev | next [-] |
| 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 5 days ago | parent [-] | | 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 5 days ago | parent | next [-] | | 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 5 days ago | parent | next [-] | | 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 5 days ago | parent | prev [-] | | Wireguard is so much simpler than those other options. IPSec is a mess. |
| |
| ▲ | BLKNSLVR 5 days ago | parent | prev [-] | | 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 5 days ago | parent | next [-] | | "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 5 days ago | parent [-] | | Out of curiosity, what references were you looking at for the setup? |
| |
| ▲ | bb88 4 days ago | parent | prev [-] | | 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 6 days ago | parent | prev | next [-] |
| Never knew about ssh-j.com. Neat. |
|
| ▲ | ndyg 4 days ago | parent | prev | next [-] |
| The approach you describe requires host to have an open ssh port you can access. quic + nat hole punching works around this. |
|
| ▲ | defraudbah 5 days ago | parent | prev | next [-] |
| you need an ssh server and an open port, different protocol etc |
|
| ▲ | michaelmcmillan 5 days ago | parent | prev [-] |
| [flagged] |
| |
| ▲ | latexr 5 days ago | parent | next [-] | | I really wish the people who feel like bringing up that comment would do a modicum of research instead of perpetuating unhelpful and wrong information. For one, that wasn’t “HN’s reaction”. Read the thread, it’s full of praise. You’re talking about one specific comment. For another, the commenter was incredibly respectful and even conceded some of the points after they got a reply. Again, read it, it’s right there in your link. That is an excellent example of how to communicate, and we would be lucky if all interactions followed that example. We should be praising it, not deriding it. | | |
| ▲ | 5 days ago | parent | next [-] | | [deleted] | |
| ▲ | acheron 5 days ago | parent | prev | next [-] | | People who still link to it are just trolling. | |
| ▲ | gherkinnn 5 days ago | parent | prev | next [-] | | And yet, that comment was the first thing that came to my mind. | |
| ▲ | michaelmcmillan 5 days ago | parent | prev [-] | | "modicum of research" Jesus christ. The reason why that comment gets brought up is because it stereotypes the HN community. He wasn't disrespectful. Calm down. |
| |
| ▲ | remram 5 days ago | parent | prev [-] | | I didn't say this project is useless, I offered a different way to do it with the tools you already have installed. Calm down. Iroh *is* cool. | | |
|