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.
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.
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.
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.
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.
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.
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“?)
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.