Same problem as https://aottr.dev/posts/2024/08/homelab-using-the-same-local-domain-to-access-my-services-via-tailscale-vpn/: I have setup a tailscale mesh VPN, and want to access services in my home network even without their hosts being part of the VPN (think IoT devices without resources or support for the tailscale daemon).

Subnet Routes

The tailscale client (and headscale, the self-hosted bootstrap server) support subnet routers for exactly this purpose: I configure the tailscale client on my NAS to --advertise-routes 192.168.168.0/24,<2003:... prefix from Telekom>::/56 and then use headscale nodes approve-routes on my VPS to allow those routes to be published for all other devices in the VPN.

TODO: whenever my CPE at home (the router which terminates the internet connection using e.g. PPPoE) gets a new IPv6 prefix via Prefix Delegation, update the advertised route and approve it.

Now other devices can tailscale up --accept-routes and the daemon will inject some fancy firewall rules which route traffic to addresses in my home network over the tunnel -- first part done.

home network DNS

My homeserver runs a DynDNS client, which ensures a publicly resolvable DNS name nas.example.com always points to

• (A) the public IPv4 assigned to the CPE, which can port-forward single ports to the NAS to expose some of its services directly to the internet
• (AAAA) the globally routable IPv6 it has assigned to itself (read out locally using ip -6 -json a s scope global -deprecated -temporary -mngtmpaddr | jq -r '.[0].addr_info[].local | strings' | head -1)

A static alias record *.nas CNAME nas (expanded: *.nas.example.com CNAME nas.example.com) lets me use any name below that zone for services on the nas, so allowing

• every service to have its own hostname, so no messing with ports, and a different cookie namespace in web browsers
• the NAS to get a wildcard certificate via ACME from Let's Encrypt valid for all its services. I made sure the NAS responds to unconfigured hostnames with an error (instead of responding e.g. with the first one in the configuration).

...conflicts with VPN

This setup is not reliable with tailscale subnet routes. When a client tries to access myservice.nas.example.com:

• If it is in some other network, without VPN, my router firewall blocks the access (except for configured port forwardings) -- as it should
• If it is in my home network, it can access myservice just fine: It has an IPv6 addresses from the same prefix and thus a local route. Apparently that is always used to connect to the NAS, because the A record would let it use the public IPv4 of the CPE, i.e. take a turn just "outside" my router and get blocked by its firewall.
• If it is in some other network and connected to the tailscale VPN, the (AAAA) record points it to an IPv6 address in my home network, which gets routed correctly through the tailnet, but the (A) record points to the public IPv4 of my CPE on which the firewall blocks access. Thus if it's possible to access the service depends on the IP stack used, which I cannot influence

solution: IPv6 only internal services

The article linked at the start solves this problem using split DNS: VPN-connected nodes get a different DNS resolver for the Zone(s) used in my home (or any network subnet-routed into the VPN). However this

1. would require me to maintain that resolving DNS server and
2. let the tailscale client configure that resolver on all clients whishing to communicate to my home net (MagicDNS is a standard function in tailscale, but by default of in linux clients, probably because it can mess with the local configuration) and
3. could lead to issues when clients use cached DNS responses from before connecting to the VPN (e.g. Browsers do so: Inspect your Firefox' cache at about:networking#dns, disable using network.dnsCacheEntries and network.dnsCacheExpiration)

So instead I switched my internal services (i.e. those not exposed to the internet with a port forwarding) to IPv6 only: DynDNS on my NAS now updates not only the A and AAAA records for nas.example.com, but also an extra AAAA (but no A) record nas-services.example.com with its (globally routable) IPv6 address. The CNAME *.nas.example.com now (statically) points to nas-services.example.com, leaving all services without an A record thus only resolving to IPv6 which is (the three client cases from before) either locally reachable, globally reachable but firewall-blocked, or routed via VPN and thus reachable.

Things about CheckMK not (easily) found in the documentation.

Every host is pinged, this service is named "Check_MK".

Run containerized version in podman with podman --cap-add net_raw for ping to work

Install Plugins in containerized Raw edition:

$ podman exec -it -u cmk  checkmk  /bin/bash
OMD[cmk]:~$ cd /tmp
OMD[cmk]:~$ curl https://raw.githubusercontent.com/f-zappa/check_mk_adsl_line/master/adsl_line-1.3.mkp
OMD[cmk]:~$ mkp install adsl_line-1.3.mkp

Monitoring RHEL7

• has systemd v219, the agent requires 220. remedy: "legacy mode"
• avoid xinetd? use Agent over SSH
• ssh known_hosts in checkmk container: run cmk --check $hostname which lets "the correct" ssh ask for accepting the host key. podman -u cmk $containername /bin/ssh $hostname did not suffice in my case

IPv6

checkmk defaults to IPv4 only, change in Settings > Folder "Main" > Dual stack. Selecting "both" will do ping4 and ping6 checks separately.

podman container gets no public route, only link-local (fe80:), thus IPv6 pings to public addresses fail. Apparently an open issue: https://github.com/containers/podman/issues/15850.

My fedora 35 had its plasmashell process stuck at 100% CPU, after some switching between wayland and X11 sessions. When trying to change global keyboard shortcuts (e.g. Alt-F1 for the App-Menu Launcher), it would freeze completely for like 30 seconds, repeatedly. A new user wouldn't have that problem.

The fix was to remove ~/.config/plasmashellrc.

Disclaimer: this article is rather old, and does not reflect linux' current state of brightness on the Thinkpad E135

first, it was fixed on maximum. no tool could change it, /sys/class/backlight/acpi_video0/brightness could be written to and changed, but the backlight didn't. Tried the solutions in¹, excluding those which would just echo to above /sys/... file, until I found out Kernel parameter acpi_backlight=vendor did the trick.

Now /sys/class/backlight no longer contained an acpi_video0 directory, but a thinkpad_screen directory, that has the same brightness files, which change on using the Fn keys for brightness change.

If I write to them their content changes, but not the backlight, but at least the Fn key combos work.

On the Thinkpad Edge E135, ALSA recognizes 2 sound cards (0 and 1), of which #1 is the analog one I want to use and control - but not the default one. alsamixer can control it via selecting the entries in its F6 menu, but still it's not the default one. Creating this¹ asound.conf fixes that.

Now KMix shows 2 open tabs (both with the label "HD Audio Generic"), one for each card. Unfortunately it defaults to control the digital output with its control-panel icon, too, and worse, the dialog to change that "Master Channel" gets confused by the identical names and just doesn't display any channel, so you can't change it. Fix: Stop KMix (dunno if that's really neccessary, but probably is), open ~/.kde4/share/config/kmixrc and set the MasterMixer= and MasterMixerDevice= entries in the [Global] section. MasterMixer specifies an equivalent to the ALSA card, but apparently 1-indexed (so here it was "ALSA::HD-Audio_Generic:1" and I set it to "ALSA::HD-Audio_Generic:2"), MasterMixerDevice tells the channel which should be controlled as Master ("IEC958:0" here, changed to "Master:0"). Simply look at the end of the section names and compare with the channels displayed in KMix beyond each tab (i.e. card), if you're unsure what entries to set.

Note: In later versions of KMix (IIRC around 4.15) this stopped to work, so I stayed on that version