stratself

joined 4 months ago
[–] stratself 1 points 11 hours ago* (last edited 11 hours ago)

Have you solved your problem? It seems like there are some issues with your setup:

TDNS is set to "allow recursion only for private networks" this means that if something external tried to resolve using my TDNS they'll be refused, correct?

Correct. It only accept recursion queries from private networks and can make outbound requests to the internet as normal

10.2.0.1 turned out to be my vpn’s dns server

On the computer, you're also using your VPN's DNS service accessible within the VPN tunnel (hence the weird IP address). If you wanna use Technitium you should disable such service

I set NAT rules to force TDNS port 53 routing. TDNS is set to forward to quad9 and cloud flare externally. DNS blocking lists are set in TDNS.

Unable to reach external net when NAT rules active.

If you're forcing every device to talk to TDNS, then your TDNS server is also talking to itself and cannot make queries to Cloudflare/Quad9 on port 53. You can either:

  • Create an exception rule to allow your TDNS address to talk to Cloudflare/Quad9, or
  • Use DNS-over-HTTPS/DNS-over-TLS as your TDNS forwarder protocols as they aren't affected by rules on port 53 (recommended for encryption)

It seems the DHCP is handing out the fire wall's ip for DNS server, 100.100.100.1 is that the expected behavior since DNSmasq should be forwarding to TDNS 100.100.100.333.

Yes it's expected, if you're telling your clients to forward their queries to dnsmasq, and then let dnsmasq forward those queries to Technitium. If you want clients to talk directly to TDNS instead, set the DHCP option to advertise its address and don't use your firewall's address as a forwarder. I prefer the second option as it'll give you correct client IPs in query logs and save some round trips.

I don't really know what I'm doing with zones but I have a primary zone set with example.com. I set some static hosts records in this zone and enabled reverse lookup, expecting servicehost.example.com

If you can query the zone and its reverse PTR record in Technitium's DNS client, then you've properly set it up. Remember you'll have to tick the PTR options when setting up said record. Also you can open an issue on Technitium's Github or their subreddit for assistance.

[–] stratself 3 points 3 days ago

My guess would be NSEC zone walking if your DNS provider supports DNSSEC. But that shouldn't work with unregistered or wildcard domains

The next guess would be during setup, someone somewhere got ahold of your SNI (and/or outgoing DNS requests). Maybe your ISP/VPN service actually logs them and announce it to the world

I suggest next time, try setting up without any over-the-internet traffic at all. E.g. always use curl with the --resolve flag on the same VM as Apache to check if it's working

[–] stratself 1 points 4 days ago

Having a DNSSEC-enabled resolver does protect from tampering with the DNS records, but not all ISPs properly support it so you may see many more errors. It should be used in conjunction with recursion or a respectable public resolver with support for DoH/DoT

[–] stratself 1 points 5 days ago

It's not a factor for me, but if you continually find slow speed you could try picking a mirror that has better perf. Also dnf can be incredibly slow so you may need some additional max_parallel_downloads tuning

[–] stratself 2 points 1 week ago
[–] stratself 3 points 1 week ago* (last edited 1 week ago) (1 children)

Technitium is very powerful and could perfectly handle being a DNS forwarder + DHCP provider for your LAN, replacing both Pihole + cloudflared. Though it does many other things too, which can make the UI overwhelming for starters. But in my opinion if you'd like to fine-tune a lot of things like cache and custom DNS logic (via installable applets), this would be the software for you

Edit: If you want something simpler to replace Pihole + cloudflared, AdGuard Home is pretty good too. It uses dnsproxy under the hood and has a nice UI

For the upstream provider I guess Quad9 is popular enough to give you fairly good geolocated IPs, but also has some sense of privacy. The main thing is to always validate your andwers with DNSSEC as to detect and refuse any DNS tampering attempts

[–] stratself 4 points 1 week ago

Yes you'll need a way to query the domain of the DoH service in plaintext before using it. In many software you can define "bootstrap DNS addresses" to do exactly that. Or you can hardcode the DoH service's IPs, which for most upstream providers are almost always the same as their "normal" IPs anyways

[–] stratself 2 points 1 week ago

Yes it involves nginx's stream directive

[–] stratself 4 points 1 week ago (3 children)

As continued from my answer for ypur previous post I suggest you route pure TCP traffic all the way to your backend and terminate TLS (with a Let's Encrypt cert) there. In fact, I prefer not to mount any certs on the VPS. This does not involve separate certs nor internal domains.

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

YOU WILL NEED TO UPDATE AGAIN!

There is another vulnerability making the rounds with details pending embargo. Please update to the latest version (again)

[–] stratself 3 points 2 weeks ago (1 children)

Is there a way for you to talk to upstream DNS bypassing Ubiquiti's firewall? Maybe do it on a different port? (idk if the RFC permits this)

 

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 2 months ago* (last edited 2 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 ›