The article makes sense. I think it’s good to note that if the services you’re running makes outbound requests (e.g. a Matrix homeserver), you could also tunnel outbound traffic to the same VPS as your inbound, so your residential IPs won’t be leaked.
I’ve written about a similar setup, but for Tailscale nodes, here.
Headscale is best used with the CLI. If you host a UI it’s only for convenience, and you need to keep track of the Headscale version it supports. The Discord guild can help you debug things.
Can Tailscale be logged in from multiple credentials? If so try having a few of them instead of one for redundancy. Also maybe look into hosting a reliable and simple IDP like Kanidm for Tailscale.
Does Synapse have an option to create a one-time registration token with short expiry? I’d do that if my community is small enough.
Hi, the other comments have said it pretty well, but you can also check out my previous post for some of the other comparisons.
I went from Pihole > Adguard Home > Technitium, and stuck with the last one because it supports clustering (syncing data between nodes) and recursion (so no need for external Unbound). The interface is a bit complex and there is no dedicated documentation, but should be intuitive enough as you learn.
If you want something simpler, I think Adguard Home is a better choice than Pihole as it natively supports encrypted DNS protocol, and has a sleeker UI. But other than that Technitium is nice as you expand your homelab eventually.
Did you try OpenVFS ever outside of Opencloud? Is that project even published yet?
I’m not sure why this Lemmy post was titled “RCE in Forgejo” when it just links to a yet-to-be-proven exploit, and the post itself is just a boast on not disclosing the vuln and telling maintainers to duplicate efforts. Feels rather disingenuous.
Other than that the idea of treating Forgejo as some sort of vendor to pull a carrot on is kind of a stupid joke. The security policy, even if lengthy, provides basis for collaboration. And these behaviors, although coming out the volunteer effort of a security researcher, does not exempt one from looking like an ass.
Also see the Mastodon thread for more.
It’s quite fine, but not as feature complete as the proprietary control plane. My main issue is that it doesn’t support tailnet lock yet, and it’ll take a while before they’ll implement grants instead of the old ACL system
Yes, the app is the only “Android VPN”. The exit node is deployed on another network, but there should be no problem deploying it locally.
My phone would be attempting to make direct WireGuard connections to my other Tailscale nodes (be it the server, the exit node, or any other device), so it’ll prefer local connections. When it can’t (e.g. in a different and restrictive network), it will relay these traffic through DERP servers. Tailscale automate these processes very well, so no port forwarding is needed.
Note that to establish these encrypted direct tunnels, Tailscale clients have to talk to a control server to fetch required metadata. I selfhost this piece via Headscale along with the DERP servers. The stack would be quite complicated for those who already had a wireguard tunnel, but I found myself liking it because Tailscale has other cool features too.
Alternatively, I guess you could also do “split-route” by defining different peers in your Android WireGuard app, and use different AllowedIPs for them.
I use Tailscale with an exit node container that forwards all traffic to the commercial VPN via a wireguard config. This “hopping” solution serves me well enough, and works for Android too.
If you want to simultaneously have two VPN interfaces, you may wanna consult this and this guide. The principle should apply with non-Tailscale wireguards too I think
Try nslookup testdomain.com from your laptop (this uses your router DNS by default)
Then try nslookup testdomain.com <your-router-ip> from your laptop (this forces using your router DNS)
Then try nslookup testdomain.com 1.1.1.1 from your laptop
Then repeat all 3, but on your router. Just to see where the problem is exactly
Does restarting your router help in these moments? Might just be an underpowered router
Do your devices use the router’s DNS? If so is it still reachable? From the client? From the router machine?
Might be some kind of DHCP bug too but I’m not well versed in it
I don’t think they require Nextcloud. Consider LaSuite Docs too if you need something simpler
FWIW, you can use Headscale’s embedded DERP server, or host your own. They need a STUN port and an HTTPS port
Ntfy can send/receive notifications to/from the phone. You can selfhost it or use a public instance. For the healthcheck app, consider Uptime Kuma as it has ntfy integration. But a simple cron script that monitors + cURLing ntfy when it fails could also be used.
Protocol-wise, OIDC is generally the most supported out there. LDAP too, to an extent.
Software wise, I find Kanidm quite simple to set up (basically just one container). It’s mostly managed via the terminal though, and lacks some eyecandy. But some of the examples in its docs should be easy to follow and get you familiar with mapping scopes/groups between Kanidm and services.
Authelia is okay too
I believe as of now, the databases do not diverge and hence a binary swap/container image swap is doable. If you already set up SSO logins, then I’m not sure because Continuwuity doesn’t support that yet.
Please re-ask the question with the folks in #continuwuity:continuwuity.org to be extra sure before doing anything. Oh and without saying, do clone and backup the data paths for easy reverts later
Feel free to ask here and I’ll reply. If you have a Matrix account you may wanna join #matrix:matrix.org too, it’s the “general” room where you should be able to get answers