Question: what sort of misconfiguration was it? Might have an effect on the round robin assignments of Cloudflare
Edit: just FYI, if behind a VPN, you may prefer using the DNS servers of that VPN provider to blend in with others. But I guess your VPN is your VPS so it’s a bit different here
Why are files unusable outside of Nextcloud? Consider using the External Storage plugin.
Imo there are two types of file servers: smart clouds with offline and smart selective on-demand sync on brand-specific clients, groupware support, conflict resolution, and enterprisy plugins (Nextcloud, Opencloud, Seafile, etc); and dumb clouds with protocol-based file transfers and filesystem-tree/userperms instant compliance (copyparty, sftpgo, etc)
Of the first one, only Opencloud has a native-looking filesystem (PosixFS) and does it without dependency on a db. It supports smart sync for Windows (via the same API OneDrive uses). Linux smart sync is sadly nonexistent due to lack of protocols, and whatever other software do (e.g. using an .owncloud placeholder file) is highly experimental.
Of the second type, you’d get all the standardizations and speed but no bidirectional sync nor offlineness - again this is honestly an advanced undertaking requiring academic understanding of distributed systems and whatnot. On Linux you may try emulating some aspects of it via a half-smart client like rclone with VFS, but the UX to store files offline is still not there.
Knowing these constraints I’d tier my storage into 2 parts: the daily files like notes and recent photos stored in one of the smart sync solution, ready for download and later offline use; and anything unnecessary (Jellyfin media, archives, ) to be in a dumb SMB share/SFTP mount.
HI, kinda late to the party. I’m in a similar rut with intercontinental internet issues, and would like to share my thoughts
While not a full-fledged CDN, you may consider setting up an Asian VPS to serve as a second reverse proxy/ingress route, terminate TLS there, and route plaintext HTTP back to your homelab (this virtual tunnel shall be behind a WireGuard VPN interface). As I’ve figured out in my blogpost here (see scenario 2), this allows the initial TCP and TLS handshakes to happen nearer to the user instead of going all the way to Europe and back home.
You can consider setting up a separate Jellyfin instance for Asia, but of course that comes with setting up syncing media, maintaining separate user credentials, and so on. So before renting compute, I suggest trying these smaller actions first - if they work you mightn’t need a VPS anymore:
/etc/sysctl.conf stuff are:
Curious to see if any of this helps :)
Try writing a maubot plugin or build from the ones available
If it’s a bunch of users sharing a bunch of resources from behind a bunch of different VPNs, I guess the most simple way is to tell them to expose it to the internet
Are you sharing your Linux PC with a bunch of different users? Or are you sharing your Linux server with a bunch of different users?
The Cloudflare Matrix blog in the newswire section is an AI slopfest, featuring a vibe-coded repo lacking fundamental protocol features, trivially false claims about Matrix projects, and misinformed comparisons to market their software offerings. Its original version did not even disclaim any AI assistance, and dishonestly advertise the thing as production-ready. It is not anything of proper substance.
To the selfh.st maintainers, I urge you to include the community’s responses towards this action, for completeness of the situation
I’m running continuwuity, and ejabberd as text-only IM servers to talk to some communities. The latter (and XMPP in general) has more moving parts (more ports, SRV records, etc) to set up, but messages deliver much faster and take much less resources. They’d probably both run fine on a VPS with the proper tweaks anyhow - the Rust-based server makes Matrix actually not suck after all
For bridges, I’ve used maunium-discord as a Matrix bridge in the past, and trying out slidcord right now. I think Matrix bridges still got better UI/UX due to more supported features (spaces/threads) and coherent clients, though let it be known Slidge is a hobbyist project. If your chat server is mainly for bridges, stick to Matrix and consider disabling federation. Also Matrix if you’d like your friends to switch over from Discord - it has more Discordesque features like custom emojis/stickers and SFU-backed group calls
Though this doesn’t mean I’m unrecommending XMPP. I do appreciate its clients’ snappiness, in-band notifications, the general ephemerality of its chats, and unrivaled efficiency. I kinda wanna write a blogpost comparing both software and protocols, but right now I don’t have an opinion about one over the other. They’re both cool albeit they both leak different metadata differently
It’s basically XMPP with a clear packaging, from server to client
Yes.
If you want to access your NPM stuff on both Tailscale and LAN, either:
Do a DNS rewrite at AGH, but instead of the LAN IP make it the Tailscale IP of your NPM machine. Then configure AGH’s IP address as one of the global nameservers on your Tailscale admin panel
Delete all A/AAAA records on Cloudflare, only use it for registrar purposes and the occassional certs authentication.
In your Tailscale DNS panel, disable “Use with exit node” option for your nameservers.
When turned on, that option actually allows you to talk directly to nameservers without tunneling DNS queries through the exit node. Since Quad9 in fact has a worldwide CDN, this would leak your (general) DNS query location.
I believe Tailscale send the queries in parallel and fetch the faster response, which is Quad9 in this case. Ideally for your use case, all your queries should be able to reach and show up in Pi-hole’s logs. Use tailscale dns commands for further debugging
Glad to know you got it working.
When you use a VPN as a matter of privacy, I believe you should use their DNS service too to blend in with the crowd. Because of DNS leaks, websites would likely know which DNS server you’re querying from, so using a selfhosted one instead of a VPN’s can be a major uniqueness vector. On the contrary however, I’ve seen many do exactly that, so I guess it’s not as big of an issue. So it’s your choice ultimately.
Now, if you opt for commercial VPN’s DNS servers, be aware that don’t usually block any ads (if they do it’s likely a paid option), and you’d want to configure your own local zones too. To intercept DNS queries and forward only the approved ones to the VPN, I think you have 2 options:
One solution is to resolve all my subdomains on /etc/hosts so it never has to leave the box, but I’m curious what a more experienced net admin would suggest.
Not a net admin but I would enforce a LAN-only DNS server for all relevant clients and put the records there. And/or put such an infra behind a VPN like Tailscale so bots don’t see it.
Yeah they registered a wildcard but queries contain the full domain
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:
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.
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
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
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
If you’re still interested in selfhosting a Rust-based homeserver, https://continuwuity.org/ will get you there. However if you’re just migrating your community to this federated protocol, making a room on an open registration server could be enough