Dietpi-9.3 issues with all existing services going down while using tailscale as an exit node. about dietpi

[MichaIng]

Please check the service logs about why they were stopped (or crashed), when you face this issue:

journalctl -u smbd -u nmbd -u adguardhome -u dropbear -u ssh

In case you have no local access, and SSH drops, you might need to enable persistent system logs:

dietpi-software uninstall 103 # disables RAMlog
mkdir /var/log/journal # enables persistent system/journal logs
reboot # needed to really enable it, since /var/log is still a tmpfs until reboot

Also, did you try to skip the routing options? Probably accepted or advertised routes conflict with each other and/or this device being an exit node. Loops are theoretically possible if multiple nodes advertise the same routes, not sure whether Tailscale has some internal prevention for this. This would be actually a good explanation, since I cannot imagine that Tailscale really affects the status of other services, but more that incoming traffic aimed to be handled by the device itself is instead routed elsewhere, or the answers are routed elsewhere, similar to when you enable a strict killswitch on a VPN server.

[zappydood]

Okay thank you for your help! I haven't gotten around to doing it again just yet but I plan on doing Tailscale up again this evening so I will use your tips and advice and report back. But I have a question for the setup.

So on diet pi I set it in my openwrt router as my used dns server. So all devices are dependent on it as well as unbound running with AdGuard home. So I'll know really quick if it's an issue. When I was doing this before I hadn't fully transitioned over to using it as the networks only dns (it was also using the built in dnsmasq in openwrt, but now I've got it set to only the dietpi for AdGuard home. Do you have any recommendations on Tailscale settings for AdGuard home/unbound to work properly for my local network as well as over the talent? I can for sure live without setting it as my exit node, but ideally I would also like to be able to utilize that as well given its 2.5 gb ports are far faster than my Apple TV as an exit node. But I'm gonna take it one step at a time I just wanted to know if you have any recommended settings for Tailscale? For context I'll include some information on dietpi and Tailscale so I hope it's not too many details.

I've read a lot of the Tailscale guides but so far the dns options seem to clash with Tailscales in-built magic dns as things seem to stop working for some devices somewhere at some point when enabling the split-dns. I'm probably doing something wrong somewhere. Any tips would be greatly appreciated. I have only two routes being advertised one by my Apple TV and one from my travel router and they don't collide with each other. 10.xxx.xxx.xxx/24 & 192.168.xxx.xxx/24 would it be best to only have one subnet router per subnet as I may stupidly been doing diet pi and the Apple TV as subnet routers and I feel like that was a mistake. Thanks again!

[MichaIng]

I have not much experience with Tailscale either. So I think you use its internal MagicDNS feature? https://tailscale.com/kb/1054/dns#using-dns-settings-in-the-admin-console

If I understand it right, this is a client/node side setting, to enable hostnames for other Tailscale nodes. I guess, for this to work, the Tailscale daemon itself then functions as and configures itself as local DNS resolver. If you enable this on the DietPi system, it would collide with AdGuard Home then, trying to listen on the same port 53. But on all other nodes, you could enable MagicDNS and configure the DietPi system (its Tailscale IP address) as global nameserver. I guess this was the plan anyway, to have ad blocking for remote devices?

10.xxx.xxx.xxx/24 & 192.168.xxx.xxx/24 would it be best to only have one subnet router per subnet as I may stupidly been doing diet pi and the Apple TV as subnet routers and I feel like that was a mistake. Thanks again!

As long as there is only one route for each subnet, i.e. one for 10.xxx.xxx.0/24 and one for 192.168.xxx.0/24, this should be all fine. But two subnet routers for the same subnet would likely be an issue, as other nodes then would not know which of both routes to use, probably sending requests randomly to either one or the other. Or requests are routed in an endless cycle between the two routers, as both follow the route distributed by the other one? 😄
Not sure whether Tailscale prevents this at the client/node side, to accept and configure only one of the two routes, based on some priority system.

In any case, it makes sense, for debugging, to test everything step by step, i.e. disable all subnet routes at first, then enable them one by one and see whether the DietPi system can still be reached from within LAN and Tailscale network.