A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
Cool idea. Just be aware, that there are a lot of shady people out there. I'm not sure I would publicly host services, which rely on tight security (like Vaultwarden). They will come and they will probe your system and it's security!
You might also want to remove Dockge from Uptime Kuma, no need to broadcast that publicly.
Yeah seeing all the attack vectors opened here freaks me out
Thank you for pointing these things out! I've removed Dockge from Uptime Kuma.
Let me know if you need any help with that. I'm still a beginner, but have used the last few months to learn about cyber security. It can be a daunting subject, but if you get the basics right, you're probably good. I also hosted without a care for years and was never hacked, but it can/will happen. Here are some pointers!
Get or use a firewall. Iptables, UFW and such are probably good enough. I myself use OPNsense. It can be integrated with Crowdsec, a popular intrusion prevention system. This can be quite a rabbit whole. In the end, you should be able to control who goes where in your network.
Restrict ssh access or don't allow it at all via internet. Close port 22 and use a VPN, if needed. Don't allow root access via Ssh, use sudo. Use keys and passphrase login for best security.
Update your stuff regularly. Weekly or bi-weekly, if you can.
Use two factor authentication, where possible. It can be a bit annoying, but improves things dramatically. Long passwords help to, I use random-word-other-word combinations.
If you haven't, think of a backup strategy. 3 redundant copys on 2 media, one off site.
I wrote a small blog about bypassing CGNAT using TLS-passthrough. Cloudflare uses TLS-termination, which means they can see all the data being passed through, which defeats the purpose of privacy.
Hey, thank you for your blog post. I'm definitely reconsidering my choices with Cloudflare tunnels. I will take a look at the VPS setup. Privacy is something that I really care about, so this would be pretty useful. I would definitely be ready to pay 3.29€ per month for the privacy aspects of this setup.
Thanks for the nice writeup. Can you explain why you have these rules.
PostUp = iptables -t nat -A PREROUTING -p tcp -i eth0 '!' --dport 22 -j DNAT --to-destination 10.0.0.2; iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source SERVER-IP PostUp = iptables -t nat -A PREROUTING -p udp -i eth0 '!' --dport 55107 -j DNAT --to-destination 10.0.0.2;
What happens if you remove it ?
I am not sure, actually. Look at the sources, and you'll find the original GitHub link from where I took it. I am not very well versed with iptables.
I am behind CGNAT and I have been trying to set up a WireGuard mesh network to connect my local devices, such as a Raspberry Pi and Proxmox server, as well as my mobile devices, using a VPS as the central point. The goal is to expose locally running applications to the internet without relying on Cloudflare, as they do not allow video streaming and remote access to my local devices. I have looked at many tutorials on this topic, but they often left me confused due to the varying iptables rules and configurations. Some tutorials include specific device names like eth0 in the iptables rules, while others use variables like %i. Additionally, some examples have special rules for SSH access like this one. Apart from that, I am unsure about what additional steps I need to take when I want to run one of the peers as an internet gateway. Despite the confusion, I managed to achieve the basic mesh network setup without implementing any iptables rules for PostUp/Down. Each device in the network receives an IP address within the WireGuard subnet (10.0.0.x) and can ping one another. However, I believe that the iptables rules mentioned in the tutorials would allow accessing other subnets, such as my local LAN, through the WireGuard VPN. I am still uncertain about the exact mechanism behind how these rules work in that context and how to properly configure them for my specific use case, especially considering the CGNAT situation
If you are using the exact rules mentioned in my post, only the ports of your machine will be forwarded, not your entire local network. If you want to forward ports of more than one machine, look at the github link in the sources, it contains a detailed documentation of how to achieve that. Since, I do not know a lot about iptables, I may not be the best person to guide you, in this case. However, feel free to DM me, I'll might be able to help.
The problem with such a situation is that you have no idea of the origin IP address, as all the requests look like they are coming from your VPS. Did you find a way to restore origin IP in your logs?
Yes, it is fairly easy. You just have to forward the http headers. I am using HAProxy, and you can look at my configuration file in the blog. If you're using something like Nginx Proxy, look up how to forward http heards. Some applications, like Nextcloud, require extra steps, but they also provide their own documentation.
Ok for http trafic, but what about SMTP?
All ports are forwarded. If your SMTP is running on, say, port 993, on your local machine, your-VPS-ip:993 will be your SMTP.
Sorry for the late answer, but will your SMTP logs show the original IP or the VPS'?
Not sure. Will have to try it out.
You can do https Cloudflare <-> node
I am not sure what you mean.
The issue is, when using Cloudflare, they will terminate your TLS, then encrypt the data again with their own certificate, which is send to the visitor. When visitor interacts, their data is decrypted on Cloudflare's servers, which they encrypt again eith our original certificate and send it back to us.
Sure, hackers or sniffers might not be able to look at the sensitive data, but Cloudflare can. But do they, or do they not, is upto you, if you trust them or not.
Oh I understand.
I was referring to the "strict" tls option which enforces that Cloudflare connect to your node via tls instead of http.
Pretty neat! Or should I say. Its really awesome 😎 thanks!
Thank you! I appreciate the feedback!
Awesome :D But providing a speed test on a 10 Mbit line is IMO pretty pointless.
I know, I just added the speed test because I can. If people want to use it, they can.
Is it so quick because Cloudflare is acting as a CDN? I tried a SearXNG search and it was just as fast as my local browser??? What on earth is this sorcery
It might also be because some mini PCs nowadays are fast AF.
If they’ve got the orange cloud enabled, then Cloudflare will cache, minify, and distribute the static contents to servers closer to your ISP. The result would be that the initial page load appears faster. Dynamic content (such as actually performing a search) would require the server to actually perform actions, and would depend on wider range of factors.
A lot of words to say, yes, if you have static content to serve, Cloudflare is one of the cheapest way to make them go vroom vroom.
Well yes, but try out for yourself: the chap's SearXNG instance is blazing fast. This is obviously dynamic content
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
| Fewer Letters | More Letters |
|---|---|
| CGNAT | Carrier-Grade NAT |
| DNS | Domain Name Service/System |
| IP | Internet Protocol |
| NAT | Network Address Translation |
| SMTP | Simple Mail Transfer Protocol |
| SSH | Secure Shell for remote terminal access |
| SSL | Secure Sockets Layer, for transparent encryption |
| TLS | Transport Layer Security, supersedes SSL |
| VPN | Virtual Private Network |
| VPS | Virtual Private Server (opposed to shared hosting) |
8 acronyms in this thread; the most compressed thread commented on today has 12 acronyms.
[Thread #627 for this sub, first seen 25th Mar 2024, 14:45] [FAQ] [Full list] [Contact] [Source code]
I have rented a cheap vps and use ssh encrypted port fotwarding to it instead of cloudflare. Its an option in alternative.
I prefer owning my server hardware than renting a VPS. I completely forgot that I couldn't port forward in my home network, so Cloudflare was my last-minute solution to that problem.
I think parent is hosting on their own physical hardware, just using a VPS for a public IP. I do the same (I use WireGuard instead, but similar idea). The VPS is doing the same thing as Cloud flare in your setup. I'm a proponent of this setup because the only reliance is on a totally generic VPS, of which there are many providers.
Yes exactly, you can switch as fast as your DNS entry gets updated and you have zero dependency to a specific provider.
No, I mean, do host on your own hardware then rent a vps and use it as public IP by ssh-tunneling and forward ports 80/443 back to your own hardware.
The idea is: https://wiki.gardiol.org/doku.php?id=selfhost:architecture
Are you able to tunnel ports other than 80 and 443 through Cloudflare?
If you have a domain and connected it to Cloudflare, you can assign tunnels to specific subdomains. For example, I have Invidious running locally on my server with port 3000. I connected the server with a Cloudflare tunnel and pointed invidious.reallyaweso.me to http://192.168.0.17:3000, which is my local IP.
Ah right. What I really meant to ask was if it can do protocols other than http.
Which I don't think it can...
You can, but I found it a bit laggy. It basically wraps your tcp stream over https, so I think the extra overhead was what was slowing it down.
Very cool! Thanks, saw some things I didn't know about.
Thanks! I'm glad that I could show you some other services!