Auftrennung der Netze

**wusel** · 9. Januar 2021 um 08:17

Originally published at: https://freifunk-kreisgt.de/auftrennung-der-netze/

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

**Thomas** · 9. Januar 2021 um 12:23

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, …)

**wusel** · 9. Januar 2021 um 13:30

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?

**Thomas** · 9. Januar 2021 um 13:49

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)

**wusel** · 9. Januar 2021 um 17:01

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.

**wusel** · 9. Januar 2021 um 17:24

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:10000 bei den »NRW-Meshes« und l2tp-wrz00.4830.org:10169 bei 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.

**Thomas** · 9. Januar 2021 um 19:55

Hmm, OK, also Aufmerksam sein und schauen das wir alle mit bekommen.

Und dann das Netz stabil halten und schauen das wir bei neuen Knoten aktive Knotenaufsteller haben.

**wusel** · 9. Januar 2021 um 23:44

Ich denke, das geht relativ gut:

https://map03.4830.org/map_Freifunk%20KreisGT/ (fastd-Karte; rawhide updated auf L2TP-FW => Knoten gehen in fastd-Mesh offline):

Screenshot_2021-01-10%20Karte%20Freifunk%20KreisGT

https://newmap.4830.org/map_Freifunk%20KreisGT/ (L2TP-Karte; Knoten tauchen neu in L2TP-Mesh(es) auf):

Screenshot_2021-01-10%20Karte%20Freifunk%20KreisGT(1)

Ebenso Feldberg; aus Müritzer fastd-Karte raus …

… tauchen sie auf Feldberger Karte auf — zumindest bis auf zwei:

Screenshot_2021-01-10%20Karte%20Freifunk%20Feldberg

Hmm, 17258-HDG-Offloader hat’s schein’s nicht geschafft, und dadurch ist auch 17258-HDG-Tagungsraum wohl offline.

Screenshot_2021-01-10%20Karte%20Freifunk%20M%C3%BCritz%2017258-HDG-Offloader

Vielleicht weiß @charrr näheres? Bei den ERXen gibt’s ja ein seit Gluon v2020.1 bekanntes Problem (1.1.5~41 basiert aber noch auf Gluon 2018.2.x; keine Ahnung, ob es da auch zum Problem werden kann):

Upgrading EdgeRouter-X from versions before v2020.1.x may lead to a soft-bricked state due to bad blocks on the NAND flash which the NAND driver before this release does not handle well.

**charrr** · 10. Januar 2021 um 07:55

das hatte ich schon erwartet. dort muss noch die portfreigabe in der firewall geändert werden. werde mal kontakt zum it dienstleister von denen aufnehmen.

**charrr** · 10. Januar 2021 um 12:43

bleibt es denn bei port 10005/6 für fsl oder ist absehbar, dass sich das in nächster zeit nochmal ändert?

**Cord** · 10. Januar 2021 um 12:58

können wir die Links der funktionierenden Karten als Linksammlung z.B. auf https://map.4830.org/? Ich habe mittlerweile drölfzig Links wo Karten sein könnten, aber es nicht mehr sind.

**wusel** · 10. Januar 2021 um 15:18

Ja, der virtuelle Webserver map.4830.org wird wohl auf eine Webserver-VM (web01.4830.org oder so) umziehen, dort dann auf die neuen Ziele für die kommunizierten Links (map.4830.org/ffgt, map.4830.org/mueritz) zeigen (per redirect denke ich). hopglass.4830.org und die anderen temporären Mapserver werden dann wieder eingestampft.

BTW, irgendwas ist mit dem Tile-Caching auf newmap.4830.org im Argen

2a06:e881:260c:1:1202:b5ff:feb1:ae68 - - [10/Jan/2021:14:36:15 +0100] "GET /tiles_cache/osm_mapnik/12/2143/1353.png HTTP/2.0" 500 251 "https://newmap.4830.org/map_Freifunk%20KreisGT/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0"

Wäre klasse, wenn sich das jemand ansehen könnte; ich verstehe gerade nicht, was Nginx da hat.

Edit: Bzw. überhaupt, wie das Tile-Caching funktioniert; stammt alles aus Ansibe und tat 'ne zeitlang

**Cord** · 10. Januar 2021 um 15:22

Hallo! Du (Kai ‘wusel’ Siering via Freifunk Kreis GT) hast geschrieben:

