Fastd

Fast and Secure Tunneling Daemon.

Konfiguration Ruhr

Es gibt zwei Fastd-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).