Freifunk-Gateway aufsetzen/Batman-adv: Unterschied zwischen den Versionen

Aus Freifunk Franken
Wechseln zu:Navigation, Suche
(Seiten zusammengelegt)
Zeile 38: Zeile 38:
</pre>
</pre>


== DKMS für batman-adv ==
=== DKMS für batman-adv ===
Wenn man Batman-adv aus dem Quellen selbst kompiliert, wird bei einem Kernelupdate wieder eine alte Version installiert. Damit hier automatisch wieder die aktuelle Version gebaut wird, kann DKMS verwendet werden.
Wenn man Batman-adv aus dem Quellen selbst kompiliert, wird bei einem Kernelupdate wieder eine alte Version installiert. Damit hier automatisch wieder die aktuelle Version gebaut wird, kann DKMS verwendet werden.


Zeile 66: Zeile 66:


Wenn dies erfolgreich durchläuft, sollte beim nächsten Kernelupdate automatisch neu gegen den aktuelleren Kernel gebaut werden.
Wenn dies erfolgreich durchläuft, sollte beim nächsten Kernelupdate automatisch neu gegen den aktuelleren Kernel gebaut werden.
= Konfiguration =
In der Datei /etc/network/interfaces ...
<code>
vi /etc/network/interfaces
</code>
fügen wir zunächst folgenden Textblock des Gateways "klee" aus der Fürther Hood an:
<pre>
.
.
.
# device: bat0
iface bat0 inet manual
    post-up ip link set dev $IFACE up
    ##Einschalten post-up:
    # IP des Gateways am B.A.T.M.A.N interface:
    post-up ip addr add 10.50.32.5/21 dev $IFACE
    # Regeln, wann die fff Routing-Tabelle benutzt werden soll:
    post-up ip rule add iif $IFACE table fff
    post-up ip rule add from 10.0.0.0/8 table fff
    post-up ip rule add to 10.0.0.0/8  table fff
    # Route in die Fuerther Hood:
    post-up ip route replace 10.50.32.0/21 dev $IFACE proto static table fff
    # Start des DHCP Servers:
    post-up invoke-rc.d isc-dhcp-server restart
    ##Ausschalten post-down:
    # Loeschen von oben definieren Routen, Regeln und Interface:
    post-down ip route del 10.50.32.0/21 dev $IFACE table fff
    post-down ip rule del from 10.0.0.0/8 table fff
    post-down ip rule del to 10.0.0.0/8 table fff
    post-down ip rule del iif $IFACE table fff
    post-down ip link set dev $IFACE down
iface bat0 inet6 static
    address fd43:5602:29bd:x::1/64
    # zusätzliche Link Local für Hoodfile und Default-Gateway
    post-up ip -6 addr add fe80::1/64 dev $IFACE nodad
    post-up ip -6 addr add fe80::IRGENDWAS/64 dev $IFACE
    post-up ip -6 rule add iif $IFACE table fff
    post-down ip -6 rule del iif $IFACE table fff
    # "catchall"
    post-up ip -6 rule add from all iif $IFACE lookup fff
    # ip route   
    post-up ip -6 route replace fd43:5602:29bd:x::/64 dev $IFACE proto static table fff
    post-down ip -6 route del fd43:5602:29bd:x::/64 dev $IFACE proto static table fff
    post-up invoke-rc.d radvd restart
# VPN Verbindung in die Fuerther Hood
iface ffffuerthVPN inet manual
    post-up batctl -m bat0 if add $IFACE
    post-up ifconfig $IFACE up
    post-up ifup bat0
    post-down ifdown bat0
    post-down ifconfig $IFACE down