BTW, irgendwas ist mit dem Tile-Caching auf newmap.4830.org im Argen

2a06:e881:260c:1:1202:b5ff:feb1:ae68 - - [10/Jan/2021:14:36:15 +0100] “GET /tiles_cache/osm_mapnik/12/2143/1353.png HTTP/2.0” 500 251 “https://newmap.4830.org/map_Freifunk%20KreisGT/” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0”

Wäre klasse, wenn sich das jemand ansehen könnte; ich verstehe gerade nicht, was Nginx da hat.

Fixed.

proxy_set_header Host $http_host;

darf NICHT gesetzt werden, sonst weiss OSM/Fastly nicht wo die Reise
hin gehen soll.

auskommentiert.

Cord

**wusel** · 10. Januar 2021 um 15:30

Danke!

**wusel** · 10. Januar 2021 um 15:35

Erm, bei mir nicht?

2a06:e881:260c:1:1202:b5ff:feb1:ae68 - - [10/Jan/2021:16:31:56 +0100] "GET /tiles_cache/osm_mapnik/12/2144/1356.png HTTP/2.0" 500 263 "https://newmap.4830.org/map_Freifunk%20KreisGT/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0"

Shift-Reloaded, root@newmap ~ # systemctl restart nginx.service gemacht. Still no tiles?

**Cord** · 10. Januar 2021 um 15:53

Hallo! Du (Kai ‘wusel’ Siering via Freifunk Kreis GT) hast geschrieben:

Erm, bei mir nicht?

2a06:e881:260c:1:1202:b5ff:feb1:ae68 - - [10/Jan/2021:16:31:56 +0100] “GET /tiles_cache/osm_mapnik/12/2144/1356.png HTTP/2.0” 500 263 “https://newmap.4830.org/map_Freifunk%20KreisGT/” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0”

Screenshot_2021-01-10 Karte Freifunk KreisGT(2).png1107×585 46.8 KB

Shift-Reloaded, root@newmap ~ # systemctl restart nginx.service gemacht. Still no tiles?

Please retry.

Ugly hack enabled…

    proxy_set_header    	Host a.tile.openstreetmap.org;

Cord

**wusel** · 10. Januar 2021 um 17:10

Works, danke! Lustig; hat sich da »kürzlich« was bei OSM geändert? Weil, initial läuft’s, aber auch auf map03.4830.org zeigen sich erste Ausfallerscheinungen. Und auch die Münsterländer Karte zeigt bei mir nur noch grau — ihr Ansible hat da auch noch den $host-Header drin.

**Cord** · 10. Januar 2021 um 19:38

Hallo! Du (Kai ‘wusel’ Siering via Freifunk Kreis GT) hast geschrieben:

Cord:

Ugly hack enabled…

Works, danke! Lustig; hat sich da »kürzlich« was bei OSM geändert? Weil, initial läuft’s, aber auch auf map03.4830.org zeigen sich erste Ausfallerscheinungen. Und auch die Münsterländer Karte zeigt bei mir nur noch grau — ihr Ansible hat da auch noch den $host-Header drin.

keine AHnung. Mittlerweile zeigen ([abc].)?tile.openstreetmap.org alle
auf fastly und immer auf dieselben IPs.

Damit das da funktionieren kann muss man den richtiugen Host-Header
mitschicken.

Vielleicht haben die kürzlich erst umgestellt? Muss wohl:

https://help.openstreetmap.org/questions/77894/were-experiencing-an-issue-where-our-leaflet-map-on-our-homepage-is-not-displaying-any-images-and-remains-entirely-blank-a-lot-of-500-errors-are-reported-from-the-chrome-developer-console
(zweite Antwort)

Cord

**wusel** · 10. Januar 2021 um 22:18

Okay, dann kann dies wohl weg:

upstreams:
   name: openstreetmap_backend
    servers:
     - a.tile.openstreetmap.org
     - b.tile.openstreetmap.org
     - c.tile.openstreetmap.org

**TomH** · 15. Februar 2021 um 00:52

Ist nginx intelligent genug damit der bei mehreren IPs auch mehrere durchprobiert falls eine mal fehlschlägt?

Bei [a-c].tile.openstreetmap.org bestünde immerhin die Chance das da verschieden aufgelöst wird.