by willmorrison on 4/9/22, 6:38 PM with 76 comments
by apitman on 4/9/22, 11:03 PM
https://github.com/anderspitman/awesome-tunneling
It's interesting to me how many times this particular wheel has been reinvented. That said, it's a great exercise and one I highly recommend if you want to learn a bit more about networking.
I like the minimalism of this implementation.
by Klasiaster on 4/10/22, 1:09 PM
sudo apt install miniupnpc
upnpc -r 22 57922 TCP # forward 57922 on public address to this client's port 22
Together with something like https://dynv6.com/ you even get a subdomain that you can point to the public address: curl "https://ipv4.dynv6.com/api/update?ipv4=auto&token=$TOKEN&zone=$ZONE.dynv6.net"
curl "https://ipv6.dynv6.com/api/update?ipv6=auto&token=$TOKEN&zone=$ZONE.dynv6.net"
by PeterWhittaker on 4/9/22, 8:44 PM
Yes, setting this up with SSH is (mildly) more complex, but given the inherent security, one wonders why one would opt for simplicity.
by ekzhang on 4/9/22, 8:58 PM
Happy to answer any questions, though the README has most of the technical details already. Quick FAQ:
--
Q: What inspired this?
A: I wanted to make a really simple CLI tool for forwarding local TCP ports. No TLS termination or any other features. Localtunnel is unmaintained, slow, and requires Node.js. Ngrok v2 is proprietary, while Ngrok v1 is unmaintained, leaks memory, and is complicated to set up (requires wildcard certificates...). Why can't we just write a simple, minimal binary that does this? And focus on user experience (good error messages, clean code, systems correctness). That's the goal.
--
Q: Why Rust?
A: Because Rust gives you a lot of things: tracking lifetimes of variables statically, very fast code execution, data-race freedom guaranteed by the compiler, documentation, unit testing, simple binary distribution in the form of `cargo install`, and a strong focus on correctness. Tokio is also a _really_ great asynchronous runtime for writing network services.
--
Q: Why release a public server?
A: Mostly because I want it to be as easy as possible to try and access Bore, even if you don't have access or the technical means to run an instance in the cloud yourself. That said, "bore.pub" is not hard-coded anywhere inside the source code. The CLI usage examples explicitly pass in a mandatory `--to bore.pub` option to make sure that this software is not tied to any particular server instance. And an explicit goal of bore is to be easy to self-host, just run a single command (it's `bore server`) and you're all set.
--
Q: How much does this cost you?
A: I'm running the public server (bore.pub) on a $6/mo DigitalOcean droplet right now, the smallest size on shared vCPU. I just checked my dashboard, and it's only using 2% CPU at the moment. Will upgrade if I need to, but I don't expect the public server to incur significant fees unless bore gets _really_ popular.
--
Q: Is there potential for abuse?
A: I don't believe there's much potential for abuse here, in terms of distributing illegal content. If you wanted to do that, you could just set up port forwarding on your router and have people connect directly. Also, bore.pub doesn't guarantee you a stable TCP port to share with people; it's intended as a developer tool. So the risk seems fairly low.
--
Q: How can I help with this?
A: You can star the repository, share it with your friends, try using bore, and give any feedback on the issues page. Any help with packaging in software repositories or CI/CD binary builds would always be appreciated as well! Right now the only installation option is from source, using `cargo install bore-cli`. Finally, feel free to follow me on Twitter (https://twitter.com/ekzhang1) where I've been posting some updates on this work.
--
Q: How can I learn more?
A: Read the source code — it's literally 400 lines of Rust, super short if you have an hour or so this afternoon. :)
by heinrichhartman on 4/9/22, 8:26 PM
I hope this service will continue to be available, however it looks to me as if this service is very easily abused (e.g. by spreading illegal content). But even if it just gets popular there are bandwidth costs which may run high quickly, if you have a few 100 heavy users.
If the author is here:
- How much of a concern is this for you?
- Do you have plans to offset the bandwidth fees?
- The backend is a single host, right? When would you need to scale this?
by bnert on 4/9/22, 8:14 PM
by lapser on 4/9/22, 11:06 PM
Also, seems like it'd be trivial to add TLS termination. I've used ngrok for it's TLS termination when developing GH Webhook listeners.
by scns on 4/10/22, 10:12 AM
by joshbaptiste on 4/10/22, 3:46 PM
by hsbauauvhabzb on 4/9/22, 10:13 PM
Legitimately, what benefits does this have?
by pabs3 on 4/10/22, 3:39 AM
by anonu on 4/10/22, 1:31 AM
by skanga on 4/11/22, 4:09 AM
by polio on 4/9/22, 9:13 PM
by lmc on 4/9/22, 10:20 PM
Port numbers are limited to 65535. Isn't this un-scalable and a massive security risk?