stratself

joined 8 months ago
[–] stratself 2 points 1 day ago

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.

[–] stratself 2 points 3 days ago

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.

[–] stratself 3 points 5 days ago (1 children)

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.

[–] stratself 2 points 1 week ago (2 children)

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.

 

Technitium DNS Server v15.1.0 has been released with support for OIDC! Now you can use your preferred identity provider to log in to user accounts, and manage your DHCP/DNS deployments with approriately granular permissions controls.

I've played around with it, and safe to say that the SSO integration works well. I've written a guide to set it up against Kanidm here. There were some OIDC/clustering bugs in prior v15 releases, and with v15.1.0 they have been squashed and solved.

The major release of version 15 also include various important changes, such as the following highlights:

  • A new API call for Prometheus metrics
  • Query Logs apps can now follow live updates
  • Codebase updated to .NET 10 runtime
  • HTTP tokens are now accepted via the Authorization: Bearer <token> header
  • Many other bugfixes, secfixes, and improvements...

Technitium is pretty great. Hope everyone enjoy the release :)

[–] stratself 1 points 1 week ago

Did you try OpenVFS ever outside of Opencloud? Is that project even published yet?

[–] stratself 12 points 1 week ago (1 children)

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.

[–] stratself 1 points 3 weeks ago

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

[–] stratself 1 points 1 month ago (1 children)

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.

[–] stratself 1 points 1 month ago (3 children)

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

[–] stratself 1 points 1 month ago* (last edited 1 month ago)

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

[–] stratself 1 points 1 month ago (1 children)

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

[–] stratself 2 points 1 month ago

I don't think they require Nextcloud. Consider LaSuite Docs too if you need something simpler

 

There is a recently discovered critical vulnerability that affects all Matrix homeservers of the Conduit lineage. If you're using a Rust-based Matrix server (which are basically Conduit and forks), please urgently upgrade to the following versions:

If you're not able to upgrade right now, you should urgently implement this workaround in your reverse proxy.

Attackers exploiting this flaw can arbitrarily kick any user out of a room, join rooms unauthorized on the same server, and can also ban same-server users. They effectively constitute a severe denial of service from an unauthenticated party, and it has been exploited in the wild.

 

Technitium DNS Server (TDNS) has gotten a new release with many awesome features: TOTP authentication, an upgraded .NET library, and many security and performance fixes.

But most important of all, it now supports clustering. A long-awaited feature, this allows Technitium to sync DNS zones and configurations across multiple nodes, without needing an external orchestrator like Kubernetes, or an out-of-band method to replicate underlying data. For selfhosters, this would enable resilience for many use cases, such as internal homelab adblocks or even selfhosting your public domains.

From a discussion with the developer and his sneak peek on Reddit, it is now known that the cluster is set up as a single-primary/multiple-secondary topology. They communicate via good-old REST API calls, and transported via HTTPS for on-the-wire encryption.

To sync DNS zones (i.e. domains), the primary server provisions the "catalog" of domains, for secondary ones to dynamically update records in a method known as Zone Transfers. This feature, standardized as Catalog Zones (RFC9432), were actually supported since the previous v13 release as groundwork for the current implementation.

As an interesting result, nodes can sync to a cluster's catalog zone, as well as define their own zones and even employs other catalog zones from outside the cluster. This would allow setups where, for example, some domains are shared between all nodes, and some others only between a subset of servers.

To sync the rest of the data such as blocklists, allowlists, and installed apps, the software simply sends over incremental backups to secondaries. The admin UI panel is also revamped to improve multi-node management: it now allows logging in to other cluster nodes, as well as collating some aggregated statistics for the central Dashboard. Lastly, a secondary node can be promoted to primary in case of failures, with signing keys also managed within for a seamless transition of DNSSEC signed zones.

More details about configuring clusters is to be provided in a blogpost in the upcoming days. It is important to note that this feature only supports DNS stuff, and not DHCP just yet (Technitium is also a DHCP server). This, along with DHCPv6 and auto-promotion rules for secondaries, is planned for the upcoming major release(s) later on.

As a single-person copyleft project, the growth of this absolute gem of a software has been tremendous, and can only get better from here. I personally can't wait to try it out soon

Disclaimer: I'm just a user, not the maintainer of the project. Information here may be updated for correctness and you can repost this to whatever

66
submitted 6 months ago* (last edited 6 months ago) by stratself to c/selfhosted@lemmy.world
 

Hi all, I made a simple container to forward tailscale traffic towards a WireGuard interface, so that you can use your commercial VPN as an exit node. It's called tswg

https://github.com/stratself/tswg

Previously I also tried Gluetun + Tailscale like some guides suggested, but found it to be slow and the firewall too strict for direct connections. Tswg doesn't do much firewalling aside from wg-quick rules, and uses kernelspace networking which should improve performance. This enables direct connections to other Tailscale nodes too, so you can hook up with DNS apps like Pi-hole/AdguardHome.

I've shilled for this previously, but now I wanna promote with an actual post. Having tested on podman, I'd like to know if it also works on machines behind NATs and/or within Docker. Do be warned though that I'm a noob w.r.t. networking, and can't guarantee against IP leaks or other VPN-related problems. But I'd like to improve.

Let me know your thoughts and any issues encountered, and thank you all for reading

 

Hi all. Per the title, I'm looking for something that:

  • Can run as an unprivileged user inside a container

  • Allows OpenID Connect authentication for a multiuser setup

  • Doesn't take hostage of my CPU

Homarr and Dashy are featureful solutions, but they can't run unprivileged in docker. Dashy closed this issue, but in fact it's not resolved. Meanwhile Homarr does work with UID/GID env vars, but starting as root and dropping capabilities is not the same as defining user: 1234:1234 from the get-go. Furthermore, they are really heavy node apps, which kinda deter me from deploying.

I neither wanna use my reverse proxy with forward auth or having an extra oauth2-proxy container, so Organizr (using forwarded auth headers) or Homer/Homepage/bunch of static pages behind a reverse proxy is out of scope.

Feature-wise I'm just looking for a beautified link keeper, preferably with multiple dashboard mapped to different user groups (ideally it could be done via custom OAuth metadata/claims). Fancy plugins like RSS and weather are not needed, but appreciated.

With all that said (and sorry if I'm too choosy), is there a current solution that fits the bills above? My IDP's UI is quite rudimentary, but I can resort to using it as a "homepage". I wanna thank in advance for any guidance

P/S: Seems like most dashboards fall into two categories - bloated fancy apps, or dead simple frontpages. It'd be nice to have something inbetween.

view more: next ›