Am Wochenende haben wir das Wiki und das WordPress auf eine andere VM umgezogen, damit diese unabhängig vom Gatewaybetrieb sind. Bei der Gelegenheit haben wir auch gleich Zertifakte von Letsencrypt verwendet. Das Kontaktformular funktioniert derzeit noch nicht. Wenn sonst noch etwas fehlt oder falsch verlinkt ist, lasst es uns wissen.
Seit Freitag haben wir auch Probleme mit unserer Karte, die wir uns nicht erklären können. Das Netz selbst funktioniert aber. Wir arbeiten drann!

Update: Die Karte geht wieder! Was genau die Ursache war, wissen wir nicht, aber  das Gateway, auf dem die Karte läuft (vpn6), hat jetzt mehr direkte Verbindungen zu anderen Gateways und damit läuft es jetzt wieder.

Da mit immer mehr Knoten und Geräten in unserem Netz die vorhandenen VPN-Tunnel nicht mehr ausreichten, haben wir uns letztes Jahr dazu entschlossen, diese durch einen Anschluss an den Backbone des Freifunk Rheinland zu ersetzen.  Leider hat das ganze aus zeitlichen Gründen etwas länger gedauert als geplant, aber seit ein paar Wochen ist vpn1 angeschlossen und diese Woche folgte vpn6. Dafür haben wir von Freifunk Rheinland vier öffentliche IPv4-Adressen bekommen, mit denen wir auf den Gateways NAT machen. Da die Gateways über mehrere Tunnel verbunden sind, ist auch noch eine Redundanz vorhanden. Im moment wickeln wir nur IPv4 über das Rheinland-Backbone ab, IPv6 geht nach wie vor über das Intercity-VPN zum Förderverein freie Netzwerke. Wir als Freifunk Bielefeld müssen dafür nichts bezahlen, was aber nicht bedeutet, dass das alles kostenlos ist! Die Backbone-Admins stecken sehr viel Zeit und Arbeit in das Projekt und auch die RIPE-Mitgliedschaft muss irgendwie bezahlt werden. Wenn ihr also etwas Geld übrig habt, könnt ihr ganz unkompliziert steuerlich absetzbar über Betterplace an den Freifunk Rheinland spenden, vor allem weil demnächst der dritte Standort in Frankfurt komplett neu aufgebaut werden muss. Es kommt auch uns zu gute.

Gleichzeitig arbeiten wir im Hintergrund an der Verbesserung unserer eigenen Serverinfrastruktur. Als Ansporn dient uns dabei die Struktur von Gütersloh. Mit der Zeit reichen die kleinen VMs einfach nicht mehr aus. Eine schmerzhafte Erfahrung mit Hetzner zeigte, dass größere VM nicht unbedingt besser sind. Der Schluss daraus war, dass auf Dauer ohne eigenes Blech die Performance mies ist. Bis das ganze Konzept aber endgültig umgesetzt sein wird, werden noch einige Monate vergehen. Bleibt gespannt!

Vor zwei Wochen haben wir die Knoten im alten Netz aktualisiert und auch die meisten erwischt. Sechs Knoten gibts aber immer noch, wie auf der alten Karte zu sehen: http://vpn2.freifunk-bielefeld.de/graph.html

Da wir vor haben, am Wochenende auch noch das letzte verbliebene Gateway im alten Netz abzuschalten, werden die Knoten danach keine Verbindung mehr zum Freifunknetz haben. Bitte aktualisiert daher die Firmware. Entsprechende Images findet ihr hier.

Disclaimer:  Dieser Blogartikel spiegelt nicht die Meinung von Freifunk Bielefeld wieder

Ich gebe zu, der Blogeintrag von kinolux ist schon fast einen Monat alt, aber ich muss dazu auch mal was schreiben, da das Thema immer wieder hochkommt.  Ich gehe bewusst nicht auf alle Kritikpunkte ein, einige sind auch durchaus berechtigt, andere dagegen nicht.

Es war einmal vor einer langen Zeit, als wissenschaftliche Einrichtungen einen Weg suchten, effizient Daten untereinander auszutauschen. Zuerst passierte das mit UUCP, aber irgendwann merkte man, dass sich TCP/IP besser dafür eignete. Nur, wie tauschte man die Routinginformationen aus? Jede Einrichtung wollte natürlich eigenständig bei ihrer IT bleiben, also schuf man sogenannte autonome Systeme, die unter der Verwaltung einer Entität stehen, per Border Gateway Protocol zusammengeschlossen werden können und trotzdem eigenständig bleiben. Die Anzahl der zusammengeschlossenen autonomen Systeme wuchs und auch die Privatwirtschaft interessierte sich immer mehr dafür. Heute nennen wir diesen Zusammenschluss Internet, „Interconnected Networks“.

Freifunk und ISP-sein weiterlesen →

Wie wir richtig vermutet haben, lag das Problem bei fastd: Da unsere Gateways seit kurzem auch DNS-Einträge für IPv6 haben, hat fastd zuerst eine Verbindung über IPv6 versucht, auch wenn das nicht vorhanden war. Da in der 0.2-Firmware noch eine ältere Version von fastd zum Einsatz kommt, in der der Fallback auf IPv4 kaputt ist, konnten die Knoten überhaupt keine Verbindung zu unserem Netz aufbauen. Das Problem wurde bereits letztes Jahr in fastd 11 gelöst.

Nachtrag: Das soll euch natürlich nicht davon hindern, eure Knoten zu aktualisieren, dann gibts auch einen tollen Autoupdater 😉