wiki/Technik/Netzinfrastruktur/Supernodes/fastd.page

---
format: markdown
categories: Netz-Infrastruktur, Backbone, Supernodes
title: Fastd
...

*Fast and Secure Tunneling Daemon.*

## Konfiguration Ruhr

Es gibt zwei [Fastd](https://projects.universe-factory.net/projects/fastd/wiki)-Instanzen, eine für Nodes (Port 10000) und eine für Supernodes untereinander (Port 10001). Ein Fastd-Prozess kann nur eine CPU nutzen, deshalb ist Fastd der limitierende Faktor für die Skalierbarkeit von Supernodes. Fastd performt auf Blech nicht viel besser als virtualisiert, aus nicht ersichtlichen Gründen hat man nur 5% mehr Clients als in den jetztigen VMs hingekriegt, danach wurde das System spürbar beeinträchtigt. Deshalb wurde die Entscheidung getroffen, Supernodes zu virtualisieren um die Hardware besser auslasten zu können.

Über ein Status-Socket können Zustand und Statistiken eines laufenden Fastd abgefragt werden. Dies wird derzeit nur manuell durch Scripte zum Debuggen genutzt. Eine Statistik über Auslastungen und andere ausgespuckte Metriken erzeugen zu können wäre schön, hat aber noch niemand realisiert bisher.

Bei Konfigurationsänderungen an der `fastd.conf` einer Instanz muss der Fastd durchgestartet werden und die Clients verlieren die Verbindung, das gilt aber nicht für per `include`-Anweisung eingebundene Fragmente, die über ein `SIGHUP` neu eingelesen werden können.

### Client-Instanz (Port 10000)

* Diese Instanz wird von den Nodes genutzt, Konfiguration liegt in `/etc/fastd/ruhrgebiet/`.
* Verschlüsselung: `salsa2012+umac`, momentan ist noch `null` erlaubt, aber die Nodes erzwingen Verschlüsselung. `null` kann also eigentlich raus und war nur aus Kompatibilitätsgründen eingetragen.
* Das bereitgestellte Interface `tap0` nimmt am batman-adv Mesh teil. 
* Bei jedem eingehenden Verbindungsaufbau wird von Fastd ein Shell-Script aufgerufen, welches den Fingerprint (?) des Client-Keys übergeben bekommt. Anhand des Rückgabewertes des Scriptes wird entschieden, ob die Verbindung zugelassen wird.
    * Das Script prüft lediglich gegen eine Blacklist, ob ein Client explizit gesperrt ist, alle anderen Verbindungen werden zugelassen.
        * Die Blacklist wird alle 5 Minuten durch einen Cron-Job mit `wget` von https://github.com/ffruhr/fastdbl aktualisiert.
    * Früher war hier ein Verzeichnis mit Keys eingetragen. Da Fastd nicht startet, wenn kein Key-Verzeichnis angegeben wird, ist immernoch ein Dummy-Verzeichnis vorhanden und in die Konfiguration eingetragen.
* Durch die Option `hide ip addresses yes` wird das Logging der Quell-IPs von verbundenen Clients zwecks Datensparsamkeit verhindert.
    * Der Status Socket reicht auf Anfrage trotzdem die IPs von aktuell verbundenen Clients mit raus. 
* MTU im Tunnel ist 1364 entspricht Transport-MTU 1450

### Supernode-Instanz (Port 10001)

* Hier ist die Liste der Peers auf jedem Supernode fest eingetragen und besteht aus den anderen Dortmund-Supernodes und dem Map-Server. Andere Peers werden nicht zugelassen. Jeder Server hat eine Verbindung mit jedem anderen Server.
* Dass hier Fastd genutzt wird ist historisch so entstanden aber kein muss. Hauptsache, wir haben ein Layer 2 zwischen den geographisch verteilten Supernodes.
* Die Datenübertragung erfolgt Unverschlüsselt (`method "null"`).
* Das bereitgestellte Interface `tap1` bildet effektiv ein Layer 2 zwischen den betiligten Supernodes/Map-Server und nimmt am batman-adv Mesh teil.
* BGP-Sessions zwischen allen Servern werden über diese Verbindung (bzw. das hindurch laufende batman-adv) gefahren.
* In der `on up`-Anweisung dieser Instanz wird fast die gesamte FF-spezifische Netzwerkkonfiguration durchgeführt. 
    * Einiges wurde schon nach `/etc/network/interfaces` migriert, es sind aber trotzdem noch Anweisungen drin, die woanders besser aufgehoben sind oder gar nicht vom Status des Interfaces `tap1` abhängen.
    * `alfred` und `batadv-vis` müssen eigentlich nicht mehr von Fastd gestartet werden, das war so weil die `br0` früher auch von Fastd angelegt wurde.

## Konfiguration Dortmund

Auf den dortmunder Supernodes laufen zwei Fastd-Instanzen für die Clients. Diese hören auf Port 10000 (/etc/fastd/do00) und 10001 (/etc/fastd/do01), ansonsten ist die Konfiguration identisch. 

 * Vorteile
    * Ausnutzung beider CPUs
    * Dadurch mehr Client-Verbindungen möglich
 * Nachteile
    * Es besteht die Gefahr, dass ein Client sich 2x zur gleichen Supernode verbindet. 

Die Verbindung zwischen den Supernodes und zum Map-Server wurde durch GRETAP-Tunnel ersetzt. Während der Tests lief diese Konfiguration ohne Probleme. 

Als Verschlüsselungsmethode wird nur noch "salsa2012+umac" zugelassen. Die MTU ist auf 1280 eingestellt (entspricht Transport-MTU 1366).