31·
2 months agoDuckDNS pretty often has problems and fails to propagate properly. It’s not very good, especially with frequent IP changes.
- 4 Posts
- 20 Comments
Joined 7 months ago
Cake day: April 20th, 2024
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
41·3 months agoI wrote a simple, locally running Webapp some time ago, that targets the Lemmy Import-/Export-API and supports transferring only specific userdata between accounts, as demonstrated in this corresponding Wiki Entry.
The import functionality in Lemmy is additive in nature, meaning anything you import gets added on top of existing settings instead of replacing it.
Does the same thing as these manual instructions for this usecase, may be helpful to some.
I’d appreciate it very much!
Great suggestion to secure the backups themselfes, but I’m more concerned about the impact an attacker on my network might have on the external network and vice versa.
That’d be the gold standard. Unfortunately, the external network utilizes infrastructure that doesn’t support specifying firewall rules on the existing separate VLAN, so all rules would have to be applied on the Pi itself or on yet another device between, which is something I’d like to avoid. Great general advice, though!
While this is a great approach for any business hosting mission critical or user facing ressources, it is WAY overkill for a basic selfhosted setup involving family and friends.
For this to make sense, you need to have access to 3 different physical locations with their own ISPs or rent 3 different VPS.
Assuming one would use only 1 data drive + an equal parity drive, now we’re talking about 6 drives with the total usable capacity of one. If one decides to use fewer drives and link your nodes to one or two data drives (remotely), I/O and latency becomes an issue and you effectively introduced more points of failure than before.
Not even talking about the massive increase in initial and running costs as well as administrive headaches, this isn’t worth it for basically anyone.
I’ve been tempted by Tailscale a few times before, but I don’t want to depend on their proprietary clients and control server. The latter could be solved by selfhosting Headscale, but at this point I figure that going for a basic Wireguard setup is probably easier to maintain.
I’d like to have a look at your rules setup, I’m especially curious if/how you approached the event of the commercial VPN Wireguard tunnel(s) on your exit node(s) going down, which depending on the setup may send requests meant to go through the commercial VPN through your VPS exit node.
Personally, I ended up with two Wireguard containers in the target LAN, a wireguard-server and a **wireguard-client **container.
They both share a docker network with a specific subnet {DOCKER_SUBNET} and wireguard-client has a static IP {WG_CLIENT_IP} in that subnet.
The wireguard-client has a slightly altered standard config to establish a tunnel to an external endpoint, a commercial VPN in this case:
[Interface] PrivateKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Address = XXXXXXXXXXXXXXXXXXX PostUp = iptables -t nat -A POSTROUTING -o wg+ -j MASQUERADE PreDown = iptables -t nat -D POSTROUTING -o wg+ -j MASQUERADE PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT [Peer] PublicKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX AllowedIPs = 0.0.0.0/0,::0/0 Endpoint = XXXXXXXXXXXXXXXXXXXXwhere
PostUp = iptables -t nat -A POSTROUTING -o wg+ -j MASQUERADE PreDown = iptables -t nat -D POSTROUTING -o wg+ -j MASQUERADEare responsible for properly routing traffic coming in from outside the container and
PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECTis your standard kill-switch meant to block traffic going out of any network interface except the tunnel interface in the event of the tunnel going down.
The wireguard-server container has these PostUPs and -Downs:
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADEdefault rules that come with the template and allow for routing packets through the server tunnel
PostUp = wg set wg0 fwmark 51820the traffic out of the tunnel interface get marked
PostUp = ip -4 route add 0.0.0.0/0 via {WG_CLIENT_IP} table 51820add a rule to routing table 51820 for routing all packets through the wireguard-client container
PostUp = ip -4 rule add not fwmark 51820 table 51820packets not marked should use routing table 51820
PostUp = ip -4 rule add table main suppress_prefixlength 0respect manual rules added to main routing table
PostUp = ip route add {LAN_SUBNET} via {DOCKER_SUBNET_GATEWAY_IP} dev eth0route packages with a destination in {LAN_SUBNET} to the actual {LAN_SUBNET} of the host
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip route del {LAN_SUBNET} via {DOCKER_SUBNET_GATEWAY_IP} dev eth0delete those rules after the tunnel goes down
PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark 0xca6c -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -I OUTPUT ! -o %i -m mark ! --mark 0xca6c -m addrtype ! --dst-type LOCAL -j REJECT PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark 0xca6c -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -D OUTPUT ! -o %i -m mark ! --mark 0xca6c -m addrtype ! --dst-type LOCAL -j REJECTBasically the same kill-switch as in wireguard-client, but with the mark manually substituted since the command it relied on didn’t work in my server container for some reason and AFAIK the mark actually doesn’t change.
Now do I actually need the kill-switch in wireguard-server? Is the kill-switch in wireguard-client sufficient? I’m not even sure anymore.
Oh I’m fully aware. I personally don’t care, but one could add a capable VPS and deploy the Wireguard Host Container + two Client Containers, one for the LAN and one for the commercial VPN (like so), if the internet connection of the LAN in question isn’t sufficient.
Oh, neat! Never noticed that option in the Wireguard app before. That’s very helpful already. Regarding your opnsense setup:
I’ve dabbled in some (simple) routing before, but I’m far from anything one could call competent in that regard and even if I’d read up properly before writing my own routes/rules, I’d probably still wouldn’t trust that I hadn’t forgotten something to e.g. prevent IP/DNS leaks.
I’m mainly relying on a Docker and was hoping for pointers on how to configure a Wireguard host container to route only internet traffic through another Wireguard Client container.
I found this example, which is pretty close to my ideal setup. I’ll read up on that.
2·4 months agoIndeed it does, I was talking about adding a checkbox tagged “Only transfer blocked users” instead of having to click through some menus.
Sure, the code is completely client-side, simply clone it. If you’re running into CORS problems due to the file:// scheme Origin of opening a local file, simply host it as a local temporary server with something like
python -m http.server.This is due to the two ways most instances validate Cross-Origin requests:
- Sending Access-Control-Allow-Origin: * (allow all hosts)
- Dynamically putting your Origin into the Origin header of the response to your requests by the backend
file://URLs will result in anullorfile://Origin which can’t be authorized via the second option, therefore the need to sometimes host the application via (local) webserver.
The whole point of this being a web app is to make it as easy as possible for the user to download/modify/transfer their user data. LASIM is a traditional app the user has to download and install, similar to a script this web app was developed to replace due to being too difficult to use for some users.
The import functionality targeted by this API is additive and my app features a built-in editor to add, modify or remove information as the user sees fit. To achieve your stated goal, you’d have to remove anything except the
blocked_usersentries before importing, which my app supports, I added a wiki entry explaining the workflow in more Detail.I may add options to modify the exported data in some ways via a simple checkbox in the future, but I wouldn’t count on it. I’m always open for pull requests!
- “display_name”
- “bio”
- “avatar”
- “banner”
- “matrix_id”
- “bot_account”
- “settings”
- “followed_communities”
- “saved_posts”
- “saved_comments”
- “blocked_communities”
- “blocked_users”
- “blocked_instances”
The export/import functionality is, yes. This implementation uses the same API endpoints, but the main reason for this existing:
An instance I was on slowly died, starting with the frontend (default web UI). At least at the time, no client implemented the export/import functionality, so I wrote a simple script in Bash to download the user data, if the backend still works. Running a script can still be a challenge to some users, so I wrote a web application with the same functionality. It’s a bit redundant if we’re talking about regularly working instances, but can be of use if the frontend isn’t available for some reason.
Pretty much anything, from your Desktop Environment to the simplest application running in the background, will have way more of an impact than pretty much any semistatic website. I’m curious, what do you mean with “in the optimal way possible”? Are you constantly maxing out your RAM already, and if so, how?
I prefer Lemmy for:
- actually engaging with content (commenting/posting/voting) instead of simply consuming. By the time the API restrictions came around and the ads/bots started to dominate, it felt pointless to engage on Reddit any more.
- the positive parts of the federated and FOSS nature. Choose an instance, build your own, use or build any client you want to, federate or defederate whoever you want.
I prefer Reddit for:
- getting info/recommendations on things. The knowledge base is magnitudes larger than anything Lemmy can offer atm. Also, due to the centralized nature, it’s so much easier to search for something on Reddit.
Lemmy’s got some problems and I can’t stand the interinstance drama, also, due to the decentralized nature, some instances can’t keep up or the admins don’t care any more, so whole communities can essentially be held hostage or simply die until a toolset to move a community from one instance to another (and propagate the change properly to the Fediverse) becomes available.
Well, this tells us that more privacy minded people with a background or interest in technology tend to be more present/engaging on Fediverse platforms. Not really surprising.
Buying a domain. There might be some free services that, similar to DuckDNS in the beginning, work reliably for now. But IMHO they are not worth the potential headaches.