V
I could be misinformed, but this isn’t just limited to Spark as I understand it, I believe a lot (maybe all?) third-party clients do the same thing. They act as an intermediary between you and the server so they can deliver push notifications.
However, as I understand it, Spark’s privacy policy outlines that they don’t read/scan the contents of your emails, and the use of app-specific passwords rather than your email password ensures they only have access to emails and nothing else.
Pretty sure others such as Canary, Airmail, Edison, etc. all do/did the same thing, but it was the lack of clarity in Spark’s privacy policy that made them the main target for scrutiny. I think they’ve since cleared that up.
I could be mistaken, though.
Update from this morning.
So far I’ve got the Traefik dashboard and my Homepage container using subdomains. Pi-hole is still an issue that I need to figure out.
I’ve decided to start on the SSL certificates and am following a couple of guides. Once I have those in place, I’ll start moving more containers behind subdomains.
I might have to expose my NAS IP to the internet and link it via Cloudflare, because I use an ExpressVPN on my Mac at all times, and when it’s turned on I can’t access ***any ***of my subdomains - this is obviously because ExpressVPN use their own DNS entries and don’t use the ones I’ve set. That will probably prevent me from using Vaultwarden (which is the whole purpose for all of this in the first place) because if I’m on the VPN I won’t be able to access the Vaultwarden container.
Unless anyone knows of a workaround for that?
Next steps:
Figured it out. It’s a weird setting on Netgear routers whereby you have to also update the MAC address. All been working well for the last few hours and getting queries running through Pi-hole.
I’ve also got my Homepage container setup at http://home.mydomain.com and configured Traefik a little further so it’s now accessible from http://traefik.mydomain.com (no port).
For the past few hours I’ve been struggling with getting Pi-hole behind Traefik and accessible using http://pihole.mydomain.com. Only works if I stick /admin on the end, which defeats the object of using a subdomain. Found a forum post suggesting to use Traefik’s addPrefix after declaring the Host as pihole.mydomain.com, which works great for accessing the login screen, but when you enter the password it just loops back to the login screen.
Also tried a few other things that ultimately broke the Pi-hole container and took out my entire connection, as everything is dependent on Pi-hole for DNS! So need to figure out some kind of resiliency/backup for that (my router is using the NAS IP as it’s primary and only DNS server).
So, some progress. I’ve set Pi-hope back to IP:port and I’m gonna focus on getting other containers behind Traefik and leave Pi-hole till last. Then and only then will I look at SSL certificates (unless it’s advised to do it earlier?)
Any pointers on any of the above would be appreciated! And thanks again for getting me this far.
I’ve just added in a macvlan network to my Pi-hole compose as well, not sure if it’s making any difference or not.
I wasn’t planning on using Pi-hole for DHCP - I have a LOT of reserved addresses on my network and I don’t fancy having to move them all over. My hope had been to use Pi-hole for DNS but keep the DHCP reservation with the router.
I’ve manually updated the DNS on my Mac to 192.168.1.116 and I can now access the Traefik dashboard via http://traefik.mydomain.com:8080 (so, getting there). So some kind of issue with the DNS on my router I think - caching maybe?
Actually, no I don’t see anything coming through.
So the IP address of my router is 192.168.1.1, IP of my NAS is 192.168.1.116.
Checked the DNS on my Mac and it’s 192.168.1.1. Checked the DNS on my NAS and it’s 192.168.1.1. I changed the DNS in my router to 192.168.1.116.
Have I missed a step somewhere?
OK so made a start with this. Spun up a Pi-hole container, added mydomain.com as an A record in Local DNS, and created a CNAME for traefik.mydomain.com to point to mydomain.com.
In Cloudflare, I removed the mydomain.com A record and the www CNAME record.
Doing an nslookup on mydomain.com I get
Non-authoritative answer:
*** Can't find mydomain.com: No answer
Which I guess is to be expected.
However, when I then navigate to http://traefik.mydomain.com in my browser, I’m met with a Cloudflare error page: https://imgur.com/XhKOywo.
Below is the docker-compose of my traefik container:
traefik:
container_name: traefik
image: traefik:latest
restart: unless-stopped
networks:
- medianet
ports:
- 80:80
- 443:443
expose:
- 8080
volumes:
- /etc/localtime:/etc/localtime:ro
- /var/run/docker.sock:/var/run/docker.sock:ro
- /volume1/docker/traefik:/etc/traefik
- /volume1/docker/traefik/access.log:/logs/access.log
- /volume1/docker/traefik/traefik.log:/logs/traefik.log
- /volume1/docker/traefik/acme/acme.json:/acme.json
environment:
- TZ=Europe/London
labels:
- traefik.enable=true
- traefik.http.routers.traefik.rule=Host(`$TRAEFIK_DASHBOARD_HOST`) && (PathPrefix(`/api`) || PathPrefix(`/dashboard`))
- traefik.http.routers.traefik.service=api@internal
- traefik.http.routers.traefik.entrypoints=traefik
My traefik.yml is also nice and basic at this point:
global:
sendAnonymousUsage: false
entryPoints:
web:
address: ":80"
traefik:
address: "8080"
api:
dashboard: true
insecure: true
providers:
docker:
endpoint: "unix:///var/run/docker.sock"
watch: true
exposedByDefault: false
log:
filePath: traefik.log
level: DEBUG
accessLog:
filePath: access.log
bufferingSize: 100
Any ideas what’s going wrong? I’m unclear on why the domain is still routing to Cloudflare.
Absolute superstar, thanks for your help so far. I’ll make a start on some of this tomorrow and see how far I get — either with Traefik or NPM.
Do I need to do anything with the domain itself on Cloudflare at the moment? Or do I just leave it with its current A record pointing at an IP address (it was done as part of the setup in Cloudflare so I have no idea what that IP address is).
Obviously that domain in reality will just sit there doing nothing.
I don’t plan on exposing any of this stuff to anybody other than me. I do plan on spinning up SearX but it’ll only be me using it. I’ve given up trying to convince my family to move away from Google to even DuckDuckGo or Startpage, so there’s no way I’ll convince them to use SearX!
I think, therefore, for accessing away from home I’ll perhaps setup a subdomain that points to the IP of my Tailscale container — that means it’ll be accessible externally but only when I turn on the VPN.
When I’m on my home network I have a VPN on my Mac anyway.
Before I was using Traefik I used to use plain NGINX and was pretty happy with it. I made the switch to Traefik after reading some good things about it on Reddit.
More than happy to switch to NPM and give it a try. At this point I have no reverse proxy running at all, so not even like I have to swap out Traefik — there’s nothing they’re to begin with.
Thanks. I realise they’re all pretty basic questions. But brace yourself: more are on their way!
So… no, I don’t want to give external access - I’m not running any services that anyone would want/need access to - other than perhaps my Jellyfin server, but not sure I even want anyone accessing that. So let’s assume for right now, no access to the outside world. Therefore, no port forwarding required.
So to get access to my internal network from the domain, do I simply setup local DNS records in something like Pi-hole, to point mydomain.com to the internal IP or my NAS? Kind of like a network-wide equivalent of modding the /etc/hosts file on my machine?
Perhaps a(nother) silly question but, what’s to stop me doing that now with a completely random domain name? Is there some kind of authentication I’d need to go through to prove that mydomain.com is, in fact, mine? Or does it simply not matter since it’s internal only?
If I’ve understood correctly, then, I don’t need Cloudflare at all in my setup if there’s no external access? Nothing to proxy, nothing to protect?
Assuming I get all of the above working and traffic routing to my containers, how would I then go about setting up SSL? Can that be done through Traefik rather than Cloudflare? Even if the domain isn’t external?
Thanks. There’s definitely stuff in here I want to do, I just need to figure out the order of play and break it down a bit.
As per reply to another comment.
Do I have to port forward 80 and 443 no matter what? Ideally I don’t want to forward anything.
Do I need DDNS in here somewhere, i.e. create a DDNS and link it to my NAS, create an A record in Cloudflare to point my domain to the external IP of the DDNS? Is that how I get into my NAS from the domain without worrying about the IP changing? How do I then prevent anybody accessing the NAS admin on port 5000/5001, as well as anything else except the containers I expose via Traefik?
Thanks, I’d like to know more about how to go about this approach.
I guess in my head, I want to achieve the following (however I go about it):
I have no idea where Cloudflare factors in (if at all), nor how Pi-hole factors in (if at all).
Internal stuff I’ve been absolutely fine with. Stick a domain name, a reverse proxy and DNS in front of me and it’s like I’m learning how to code a Hello World app all over again.
Thanks.
I guess the issue with this, though, is that I don’t always need to access it via Tailscale - I’d only do that when away from home. Perhaps there’s a way to point a subdomain to the Tailscale IP, and that’s only accessible when Tailscale is active? And then use an alternative subdomain to access it the rest of the time? Is that achievable?
Thanks. Yep, subdomains was what I’d planned on: traefik.mydomain.com to access the Traefik dashboard; home.mydomain.com to access the Homepage container. I was planning on spinning up an Authelia container as well to provide 2FA for the services I want protecting. I guess it’d also be nice to have some kind of landing page for traffic coming directly to www.mydomain.com or mydomain.com as well.
Ideally I don’t want to port forward, so would I need to rely on Traefik to redirect the traffic from port 80 to port 443, and then proxy from port 443 to the required container? How do I therefore stop traffic from hitting the DSM admin on ports 5000/5001 for example?
I need to figure out a starting point to get traffic from my domain into my NAS (safely) then start spinning up containers and have Traefik route them appropriately, then I can look at Pi-hole/local DNS and Tailscale. And then I guess SSL.
Interesting, I’ve never considered Cloudflare Tunnels. Thanks.
However I do remember seeing this video the other day, that suggests perhaps it’s not always the best solution? Not sure this applies here, though: https://www.youtube.com/watch?v=oqy3krzmSMA.
Would love an up-to-date tutorial on how to do this without a domain name. I don’t own one but would still much prefer to use https://jellyfin.myserver.home than http://192.168.1.200:8096.
Thanks. Yeah I originally had plain ol’ NGINX (granted, without the additional networking I have now) and using
location /xyz {
$proxy_pass http://a.b.c:123
}
(I forget the exact syntax now) was pretty easy to route stuff around.
But that was all done under an initial
server :80 {
...
}
section, which might be the part I’m initially struggling with. It just doesn’t seem as intuitive in NPM despite me seeing lots of people preferring it over plain NGINX and Traefik.
NPM is why I have the macvlan and bridge networks in there in the first place, because ports 80 and 443 are in use on the Synology NAS. Otherwise, I could revert back to running a script that frees up those ports on boot-up and use NPM within the same network as all my other containers.
Thanks. Yeah, .local was just an example for the sake of posting something on here. In reality, I would be using ds1618plus.home. But good to know .local is reserved!
I didn’t know they stored local copies — had a very, VERY quick skim through their privacy policy on their website and couldn’t see any reference to that (sure it’s there but I didn’t see it).
I’m not a Spark user btw, was just following the conversation. I use plain ol’ Apple Mail.