Die Logs laufen nun von allen PVEs (an beiden Standorten), der lokalen Netbox-Instanz und dem lokalen Technitium-Server bei Loki zusammen. Der Technitium-Server am anderen Standort kann jedoch seine Logs aktuell noch nicht an Loki (läuft in meinem Heimnetz) schicken. Bei den anderen Instanzen war dies kein Problem, denn Tailscale ist auf allen PVEs installiert und fungiert mit den beiden TS-Subnet-Routern als Transportschicht ins entfernte Subnetz.
Auf meinen Technitium-Servern möchte ich kein Tailscale installieren, daher bleibt mir nur der Trick mit dem Tailscale-Tunnel, diesmal jedoch in die andere Richtung. Das ist eh nicht verkehrt, den Weg zusätzlich einzurichten, ich kann damit jederzeit weiteren Geräten/LXCs/VMs eine Verbindung ins jeweils andere Subnet geben, ohne extra Tailscale installieren zu müssen. Ich habe auch bereits einen Weg gefunden, solche Routen in Netbox abzubilden, das werde ich aber erst angehen, sobald die Fernsteuerung per Ansible funktioniert.
Zunächst lege ich in den Tailscale-ACLs einen neuen Host namens loki an und weise ihm die tatsächliche LAN-IP-Adresse zu. Ich muss zusätzlich eine neue Action in den ACLs definieren. Die Änderungen in den ACLs sollten anhand der Screenshots selbsterklärend sein.
Nun trage ich die Route vom externen Technitium-Server (dns-giesing) in mein Heimnetz ein. Ich wechsele dazu in die Shell von dns-giesing und setze zunächst eine temporäre Route. Wenn es funktioniert, mache ich die Route persistent.
ip route add 192.168.2.0/24 via 192.168.3.67
Die IP-Adresse 192.168.3.67 gehört dem LXC mit Tailscale, das als Tailscale-Subnet-Router und Exit-Node im entfernten Subnetz fungiert. Mit
ip route show
kann man die aktuell gesetzte Route kontrollieren.
Nur zum Spaß teste ich einen Ping bereits vor der iptables-Regel auf dem TS-Subnet-Router hier im Heimnetz und stelle entsetzt fest, dass der Ping bereits jetzt durchgegangen ist… Ich vermute, das liegt an den TS-eigenen Masquerading-, SNAT- und sonstigen Geschichten, die da im Hintergrund laufen. (Hier steht die Erklärung, SNAT war die richtige Vermutung) Ich setze auf dem TS-Subnet-Router in meinem Heimnetz die iptables-Regel mit Masquerading trotzdem. Die Verbindung sollte dann auch noch funktionieren, wenn ich irgendwann mal etwas an der globalen Tailscale-SNAT-Einstellung ändere.
Der Ping geht nun vom entfernten Technitium-LXC zu meinem lokalen Loki-LXC.
Optimal! Nun mache ich noch die Änderungen persistent, auf dem LXC im Heimnetz mit dem TS-Subnet-Router.
apt install iptables-persistent -y
netfilter-persistent save
und auf dns-giesing (Technitium) noch die Route fest in die /etc/network/interfaces eintragen:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.3.2/24
gateway 192.168.3.1
post-up ip route add 192.168.2.0/24 via 192.168.3.67
Ich habe inzwischen fast alle Geräte von beiden Subnetzen in Netbox erfasst. Zusätzlich habe ich in IPAM den Schnittstellen der Geräte die aktuell gültigen IP-Adressen zugeordnet. Die beiden DNS-Zonen (inkl. der aktuell verwendeten DNS-Namen) habe ich ja bereits im Vorfeld von den beiden Technitium-Servern in Netbox abgerufen. Peter Eckel hat noch ein weiteres praktisches Script geschrieben, das man genauso in Netbox einbindet, wie das bereits zuvor erwähnte Script. Es erscheinen nun zwei neue Auswahlmöglichkeiten
Mit IPAM Hostname Updater kann man die Hostnamen aus der zuvor importierten Zone(n) in die einzelnen manuell angelegten IPAM-Einträge importieren. Die Hostnamen werden nur in IPAM übernommen, wenn man zusätzlich den Haken bei Overwrite setzt, andernfalls wird nur ein „dry run” durchgeführt. Das Script kann man beliebig oft ausführen.
Sind nur wenige Geräte im Netzwerk, geht es vermutlich schneller, die Hostnamen von Hand einzutragen. In meinem Fall waren es aber so viele Hostnamen, dass sich der Aufwand mit den Scripten von Peter Eckel gelohnt hat. Sobald alle IPAM-Einträge (mithilfe des Scripts) einen Eintrag für den Hostnamen bekommen haben, kann man in Netbox-DNS alle importierten A-Records (SOA und NS nicht löschen) in den DNS-Zonen wieder löschen (ergibt Sinn… s.u.).
In Zukunft möchte ich, um z. B. die IP für ein Gerät zu ändern, nur noch eine Änderung im Bereich IPAM bei Netbox vornehmen müssen. Die Einträge in der DNS-Zone (inkl. PTR) sollen dann von dem DNS-Plugin in Netbox automatisch mit angepasst werden. Für die PTR-Einträge meiner beiden Zonen brauche ich vorher noch jeweils eine passende Reverse-Zone. Die beiden Reverse-Zonen lege ich manuell an. Im Screenshot habe ich eine Reverse-Zone für den Adressbereich 192.168.1.0/24 angelegt. Die Screenshots in meinen Beiträgen passen leider nicht immer 100 % zum Text.
Damit das Netbox-DNS-Plugin diese Änderungen vornehmen kann, muss man im Reiter des DNS-Plugins unter Ansichten (Views) noch die gewünschten IPAM-Prefixe angeben, sonst erfolgen keine dynamischen Updates der DNS-/PTR-Einträge. Ich habe hier die Prefixe meiner beider Zone angegeben.
Eine Änderung der IP Adresse eines Geräts in IPAM, führt nun auch zu einer sofortigen Änderungen bei den DNS Einträgen (inkl. PTR). Als nächstes muss der DHCP Teil in Netbox erldigt werden, danach kann ich mich mit der Übertragung an die beiden Technitium Server via Semaphore/Ansible kümmern.
Der Zonentransfer im LAN hat gut geklappt, allerdings kann ich die Zone von dem DNS-Server aus dem entfernten Subnetz (noch) nicht abrufen, da das NetBox-LXC ja keine Verbindung zum anderen Standort hat. Tailscale will ich in dem LXC mit NetBox nicht installieren, also musste ich etwas tricksen.
Ich hatte in beiden Subnetzen bereits ein eigenes LXC mit Debian 13 und Tailscale installiert. Beide LXCs fungieren am jeweiligen Standort als Tailscale Subnet Router und Exit Nodes. Gestartet wurden die beiden mit
# auf ts-subnet-standort1
tailscale up --accept-routes --advertise-exit-node --advertise-routes=192.168.2.0/24
# auf ts-subnet-standort2
tailscale up --accept-routes --advertise-exit-node --advertise-routes=192.168.3.0/24
NetBox läuft im Subnetz 192.168.2.0/24 und soll den DNS-Server mit der IP 192.168.3.2 über einen Tunnel zwischen den beiden LXCs erreichen können. Damit die IP-Pakete bei der Rückantwort von Standort 2 an Standort 1 wieder zur richtigen IP-Adresse (von NetBox) zurückgeleitet werden, braucht es noch eine Masquerading-Regel in iptables. In der Shell des TS-Subnet-Router-LXCs an Standort 2 setze ich die notwendige Regel zunächst temporär
apt install iptables-persistent -y
netfilter-persistent save
Nun muss man die ACLs in Tailscale ein bisschen ergänzen. Die beiden Geräte müssen mit der jeweiligen LAN-IP eingetragen werden, in meinem Fall muss der Teil mit hosts folgendermaßen ergänzt werden
Das Prinzip ist ziemlich cool, weil ich einfach bei hosts und der neu angelegten action weitere Geräte aus dem Subnetz von Standort 2 eintragen und so NetBox darauf Zugriff geben kann. Zu guter Letzt muss ich noch in dem NetBox-LXC die Route ins Subnetz 192.168.3.0/24 eintragen. Temporär zu Testzwecken reicht bis zum nächsten Reboot ein
ip route add 192.168.3.0/24 via 192.168.2.128
Ich habe die Route gleich fest in die /etc/network/interfaces eingetragen, diese sieht nun so bei mir aus
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
post-up ip route add 192.168.3.0/24 via 192.168.2.128
Die IP-Adresse 192.168.2.128 ist in dem Beispiel die IP-Adresse des LXC mit Tailscale, das bei mir zuhause als Subnet Router fungiert. Wenn alles geklappt hat, sollte man aus dem NetBox-LXC den DNS-Server am entfernten Standort anpingen können. Wie man auf dem Screenshot sieht, läuft kein Tailscale in dem NetBox-LXC.
Den Zonentransfer muss man bei dem zweiten Technitium-Server auch erlauben, in dem Fall ebenfalls für das eigene Subnetz (192.168.3.0/24), da es für Technitium an Standort 2 so aussieht, als ob die Anfrage von dem Tailscale-LXC von Standort 2 kommt. Der Import der zweiten Zone hat somit ebenfalls ausgezeichnet geklappt.
Das neue Blog hat mir auch gleich ein erstes Problem beschert 😃 Ich nutze traefik um einige Dienste (z.B. immich und navidrome) unter einer leicht zu merkenden Adresse via Tailscale verfügbar zu machen. Dazu habe ich bereits vor Längerem traefik zusammen mit Tailscale in einem LXC installiert. Bei All-inkl. habe ich unter der Domain elvito.de einen zusätzlichen DNS a Record gesetzt (*.ts.elvito.de), der auf die Tailscale IP des LXC mit traefik zeigt. In traefik kann ich nun je nach vorangestelltem Namen den Netzwerkverkehr an die Dienste im LAN weiterleiten inkl. Loadbalancing etc. Ziemlich praktisch bisher und man kann das ganz leicht beliebig skalieren.
Seit heute nutze ich die Doimain nun auch für dieses Blog und auf einmal waren die traefik Dienste nicht mehr über den Browser erreichbar. Ich habe für den Blog natürlich SSL aktiviert und habe hier das Problem vermutet, traefik lief bisher mit http und das soll nach Möglichkeit auch so bleiben. Eine kurze Recherche hat gezeigt, dass in einem Flatpress Plugin (FlatPress Protect), welches zur Absicherung der Seite dient, das Problem lokalisiert ist.
Es muss nur eine Zeile in der /fp-plugins/fpprotect/plugin.fpprotect.php angepasst werden:
Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
muss zu
Header always set Strict-Transport-Security "max-age=15552000"
geändert werden, damit Flatpress im Browser für *.ts.elvito.de nicht ebenfalls https zu erzwingen versucht. Die Sicherheit des Blogs wird dadurch nicht kompromitiert und auf/über die Domain läuft sonst nichts anderes.
Bei Vivaldi musste ich noch die Domain Security Policy löschen, man erreicht diese Einstellungsmöglichkeit bei Vivaldi über die Adresse vivaldi:net-internals/#hsts. Bei allen chromebasierten Browsern wäre auch chrome:net-internals/#hsts möglich.
Passt, nun sind Navidrome & Co. auch wieder über den Browser unter http erreichbar.
