Workflows

fastd-keys

Damit die Nodes eine VPN-Verbindung aufbauen können, muss der öffentliche fastd Schlüssel auf die Gateways gelangen.

Wir verwalten diese Keys in Git-Repositories:

Bei dem ersten Start der Gluon Node wird ein fastd Schlüsselpaar erzeugt.

Im Beschreibungstext steht, man solle den erzeugten öffentlichen Schlüssel per Mail an unsere Listen schicken. Alternativ lässt sich auch ein Link klicken, der das Email-Programm öffnet und eine neue Mail ausfüllt.

  • Mainz: keys (at) freifunk-mainz.de

  • Wiesbaden: keys (at) freifunk-wiesbaden.de

Die Empfänger dieser Liste sind am Besten auch Mitglieder des fastd-keys GitHub Teams - Mitglieder dieser Gruppe haben Schreibrechte auf die peers Repositories.

Die neuen Keys von der Liste werden wie unten gezeigt lokal eingetragen, die Änderungen wie gewohnt gepusht.

Bemerkung

Damit der Nodebesitzer und die anderen Empfänger der Keys-Listen bescheid wissen, muss nach dem Eintragen der Keys die Mail beantwortet werden. Den Nodebesitzer ins To:-Feld, keys@freifunk-... ins CC: (Oder einfach auf Reply-All klicken..).

Alle 15 Minuten kommt ein Script vorbei und synchronisiert die neuen Keys von GitHub auf die Gateways.

Siehe auch

fastd-keys Format

Ein fastd-key ist ein 64-Zeichen langer HEX-String:

0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

Damit der fastd-daemon den Schlüssel lesen kann, muss noch etwas Syntax drum rum:

key "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef";

Bei Start oder Neuladen des fastd-daemons wird das Config-File neu eingelesen. In diesem steht, fastd möge zusätzlich noch alle Dateien aus dem peers-Ordner mit einlesen (== peers-… .git Repository).

fastd nimmt den Dateinamen des keys als peer name. Hat die Node z.B. den Namen Wurstsalat ist die Struktur denkbar einfach:

  • Dateiname: Wurstsalat:

    key "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef";
    

Einige Dateinamen werden zur einfachen Zuordnung mit einem Prefix markiert. In Benutzung/Angedacht sind:

gw

Für Gateways (gw_Lotuswurzel, gw_Spinat).

srv

Für Dienste-Server (srv_Aubergine).

chaos

Für Nodes im cccmz (chaos_Haggis).

peng

Für Nodes im pengland.

exitVPN Accounts

Anfragen aus dem Freifunknetz in das Internet tunneln wir durch das exitVPN, um die Störerhaftung zu umgehen.

Dies hat den Vorteil, dass Anfragen in das Internet anonymisiert werden, Anbieter sehen nur dass die Anfrage aus dem Freifunk-Netz kommt.

Hierbei handelt es sich um OpenVPN-Angebote, meist in Schweden oder Niederlande.

Diese werden im Vorraus gezahlt, und müssen von Hand aufgeladen werden.

Problem - Dies wird all zu gerne verpeilt!

Im gateway-configs.git findet sich eine exitvpn.yaml

Dort wird pro Gateway hinterlegt, welcher VPN-Account hinterlegt ist, und bis zu welchem Datum dieser bezahlt ist.

Einmal tägtlich kommt ein Script vorbei, und schreibt bei nähern des Datums Mails auf die admin@-Listen, ansonsten wird ein mal pro Woche eine Übersicht verschickt.

Firmware updates

Firmware updates müssen nach dem kompilieren noch signiert werden. So stellt Gluon die Integrität der Firmware Dateien sicher. Dazu wird die manifest datei, die Teil jedes kompilierten Gluon releases ist mittels ecdsasign signiert. Je nach Einstellungen in der site.conf und je nach build (experimental, beta, stable) sind eine verschiedene Anzahl von signaturen nötig.

Ecdsa utils intallieren & Key generieren

Siehe hier: http://wiki.freifunk-flensburg.de/wiki/ECDSA_Util

Der öffentliche Schlüssel muss dann noch in die site.conf im imagebuilder eingetragen werden.

Firmware signieren

Man braucht den Inhalt aus der manifest Datei, vom Anfang bis zum Ende Der Dateinamen der Router (also bis zum —–). Diesen speichert man ab und generiert die Signatur mit:

ecdsasign manifest < $private_keyfile

Die erhaltene Signatur fügt man jetzt unten an die manifest Datei an (unter dem —–) an.