Mit der Firmware 1.1.5 beginnt auch die Auftrennung der großen Netze (Kreis Gütersloh und Müritz/Feldberg/Neubrandenburg) in kleinere Segmente.
Konkret teilen wir das Netz im Kreis Gütersloh auf in die Segmente Stadtgebiet Gütersloh, Stadtgebiet Rheda-Wiedenbrück sowie »Nordkreis« und »Südkreis«.
Aus dem Netz in der Müritz-Region wird für den Bereich der Feldberger Seenlandschaft ein eigenes Segment eröffnet; Neubrandenburg (z. Zt. unter fünf Knoten) teilt sich bei anderer SSID weiterhin das Netz mit der Müritz-Region.
Damit einher gehen Änderungen auf der VPN-Tunnel-Ebene: Nachdem statt zwei nun sechs getrennte Netzsegmente existieren, benötigen wir einen größeren Wertebereich an freizuschaltenden sogenannten »Ports«: statt nur (UDP-) Port 10000 (Kreis Gütersloh) bzw. 10169 (Müritz/Feldberg/Nebrandenburg), nutzt unsere Firmware nun die Ports 10000 bis 10099, jenachdem, in welchem geographischen Bereich sie eingesetzt wird.
Insgesamt nutzt Firmware 1.1.5 damit diese Verbindungen über vorhandene Internetzugänge:
| Zweck | Protokoll | Zielport |
|---|---|---|
| Namensauflösung (DNS) | UDP, TCP | 53 |
| Statusabfragen | TCP | 80 |
| VPN-Tunnel | UDP | 10000 – 10099 |
Sollten wir das nicht in einem zweiten Schritt machen? Um erst einmal zu sehen, das alle Knoten in das neue Netz rüber kommen?
Sonst verlieren wir den überblick an welcher Stelle es hakt!
Wir sollten auch nicht vergessen, das u.U. viele Knoten Offline sind wegen dem Lockdown. So sieht es mir auf jeden Fall auf der Karte aus bei vielen die Langzeit Offline sind. (unter anderem sind einige Kneipen Offline, Fitnesstudios, und Vereinsheime, …)
Ist halt in der tng-FW drin; in der fastd-site.conf gehen alle ‘Domänen’, wie das im Gluon-Sprech heißt, entweder auf die 4 fastd-Server für GT oder die 2 für Müritz. In der l2tp-site.conf haben gut, gto, gt8, rhw sowie wrz/neb und fsl jeweils andere v6-ULA-Adressen und Gateways.
Kann man rückbauen, zumal eh’ noch eine weitere tng-Firmware nötig ist: mit dem Schwenk auf tng als stable soll tng ja eingestellt werden — aber dann würden heutige tng-Knoten niemals mehr Updates bekommen. (Gleiches gilt für den, an der Müritz oft eingesetzten, master-Branch.)
Firmwarebuild 1.1.5~42 (sic!) würde Autoupdater von tng auf rawhide und von master auf stable setzen — und noch kein Mesh-Splitting vornehmen. Dennoch ändern sich die Ports, für Kreis GT von 10000 auf 10001 (Mesh GT Stadt) und an der Müritz von 10169 auf 10005 (Mesh Müritz).
Einwände, Kommentare?
Meine bedenken sind eher wegen der Port Änderungen. Einen Fallback Server mit 10000 Port geht nicht, oder? (Evtl. auch ohne Funktionalität. So könnten wir dann aber gezielt die Knotenbetreiber ansprechen und würden dann nicht nur einen Offline Knoten sehen)
Ist aktuell nicht vorgesehen, sprich gibt keinen. (Und wenn, dann müßten es ja zwei sein, Müritz lief seit jeher auf 10169.)
Es geistert allerdings die Idee herum, daß die Knoten nach Erstinstallation in ein »Default-Mesh« kommen und aus diesem dann per zentraler Konfiguration ins »Ziel-Mesh« verschoben werden. Damit könnten die Veränderungen an der Gluon-Basis weiter reduziert werden, was die Adaption neuerer Versionen beschleunigen könnte. Und im Zweifel auch wieder Offline-Konfiguration möglich gemacht werden — wobei es dafür bislang keine Nachfrage gab …
Bei denen hatte ich vor, sofern eingetragen, die Kontaktmailadresse mit einem Hinweis auf die Änderungen (Link zu den Beiträgen) einmalig anzuschreiben; möglichst als individuelles Ticket zwecks Nachverfolgbarkeit.
Die alten fastd-Gateways könnten sicherlich noch bis 31.03.21 oder so weiter laufen; ich hatte auch nicht direkt vor, am 01.02.21 00:00 diese runterzufahren. Ein Enddatum würde ich aber schon setzen wollen, und sei es, um die (v4-) IPs wieder freizubekommen.
Fallback in dem Sinne geht mit der Ansible-basieren Automatisierung auch nicht. Die Portnummer ermittelt sich aus, Pseudocode, “Port=$Portbasis + $Domainnummer”. Domainnummer ist ein numerischer Wert, mehr oder weniger willkürlich in einer Konfigurationsdateil festgelegt für alle Meshes.
Natürlich kann man in der Firmware
l2tp-gut00.4830.org:10000bei den »NRW-Meshes« undl2tp-wrz00.4830.org:10169bei den »MeckPomm-Meshes« hinzufügen — und diese beiden Gateways bekäme man auch über Ansible deployed, denke ich.Nur: dann würden sich Knoten zufällig mit einem der Gateways verbinden, also entweder mit ihren »richtigen« Meshes (Lokalisierung Stadtgebiet GT über Port 10001, Nordkreis über 10003, …), ggf. aber auch mit dem Fallback-Gateway. Sprich: wir würden in Kauf nehmen, daß wir die eigentlich getrennten Meshes über Knoten bridgen könnten (zwei Knoten mit WLAN-Mesh und zwei Uplinks, einer nach 10001, einer nach 10000) oder von Knoten zu Knoten sich die dahinterliegende Infrastruktur ändert (anderer v4- und v6-Bereich), die Clients also beim AP-Wechsel offline gehen.
Gefühlt haben wir im Kreis GT keine Handvoll Knoten, die auf Port 10000 festgenagelt sind — es ist kaum nachgefragt worden, was freizuschalten sei. Ich weiß von einem Autohaus, wo das vor ~5 Jahren relevant war. Aber ja, wir wissen es nicht.