</pre>
In diesem Beispiel sind:
* IP des Gateway/Netzmaske der Fürther Hood: 10.50.32.5/21
* IP des Netzwerks Fürther Hood / Netzmaske der Fürther Hood: 10.50.32.0/21.
Diese müssen gegen die reservierte IP/Netzmaske des Gateways der Hood und gegen die Netzwerk-IP/Netzmaske der Hood, in die das neue Gateway soll, ausgetauscht werden.
Der Eintrag "ip route add 10.50.32.0/21 dev $IFACE table fff" fügt in der fff Routingtabelle eine Route in das Netzwerk "Fürther Hood" ein. Für Hassberge müsste dieser Eintrag z.B. in 10.50.56.0/22 geändert und für die IP-Adresse des Gateways eine aus dem statischen Bereich der Hassberger Hood reserviert und verwendet werden (s.o.).
Die Regeln definieren, das Traffic der
* aus dem Netzwerk 10.0.0.0/8 kommt
* das Netzwerk 10.0.0.0/8 zum Ziel hat
* oder über die B.A.T.M.A.N Schnittstelle übermittelt wird
von der fff Routingtabelle behandelt wird. Die Einträge sind so allgemein formuliert, dass sie für das gesamte Freifunk Franken Netz Gültigkeit haben sollten.
Im post-down Abschnitt werden die vorher definierten Regeln, Interfaces und Routen wieder gelöscht.
<i>Hinweis:</i> Die MTU darf nicht verstellt (vergrößert) werden, diesbezügliche Laufzeitmeldungen von batman_adv bitte ignorieren! Weil durch das Internet nur 1500bytes durchpassen und man daher den Tunnel nicht größer machen darf da er sonst nicht mehr durchs Internet passt
<br>
Beim loopback device bitte noch
<pre>
iface lo inet loopback
up ip rule add to 10.0.0.0/8 lookup fff
up ip -6 rule add to fc00::/7 lookup fff
## Möglicherweise möchte man die gleichen rules auch nochmal als Destination-rules (from statt to) anfügen.
        #Eintragen, damit das Gateway weiß, dass die Freifunk-IPs durch die fff Routingtabelle durchgehen
</pre>
=== Public IPv6 ===
Wenn man Public IPv6 Adressen vergeben möchte, muss dazu eine IP an das batX Interface gehangen werden und eine route in die Routingtabelle eingetragen werden. Dies kann man z.b. folgendermaßen tun:
<pre>
[...]
# Public IPv6
post-up ip -6 addr add 2001:DB8:aaaa:bbbb::1/64 dev batX
post-up ip -6 route add 2001:DB8:aaaa:bbbb::/64 dev $IFACE proto static tab fff </br>
[...]
</pre>
Zuerst wird eine einzelne Adresse des /64 Netzes an das bat Interface gehangen. Anschließend wird für dieses Subnetz eine Route mit "proto static" angelegt, damit Babel die Route auch weiter announced. Gleichzeitig wird die route dafür verwendet, den Traffic für das Subnetz auch auf das Interface zu routen.

Version vom 23. Juni 2019, 15:11 Uhr

Funktion

B.A.T.M.A.N. wird bei uns als Layer-2-Routing-Protokoll (ja, klingt kaputt – ist es auch) eingesetzt, um WLAN-Mesh zu ermöglichen. Für Linux gibt es dafür das B.A.T.M.A.N.-Advanced-Kernel-Modul.

Installation

B.A.T.M.A.N. Advanced wird mit dem Kommando batctl gesteuert. Das muss entsprechend installiert werden. Dabei kann sowohl die Version aus den Debian Paketquellen oder eine Selbstkompilierte verwendet werden (siehe weiter unten).

apt install batctl

Die Version, die beim Kernel von Debian Stretch mit dabei ist (v2016.4) ist Compat15, was die aktuell verwendete Compat-Version ist. (siehe [1]). Für unser KeyXchangeV2 Setup wird zum aktuellen Zeitpunkt ausschließlich Compat Version 15 verwendet.

Es sollte möglichst immer die gleiche Version für batman-adv und batctl verwendet werden. Daher entweder beides aus den Paketquellen installieren, oder beides selbst kompilieren.

