elvito.de

Ich bin immer noch damit beschäftigt, die Geräte aus dem zweiten Subnetz in NetBox einzupflegen. Ich nutze inzwischen auch noch ein anderes Skript von Peter Eckel, mit dem man die DNS-Namen aus der Zone auf neu eingepflegte IP-Adressen übertragen kann. Das spart etwas Tipparbeit. Wenn das Skript läuft, habe ich nur zwei Unterscheidungskriterien: DNS-View (Pflichtfeld, hier habe ich nur einen Wert und es kommt kein neuer dazu) und VRFs, welche bisher noch leer waren. Ich würde das Skript gerne auf eines der beiden Subnetze beschränken, denn ohne VRFs läuft das Skript immer über alle DNS-Zonen.
VRFs (Virtual Routing & Forwarding) sind scheinbar Objekte in NetBox, die z. B. ein Subnetz (als Prefix), IP Adressen, aber auch Routing-Informationen zu anderen VRFs beinhalten können. Das scheint genau das zu sein, was ich später sowieso noch für die Abbildung der Überlappungen des Tailnets in beide Subnetze brauchen könnte.
Ich habe also VRF Standort 1 mit Subnetz 1 und allen korrespondierenden IPs verknüpft, VRF Standort 2 mit Subnetz 2 & IPs und VRF Tailscale mit den Tailscale IP Adressen von denen ich zu Testzwecken einige manuell angelegt habe. Werde ich vermutlich bald merken, ob das so richtig ist….

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

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.2.0/24 -j MASQUERADE

persistent machen mit

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

"hosts": {
    "netbox": "192.168.2.102",
    "dns-giesing": "192.168.3.2"
}

Man muss auch noch eine neue “action” bei den Tailscale-ACLs anlegen

{
    "action": "accept",
    "src": ["netbox"],
    "dst": ["dns-giesing:*"]
}

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.

Nach kurzer Recherche habe ich vom Macher (Peter Eckel, besten Dank an dieser Stelle) der DNS und DHCP Plugins für Netbox diese Scripte gefunden. Als erstes will ich mit dem Script

AXFR_Importer.py

meine bestehende DNS Zone von Technitium in Netbox zu importieren. Der nächste Schritt wäre dann, die DNS Änderungen die ich zukünftig nur noch in Netbox vornehme, in die andere Richtung auf den Technitium-Server zu übertragen. Das wiederhole ich mit dem Technitium-Server am zweiten Standort und habe ab diesem Zeitpunkt hoffentlich nie wieder DNS Probleme durch Fehlkonfiguration.
In Technitium erlaube ich bei den Zone Options zunächst den Zonentransfer zu allen Geräte in meinem Subnetz.

als nächstes muss das Script für den Import der Zone in Netbox eingefügt werden. Ich musste zuvor noch eine weitere Bibliothek (dulwich) nachinstallieren.

Nun kann ich das Repository von Herrn Eckel als Datenquelle für Scripts hinzufügen,

nach einem Klick auf Synchronisieren sollte keine Fehlermeldungen mehr erscheinen. Das Script kann ich nun einbinden, als Datenquelle gebe ich hier, das zuvor hinzugefügte Repo von Peter Eckel an. Als Datei wähle ich die oben erwähnte AXFR_Importer.py aus. Ich binde lieber das Repo ein, statt einfach nur die .py Datei hochzuladen (in dem Fall darauf achten, die raw Version runterzuladen) für den Fall, daß das Script irgendwann mal ein Update bekommt, kann ich die neue Version mit einem Klick direkt von Github aktualisieren.

Wenn man das Script nun ausführt öffnet sich ein neues Fenster in dem ich die zu übertragende DNS Zone und die IP Adresse des korrespondierenden (Technitium-)DNS-Servers angeben muss. Die Warnung bzgl des TSIG Schlüssel kann ich ignorieren, da ich zuhause (noch) keinen solchen Schlüssel nutze. Das Script bricht beim ersten Durchlauf zunächst mit einem Fehler ab und schon sehe ich den ersten Vorteil. Das Script importiert die Zone nur, wenn dort alles korrekt eingerichtet ist. Bei mir wird bemängelt, das in meiner Zone weder der SOA noch dem NS einen FQDN hat. Ich hatte bei beiden Einträge nur den Hostname gesetzt ohne den Rest. In der Tat habe ich hier scheinbar geschlampt (easy to learn, but hard to master) und es ist sehr schön, daß der Fehler nun aufgefallen ist und umgehend bei beiden Einträgen in Technitium korrigiert werden konnte. Der nächste Versuch schlägt wieder fehl, nun wird ein inkorrekter Hostname bemängelt.

