Freifunk VM Verbindungsverlust um 4h30 (nach Autoupdater-Lauf)

Hallo zusammen,

wir betreiben seid einiger Zeit erfolgreich Freifunk bei uns in der Firma.
Dafür haben wir eine VM mit Gluon laufen, die zwei Netzwerkkarten hat.
Viele Accesspoints leiten die Clients dann durch die VM ins Freifunk Netz.

Leider haben wir nun folgendes Problem seit einer Woche.
Regelmäßig um 4:30 verlieren die Clients die Verbindung und bekommen keine neue Adresse.
Dies kann man ganz gut im Grafana nachvollziehen.

FreifunkMap
https://grafana.ffac.rocks/d/000000002/node?refresh=1m&orgId=1&var-node=005056b834c4&from=now-12h&to=now-1m

Merkwürdigerweise hat ein Workaround funktioniert der aktuell keinen Sinn für uns ergibt.

Wir löschen die VM nun beim Fehlerfall morgens um 4:30.
Dann nehmen wir ein Backup der VM mit Gluon vom 11.12. Aus diesem Backup wird die VM wiederhergestellt. Clients bekommen nun wieder IP-Adressen aus dem Freifunknetz. Bis 4:30 dann wieder die Verbindung verloren geht.

Hallo,

in diesem Zeitfenster beziehen die Knoten ihr Update auf die aktuelle Freifunk Version.

Ab morgen werden sie zu beliebigen Zeiten ein Update beziehen.

Nun, da ich von den Problemen hören, meine ich mich zu erinnern, dass bestimmte VMs dabei die Mac Adresse, die für die Verbindung ins Internet genutzt wird ändern könnten.

Gibt es hier vielleicht einen Filter, der dadurch den Internetzugang sperrt?

Das ist ein 2016er Image ( 2016.2.7-1-stable / gluon-v2016.2.7) — war da nicht was mit Imagegrößen post-2016.2?

Ahja, ab 2017.1: “Another potential issue mostly affects virtual machines: Gluon 2017.1 images are bigger than 2016.2.x images on x86. If your virtual harddisk is based on a 2016.2.x image, it must be resized to 273MB or bigger before upgrading to Gluon 2017.1. Using qemu, the command qemu-img resize $IMAGE 273MB can be used to do this." Würde ja zum Fehlerbild passen.

Das kann hier nicht der Fehler sein, wir fangen dies mit einem Zwischenupdate ab.

Das ist ein 2018.2.3-2 Image das auf die alte Größe gepatcht ist, es prüft beim weiteren Update auf 2019.1 ob das Image groß genug ist. Nur wenn das der Fall ist wird es ausgeführt, ansonsten wir das bestehende Release umbenannt zu 2018.2.3-2-stable-small und auch der Server Update Pfad geändert.

Die von dir genannte Anpassung ist trotzdem sinnvoll, damit der normale Update Pfad beschritten werden kann.

1 „Gefällt mir“

Anscheinend hat es wirklich mit dem Updateprozess zu tun. Wir hatten am Anfang die kleine Version zum Testen genommen und, nachdem alles lief, nichts mehr dran geändert. Deswegen haben wir danach auch nicht mehr geschaut. Leider haben wir auch gesagt, dass es sich automatisch updaten darf. Ich probiere mal verschiedene Sache aus und schaue später nochmal drüber. Aktuell versuche ich es mit der 2019.1-1

In der Konfiguration hab ich auch vorgefunden, dass ich damals anscheinend einfach zum ausprobieren irgendwelche DNS Server eingetragen habe, die ich irgendwo in den Freifunk foren vorgefunden hatte.

Und sobald es dann wirklich funktionierte, war ich zu ängstlich etwas zu ändern.

Aktuell besteht die Liste aus folgenden Servern:

10.151.192.1
10.156.200.1
10.145.208.1
10.145.216.1
10.5.0.1
10.5.4.1
10.5.8.1
10.5.12.1
8.8.8.8

Macht das Sinn?

IIRC werden bei Unixen nur drei Einträge in /etc/resolv.conf unterstützt, ob davon die ersten oder die letzten drei dann genutzt werden, weiß ich gerade nicht.

1 „Gefällt mir“

Ein Großteil der 10.er sind keine DNS Server und waren es auch nie. Zudem wird der DNS im Freifunk Knoten nur verwendet um die VPN Verbindung herzustellen. Diese netzinternen IP Adressen können jedoch ohne VPN nicht erreicht werden.

Hier gehört daher der lokal verfügbare DNS Server rein.

Der Google DNS 8.8.8.8 sollte erreichbar sein.

Vielleicht wurde diese sehr ungewöhnliche DNS Liste früher anders verarbeitet.

Daher bitte alter 10. Adressen löschen und am besten den lokalen DNS hinzufügen.

Ich melde mich nächste Woche wieder ob es nun Stabil läuft. Schonmal vielen Dank für die Antworten und frohe Festtage.

1 „Gefällt mir“

Alles Stabil. Vielen Dank.

1 „Gefällt mir“

Das klingt ziemlich ungewöhnlich.
Warum sollte man so etwas manuell konfigurieren wollen?
Der DNS für das VPN-Setup wird per DHCP bezogen.
Wenn man versucht, darin herumzurühren, dann sollte man sein Setup wirklich verstanden haben und vor allem langfristig sets „up to date“ bleiben, da sich so etwas auch mal ändern kann bei Updates der Firmware.

Aber zur Ursprungsfrage zurück: Was war denn nun der eigentliche Auslöser für das Problem?
Sich nach dem Update ändernde Mac-Adresse des VPN-Interfaces?
(aka „Freifunk hinter restriktiver Firewall-> Fußschuss von Routeraufstellenden, die die bevorstehenden Änderungen im Freifunk-Netz nicht rechtzeitig durch Firewalländerungen erlaubt haben“?)

1 „Gefällt mir“

Soweit ich das verstanden habe, war es einfach nur das Autoupdate. Wenn dies deaktiviert ist, funktioniert alles.

Oh, das ist eine schlechte Lösung. Nach Möglichkeit sollte das Autoupdate aktiv sein und stattdessen der Fehler gefunden werden.

Also beispielsweise der DNS Server automatisch bezogen oder zumindest alle 10.x.x.x Server gelöscht werden.

Auf mittlerer Sicht wird sich am Freifunk Netz in der Region einiges ändern um auf dem Stand der Technik zu bleiben und weiter wachsen zu können.

5 „Gefällt mir“

Also Hinweis: Einige Domains schließen Knoten mit alten Batman-Versionen explizit aus (gibt da verschiedene Möglichkeiten), um z.B. die Multicast-Optimierungen im Batman aktivieren zu können ohne häßliche Seiteneffekte.
Updates sind also häufig mehr als sinnvoll.

Wir werden die VM demnächst neu aufsetzen mit der aktuellsten Version. Ein automatisches Update würde uns momentan alles zerschießen.

2 „Gefällt mir“