Hinweis: Wird der Kernel aktualisiert, müssen alle selbstkompilierten Kernelmodule erneut gegen die aktualisierte Kernelversion gebaut und danach installiert werden! Folglich muss ein selbstkompiliertes batman_adv nach jedem Kernelupdate neu gebaut und installiert werden. Für den Anfang empfiehlt es sich, mit dem mitgelieferten batman_adv zu arbeiten.

Das Kernel-Modul kann testweise mit folgendem Befehl geladen werden: modprobe batman-adv

Im Kernel Log sollte das Laden protokolliert werden:

~# dmesg | grep batman_adv
batman_adv: B.A.T.M.A.N. advanced 2018.0 (compatibility version 15) loaded


Die aktuell eingesetzte Version von batctl und batman-adv (kann unterschiedlich sein) erfährt man mit batctl -v


Das Kernelmodul von B.A.T.M.A.N. kann dann bei jedem Neustart des Systems geladen werden, indem in die Datei /etc/modules der Eintrag "batman-adv" hinzugefügt wird:

..
batman-adv

DKMS für batman-adv

Wenn man Batman-adv aus dem Quellen selbst kompiliert, wird bei einem Kernelupdate wieder eine alte Version installiert. Damit hier automatisch wieder die aktuelle Version gebaut wird, kann DKMS verwendet werden.

Unter /usr/src einen Ordner anlegen mit NAME-Version z.b. batman-adv-2019.1 (zum aktuellen Zeitpunkt die aktuelle Version). Hier hinein entpackt man nun die Batman-adv sourcen und legt eine dkms.conf ebenfalls in dem Ordner an:

PACKAGE_NAME=batman-adv
PACKAGE_VERSION=2019.1

DEST_MODULE_LOCATION=/extra
BUILT_MODULE_NAME=batman-adv
BUILT_MODULE_LOCATION=net/batman-adv

MAKE="'make'"
CLEAN="'make' clean"

AUTOINSTALL="yes"

danach kann man das ganze Testen mit

dkms add -m batman-adv -v 2019.1
dkms build -m batman-adv -v 2019.1
dkms install -m batman-adv -v 2019.1

Wenn dies erfolgreich durchläuft, sollte beim nächsten Kernelupdate automatisch neu gegen den aktuelleren Kernel gebaut werden.


Konfiguration

In der Datei /etc/network/interfaces ...

vi /etc/network/interfaces

fügen wir zunächst folgenden Textblock des Gateways "klee" aus der Fürther Hood an:

.
.
.
# device: bat0
iface bat0 inet manual
    post-up ip link set dev $IFACE up
    ##Einschalten post-up:
    # IP des Gateways am B.A.T.M.A.N interface:
    post-up ip addr add 10.50.32.5/21 dev $IFACE
    # Regeln, wann die fff Routing-Tabelle benutzt werden soll: 
    post-up ip rule add iif $IFACE table fff
    post-up ip rule add from 10.0.0.0/8 table fff	
    post-up ip rule add to 10.0.0.0/8  table fff
    # Route in die Fuerther Hood:	
    post-up ip route replace 10.50.32.0/21 dev $IFACE proto static table fff
    # Start des DHCP Servers:
    post-up invoke-rc.d isc-dhcp-server restart

    ##Ausschalten post-down:
    # Loeschen von oben definieren Routen, Regeln und Interface: 
    post-down ip route del 10.50.32.0/21 dev $IFACE table fff
    post-down ip rule del from 10.0.0.0/8 table fff
    post-down ip rule del to 10.0.0.0/8 table fff
    post-down ip rule del iif $IFACE table fff
    post-down ip link set dev $IFACE down

