infrastruktur:gateway:babel-gateway

Dies ist eine alte Version des Dokuments!


Gateways für das Freifunk-Babel-Netz orientieren sich am Setup für Batman-Gateways. Der Server nimmt fastd-Verbindungen von Freifunk-Routern mit der Babel-Firmware an und verteilt Informationen zur Infrastruktur des Netzes (früher: IP-Adressen & Routen, mittlerweile lediglich Routen, wobei das streng genommen optional ist), damit das Gesamtnetz funktionieren kann.

Es gibt ein paar Unterschiede zu Batman-Gateways:

  • es ist kein dhcp-Server erforderlich
  • es ist kein radvd erforderlich
  • Batman wird nicht installiert
  • Es müssen zusätzliche Komponenten (mmfd, l3roamd) ausgeführt werden
  • Über fastd wird das babel mesh-Protokoll gesprochen. Dadurch ist eine theoretische minimale MTU von 1288 möglich (1280 minimale IPv6-Größe + ein UDP-Header für mmfd-Pakete, die weiterhin Encapsulation-Technologie nutzen)

Hier wird lediglich die Einrichtung beschrieben. Für einen Überblick der Komponenten, bitte hier schauen: http://l3-freifunk.readthedocs.io/de/latest/components.html

apt-key adv --keyserver hkp://keys.gnupg.net --recv-keys 390BF305
apt-get install apt-transport-https
echo "deb https://dl.ffm.freifunk.net/debian-packages/ sid main" >/etc/apt/sources.list.d/ff-ffm.list
apt-get update
apt-get install babeld l3roamd mmfd fastd

/etc/fastd/mesh-vpn-1374/fastd.conf:

log level error;
log to syslog level error;
interface "mesh-vpn-1374";
method "salsa2012+umac";
method "salsa2012+gmac";
method "null";
secure handshakes no;
bind any:10001;
secret "30ca8b19e7f215dc7a3f45cb95b0ae2b1cbf8d706f9991a2ff121ae7c7184e6b";
mtu 1374;
peer limit 220;
include peers from "peers";
on verify "./verify $PEER_KEY";
on up "/sbin/ip link set dev mesh-vpn-1374 up";
status socket "/var/run/fastd-mesh-vpn-1374.sock";

l3roamd bringt bereits ein script zur INitialisierung via systemd mit. Das ist seiner Zeit etwas voraus - der l3roamd erfordert leider noch obligatorisch ein client-bridge. Aus diesem Grund ist das Script anzupassen: in /etc/systemd/system/l3roamd.service in Zeile 8 sollte so etwas stehen:

[Unit]
Description=l3roamd
Wants=basic.target
After=basic.target network.target fastd.service babeld.service

[Service]
Type=simple
ExecStart=/usr/local/bin/l3roamd -p 2a06:8187:fbab:2::/64 -m gre_gw01 -m mesh-vpn-1374 -m babel-vpn-1374  -i dummyl3roamd -t 11 -a 2a06:8187:fbab:1::9000:2 -4 0:0:0:0:0:ffff::/96 -b br-client
KillMode=process
ExecStartPost=/sbin/ip link set dev l3roam0 up
ExecStartPost=/sbin/ip -6 r add 2a06:8187:fbab:2::/64 dev l3roam0 table 10
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Die Bridge br-client muss per /etc/network/interfaces eingerichtet sein. Was da drin hängt ist egal, sie muss nur automatisch da sein beim Start. Ich mach das aktuell mit /etc/network/interfaces.d/br-client mit dem Inhalt

iface br-client inet static
	address 192.0.2.1
	netmask 255.255.255.0
	bridge_ports none

Die hinzugefügte Route macht, dass Pakete mit einem Ziel im Freifunk-Client-Netz aber mit unbekannter echter Route an den l3roamd übergeben werden. Dieser kann dann die Route ermitteln. Der l3roamd wird angepasst, sodass br-client nicht mehr zwingend erforderlich sein wird, denn auf Gateways ist sie nicht vorhanden und auch nicht sinnvoll.

Tabelle 10 wird fürs Routing genutzt. Wir haben auf dne GAteways folgende ip -6 rules:

from all to 2a06:8187:fbab:1::/64 lookup netz 
from all to 2a06:8187:fbab:2::/64 lookup netz 
from 2a06:8187:fbab:1::/64 lookup netz 
from 2a06:8187:fbab:2::/64 lookup netz 
from all to 2a06:8187:fbab:1::/64 lookup babeld 
from all to 2a06:8187:fbab:2::/64 lookup babeld 
from 2a06:8187:fbab:1::/64 lookup babeld 
from 2a06:8187:fbab:2::/64 lookup babeld 

wobei die Datei /etc/iproute2/rt_tabeles.d/babel.conf folgendes enthält:

10    netz
11    l3roamd
12    babeld

Wir trennen node-Netz (2a06:8187:fbab:1::/64) und client-Netz (2a06:8187:fbab:2::/64)

in Tabelle 12 kann man routen rein schreiben, von denen man möchte, dass sie von babeld noch verteilt werden sollen, Tabelle 10 enthält die Routen, die für das Freifunk-Netz gelten, in TAbelle 11 schreibt l3roamd seine neu gefundenen Routen rein. Das lässt sich alles zusammenfassen und in Tabelle 254 machen, wie auf den Nodes. Dann käme man ohne ip rules und separate routingtabellen aus. Wir haben es auf den Gateways aktuell getrennt. So schreibt nicht jeder in der main routing table herum.

Die default-route für den uplink muss in Tabelle 10 und 12 eingetragen werden (ggf reicht Tabelle 10).

Der Dienst wird installiert und muss laufen. Den Rest macht das unten angegebene service-file in /etc/systemd/system/mmfd.service Er wird für die Weiterleitung von Anfragen an die respondd-Instanzen auf den Nodes genutzt.

[Unit]
Description=mmfd
Wants=basic.target
After=basic.target network.target fastd.service babeld.service

[Service]
Type=simple
ExecStart=/usr/local/bin/mmfd -v
ExecStartPost=/sbin/ip link set mmfd0 up
KillMode=process
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Auf dem Host mit dem yanic (nicht zwingend auf den gateways), muss der mmfd laufen. Dessen mmfd0-Interface ist als Interface für die queries anzugeben, wobei eine broadcast-Adresse eingesetzt werden muss: ff05::was-auch-immer-respondd-hier-verlangt.

  • infrastruktur/gateway/babel-gateway.1511309724.txt.gz
  • Zuletzt geändert: 22.11.2017 00:15
  • von christf