this post was submitted on 29 Nov 2024
142 points (98.0% liked)

Selfhosted

40633 readers
306 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] pax0707@lemmy.world 17 points 2 weeks ago (2 children)

For me its been wireguard with split tunnel but that had a glaring issue with my home IP change (running 2 Pi-hole+unbound instances on separate network segments and hardware). Some time ago I switched to tailscale and added a Pi-hole on a VPS. Closed system, nothing exposed to the wide internet, works 99.99…% of the time, whole family protected against low hanging fruit attacks and adds.

[–] Lem453@lemmy.ca 18 points 2 weeks ago* (last edited 2 weeks ago) (2 children)

Use ddns on your router with a domain so you can then get something like wireguard.example.com and then use that as the endpoint in your wireguard.

Set the wireguard DNS as your pihole.

To make life easier set your home network IP space to something that another WiFi would never use, ie 192.168.46.xx

That way it will never conflict if you are on a public WiFi and you can access anything on your home lab when you need.

I've been using this setup for years on laptop, phone etc

[–] DynamoSunshirtSandals@possumpat.io 4 points 2 weeks ago (2 children)

I do exactly this as well. Works great! Dynamic DNS is kind of a hilarious hack.

Quick question: since I use wireguard, do I need to use DNS-over-HTTPS for security? My assumption is that my entire session is already encrypted with my wireguard keys, so it doesn't matter. But I figured I should double check.

[–] mac@lemm.ee 3 points 2 weeks ago (1 children)

Depends, do you have pihole/unbound setup to only recursively resolve? Or do you forward requests to an upstream (either as a fallback or just as a primary). If that's the case, and depending on your threat model, you'll want to set up DoH or DoT as your DNS requests will be forwarded in plaintext

Fortunately I set up unbound ages ago, and disabled every other upstream option in my pi.hole. However, I imagine that still "leaks" some information about my DNS queries, just indirectly -- it's not like my pi.hole has every domain mapped all the time!

[–] Lem453@lemmy.ca 1 points 2 weeks ago (1 children)

You do not need anything else. DNS requests are all sent over Wireguard with encryption

[–] DynamoSunshirtSandals@possumpat.io 1 points 2 weeks ago (1 children)

Excellent to have confirmation, thanks. What about the VPN connection handshake? I always assumed it was OK over non-SSL, because the exchange should use signed keys. But that is quite an assumption on my part.

[–] Lem453@lemmy.ca 2 points 2 weeks ago (1 children)

Wireguard uses public and private keys which are designed from the ground up to be used over plain text to establish the handshake so it isn't an issue. Same idea with ssh keys and ssl keys

[–] DynamoSunshirtSandals@possumpat.io 1 points 2 weeks ago (1 children)

Thanks. Wild that folks build SSH and HTTP around the same time without realising that HTTP could benefit from some of that same tech!

[–] Serinus@lemmy.world 1 points 2 weeks ago

At the time, everything HTTP was supposed to be public.

[–] pax0707@lemmy.world 3 points 2 weeks ago

I have ddns on Cloudflare. It works great, until your home IP changes. After that wireguard will happily hammer the old IP, till something breaks the tunnel and it reestablishes it to the new IP. Working as intended. My workaround was forcing the IP change over night while everyone was home.

Tailscale sorts all the issues I had.

[–] abeorch@lemmy.ml 5 points 2 weeks ago (2 children)

Whats the issue with the Home IP changing? - Have you setup a DynDns hostname?

[–] vividspecter@lemm.ee 4 points 2 weeks ago (2 children)

It may since have been fixed, but the Android client didn't handle IP changes well in my experience. From my understanding, it only checks DNS when it initially connects, and so if the public IP changes the connection just stops working. This might be fine if the public ip changes infrequently or if you frequently connect and disconnect rather than leave the client always on, but not so much otherwise.

Tailscale (and headscale) handles this gracefully, and you also get the nice NAT traversal features so no need to worry about CGNATs which are becoming more common.

[–] friend_of_satan@lemmy.world 2 points 2 weeks ago (2 children)

From my understanding, it only checks DNS when it initially connects, and so if the public IP changes the connection just stops working.

This is pretty standard TCP network behavior for long duration connections. The client queries dns for the IP address, opens a socket, and leaves it open as long as needed.

One thing that would help here is some kind of keepalive feature, like a client to server TCP connect or SYN, or better yet a higher level protocol signal. Check your client to see if there is some tunable keepalive. It may be set so something long like 1h.

[–] pivot_root@lemmy.world 4 points 2 weeks ago
[–] vividspecter@lemm.ee 3 points 2 weeks ago

Wireguard does have a KeepAlive option, but I found it didn't seem to help in practice.

Could be bugs with the client, which is pretty barebones.

[–] WhyJiffie@sh.itjust.works 2 points 2 weeks ago

that's how it works on desktop too regarding DNS, but when it receives a response from a new IP, it should send future traffic there as I know

[–] pax0707@lemmy.world 1 points 2 weeks ago

It will resolve the IP from the domain when the tunnel goes up and will keep using that one. Working as intended.

Overlay networks solve that issue.