Das ist scheinbar mein E-Golf, Volkswagen scheint genauso wie ich nicht gewusst zu haben, daß Unterstriche in DNS Namen explizit nicht erlaubt sind. Die Unterstriche werden nun umgehend in Bindestriche umgeändert. Man kann das Script scheinbar problemlos wiederkehrend aufrufen und so die Zoneneinträge regelmäßg prüfen (nope, das Script lässt sich nur einmal ausführen. Man müsste es selbst dahingehend erweitern). Aus meiner Sicht ist ein sehr großer Teil der sogenannten Netzwerkprobleme auf DNS Fehlkonfigurationen zurückzuführen und deswegen ist so ein Check Gold wert. Ein dritten Versuch ist schließlich erfolgreich

und alle Einträge wurden scheinbar übernommen 😎

Das ist schonmal ganz ausgezeichnet, ich werde den Beitrag noch ergänzen (z.B. PTR Einträge) sobald ich mit meinen Tests etwas weiter bin.

Inzwischen habe ich eines meiner beiden Subnetze manuell in Netbox eingepflegt. Das war eine ziemliche Klickerei und ich denke ich habe das Prinzip nun für alle Zeiten verinnerlicht. Bei meinem zweiten Subnetz möchte ich mir diese Arbeit nicht mehr machen, daher werde ich mal die beiden Netbox Plugins DNS & DHCP testen. Ich hoffe, daß ich damit den zweiten Technitium-Server irgendwie “automagicly” auslesen und beschreiben kann. Neulich hat mir jemand bei Discord erklärt, daß Anleitungen nur für Looser sind, daher installiere ich die beiden Plugins einfach mal und lese die Anleitung erst dann, wenn ich nicht mehr weiter komme. Das dürfte vermutlich in spätestens 15 Minuten der Fall sein. 😁
Die Installation der beiden Plugins und vermutlich aller weiteren erfordert ein bisschen Handarbeit.

Da Netbox bei mir in einem Proxmox LXC läuft, kann ich die Befehle von der jeweilgen Pluginbeschreibung einfach in der Proxmox Shell des LXCs mit Netbox der Reihe nach ausführen.

Wenn alles geklappt hat sollte ein neuer Reiter names DNS bei Netbox auftauchen und bei Plugins ein grüner Haken bei dem Plugin DNS auftauchen.

Das Gleiche werde ich noch mit dem DHCP Plugin machen. Ich bin schon gespannt zu erfahren, ob ich die Anleitung brauchen werde.

Nachtrag: 2 Minuten, ich bin scheinbar ein Looser 😂

Netbox sagt über sich selbst es könne als eine sogenannte “Single Source of Truth” fungieren. Man kann Netbox in diesem Kontext als Dokumentationswerkzeug für Geräte mit irgendeiner Art von Anschluss verstehen. Idealerweise steht dabei in Netbox die “Wahrheit” geschrieben, beispielsweise über das lokale Netzwerk und diese “Wahrheit” wird immer entsprechend an die verantworlichen Geräte/Dienste (z.B. Technitium) ausgerollt. Man kann so beispielsweise das gesamte Netzwerk in aller Ruhe vorab in Netbox planen und muss die so geplante Topologie dann nur noch an die verantwortlichen Dienste (DHCP, DNS usw.) ausrollen. Ab einer gewissen Komplexität und Größe macht so ein Vorgehen auch absolut Sinn. Dabei geht Netbox aber weit über bloße Netzwerkkonnektivität auf IP Ebene hinaus. Die Detailtiefe reicht bis zur konkreten Aderanzahl der Kabel und wenn man will sogar deren Farbe und Länge. Wie tief man gehen will kann man selbst entscheiden, passionierte Hobbybuchhalter können sich jedenfalls freuen…