iface bat0 inet6 static
    address fd43:5602:29bd:x::1/64

    # zusätzliche Link Local für Hoodfile und Default-Gateway
    post-up ip -6 addr add fe80::1/64 dev $IFACE nodad
    post-up ip -6 addr add fe80::IRGENDWAS/64 dev $IFACE

    post-up ip -6 rule add iif $IFACE table fff
    post-down ip -6 rule del iif $IFACE table fff

    # "catchall"
    post-up ip -6 rule add from all iif $IFACE lookup fff

    # ip route    
    post-up ip -6 route replace fd43:5602:29bd:x::/64 dev $IFACE proto static table fff
    post-down ip -6 route del fd43:5602:29bd:x::/64 dev $IFACE proto static table fff
    post-up invoke-rc.d radvd restart


# VPN Verbindung in die Fuerther Hood
iface ffffuerthVPN inet manual
    post-up batctl -m bat0 if add $IFACE
    post-up ifconfig $IFACE up
    post-up ifup bat0
    post-down ifdown bat0
    post-down ifconfig $IFACE down

In diesem Beispiel sind:

  • IP des Gateway/Netzmaske der Fürther Hood: 10.50.32.5/21
  • IP des Netzwerks Fürther Hood / Netzmaske der Fürther Hood: 10.50.32.0/21.

Diese müssen gegen die reservierte IP/Netzmaske des Gateways der Hood und gegen die Netzwerk-IP/Netzmaske der Hood, in die das neue Gateway soll, ausgetauscht werden.

Der Eintrag "ip route add 10.50.32.0/21 dev $IFACE table fff" fügt in der fff Routingtabelle eine Route in das Netzwerk "Fürther Hood" ein. Für Hassberge müsste dieser Eintrag z.B. in 10.50.56.0/22 geändert und für die IP-Adresse des Gateways eine aus dem statischen Bereich der Hassberger Hood reserviert und verwendet werden (s.o.).

Die Regeln definieren, das Traffic der

  • aus dem Netzwerk 10.0.0.0/8 kommt
  • das Netzwerk 10.0.0.0/8 zum Ziel hat
  • oder über die B.A.T.M.A.N Schnittstelle übermittelt wird

von der fff Routingtabelle behandelt wird. Die Einträge sind so allgemein formuliert, dass sie für das gesamte Freifunk Franken Netz Gültigkeit haben sollten.

Im post-down Abschnitt werden die vorher definierten Regeln, Interfaces und Routen wieder gelöscht.

Hinweis: Die MTU darf nicht verstellt (vergrößert) werden, diesbezügliche Laufzeitmeldungen von batman_adv bitte ignorieren! Weil durch das Internet nur 1500bytes durchpassen und man daher den Tunnel nicht größer machen darf da er sonst nicht mehr durchs Internet passt

Beim loopback device bitte noch

iface lo inet loopback
	up ip rule add to 10.0.0.0/8 lookup fff

	up ip -6 rule add to fc00::/7 lookup fff

	## Möglicherweise möchte man die gleichen rules auch nochmal als Destination-rules (from statt to) anfügen.

        #Eintragen, damit das Gateway weiß, dass die Freifunk-IPs durch die fff Routingtabelle durchgehen

Public IPv6

Wenn man Public IPv6 Adressen vergeben möchte, muss dazu eine IP an das batX Interface gehangen werden und eine route in die Routingtabelle eingetragen werden. Dies kann man z.b. folgendermaßen tun:

[...]
# Public IPv6
post-up ip -6 addr add 2001:DB8:aaaa:bbbb::1/64 dev batX 
post-up ip -6 route add 2001:DB8:aaaa:bbbb::/64 dev $IFACE proto static tab fff </br>
[...]

Zuerst wird eine einzelne Adresse des /64 Netzes an das bat Interface gehangen. Anschließend wird für dieses Subnetz eine Route mit "proto static" angelegt, damit Babel die Route auch weiter announced. Gleichzeitig wird die route dafür verwendet, den Traffic für das Subnetz auch auf das Interface zu routen.