Netbox prüft die eingetragenen Werte dabei stets auf Plausibilität, eine IP kann bei Netbox beispielsweise nicht doppelt vergeben werden.
Was die Sache dabei aber noch wesentlich interessanter macht, ist der Umstand, dass sich Netbox via API abfragen lässt und die Daten wahlweise als CSV oder JSON (soweit ich bisher weiß) geliefert werden. Solche Abfragen kann man via Plugin dann mit Ansible Playbooks verknüpfen. Man kann aber auch externe Daten via Ansible in Netbox bringen, womit einer Automatisierung vieler Aufgaben fast keine Grenzen mehr gesetzt sind.
Es gibt z.B. bei Youtube bereits zahlreiche gute Anleitungen, die zeigen wie man in Netbox Geräte einrichtet und an selbige eine oder mehrere IP Adressen vergibt. Ich werde nur beschreiben, welche Punkte ich selbst bei Netbox verwende (die wenigsten brauchen vermutlich die volle Detailtiefe) und diesen Part auch recht kurz halten.
Bei Netbox muss man zunächst die eigene Organisation definieren. Hier ist die oberste hierarchische Ebene die Region. Wenn man ein oder mehrere VPS in einem US Rechenzentrum stehen hat, würde es bereits Sinn machen hier zwischen Deutschland und USA eine Unterscheidung zu machen. Die nächste Ebene sind für mich Standorte, hier habe ich in D aktuell zwei. Die Lokationen sind in meinem Fall die konkreten Räume an den beiden Standorten. Wenn man sich in der Hierarchie von oben nach unten durcharbeitet, hat man in der nächsten Ebenen meist die notwendigen Dinge in den Dropdown Menüs zur Auswahl. Sollte ein nowendiges (die mit *) Dropdown Menü keine Auswahl bieten, so muss man zunächst die entsprechenden Auswahlmöglichkeiten eine Ebene höher anlegen. Man braucht sich wegen den anderen Werten absolut keinen Stress machen, alles lässt sich natürlich nachträglich ändern und die Änderungen werden rekursiv überallhin übernommen.
Ähnlich verhält es sich beim Anlegen neuer Geräte. Zunächst braucht man einen Hersteller (Z.B. Apple), als nächstes braucht man einen Gerätetyp (z.B. Mac Mini M1) und eine passende Geräterolle. Geräterolle ist zwingend vorgeschrieben, da die Vorauswahl scheinbar nicht passt, habe ich zwei neue Geräterollen in bestem Denglish als “Mobile User Endgerät” (Wifi) und “Static User Endgerät” (LAN Kabel) angelegt. (Wird sich vermutlich noch zeigen, ob das so richtig/sinnvoll ist) Erst nach diesen Vorarbeiten konnte ich ein neues physisches Gerät anlegen. (Beispiel)

Das neue Gerät hat mehrere Schnittstellen u.a. Wifi, LAN, USB, Bluetooth usw., in dem konkreten Beispiel gehe ich nur auf die LAN Schnittstellen ein, weitere Schnittstellen kann man bedarfsweise jederzeit auch noch nachträglich anlegen. Die neue Schnittstelle nenne ich schlicht LAN. Es kann bei den Schnittstellen durchaus mehrere namensgleiche Schnittstellen geben, unterschieden werden solche Schnittstellen dann anhand des zugeordneten physischen Gerätes und der ebenfalls zugeordneten MAC Adresse der jeweiligen Schnittstelle. Die MAC Adresse(n) bestimmter Geräte lassen sich zwar ändern (LXCs, VMs, Handies als Anti Tracking Maßnahme usw.) und sind vermutlich deswegen kein “Netbox Pflichtfeld”, ich nutze aber fast ausschließlich feste MAC Adressen und daher ist die MAC Adresse bei der Schnittstelle für mich persönlich ebenfalls ein “Pflichtfeld”. Ausserdem benötige ich die MAC Adresse später, wenn ich die IP Adressvergabe über Ansible/Netbox steuern will.

Zu guter Letzt kann man über den Punkt IPAM nun beim Unterpunkt IP Adressen eine neue IP Adresse anlegen (CIDR Notation ist Pflicht) und diese mit der soeben erstellten Schnittstelle verknüpfen.

Man kann einer Schnittstelle auch mehrere IP Adressen zuordnen, das benötigt man beispielsweise, wenn man auf dieser Schnittstelle zusätzlich ein VPN mit eigener IP nutzt o.ä.