Freifunk-Gateway aufsetzen/keyxchangev2 VERALTET: Unterschied zwischen den Versionen

Aus Freifunk Franken
Wechseln zu:Navigation, Suche
 
(42 dazwischenliegende Versionen von 8 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
Hier landen die ersten Infos was für Gateways bei KeyxchangeV2 geändert werden muss. Es sind nur Beispieldateien und müssen pro Hood unbedingt angepasst werden! Ungetestet!
= ACHTUNG =
DIESE ANLEITUNG IST VERALTET. KEINESFALLS VERWENDEN!!
 
Dieses hier verwenden:
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Hier ist grob zusammengefasst, was bei den Gateways für den KeyxchangeV2 anders ist, als bei den KeyxchangeV1 Gateways. Es sind nur Beispieldateien und müssen pro Hood unbedingt angepasst werden! Ungetestet!


== Batman ==
== Batman ==
Zeile 24: Zeile 68:
Dafür ist mindestens build-essential, libnl-3-dev, libnl-genl-3-dev, make, pkg-config, linux-headers nötig. Bitte ergänzen, ob noch mehr notwendig ist.
Dafür ist mindestens build-essential, libnl-3-dev, libnl-genl-3-dev, make, pkg-config, linux-headers nötig. Bitte ergänzen, ob noch mehr notwendig ist.


 
Am Ende sollte 'batctl -v' sowohl für batctl, als auch für batman-adv eine Version größer 2013.4 ausgeben. (wie in diesem Beispiel 2017.3...)
Am Ende sollte 'batctl -v' Bei Version etwas größer als 2013.4 stehen (wie in diesem Beispiel 2017.3...)
<pre>
<pre>
# modprobe batman-adv && batctl -v
# modprobe batman-adv && batctl -v
batctl 2017.3 [batman-adv: 2017.3]
batctl 2017.3 [batman-adv: 2017.3]
</pre>
</pre>
'''ACHTUNG:''' Selbst kompilierte Kernelmodule funktionieren nach einem Kernelupdate nicht mehr und müssen '''unbedingt''' neu kompiliert und eingefügt werden!


== Alfred Master aufsetzen ==
== Alfred Master aufsetzen ==
==== Alfred Monitoring Proxy ====
Die Nodewatcher Daten aus dem Alfred werden nicht mehr von einer zentralen VM ans Monitoring geschickt. Das übernehmen jetzt die Gateways.
Wir nutzen besser den C-Alfred von kratz00 https://github.com/kratz00/alfred-json somit können wir auch sehr leicht mehrere Hoods bedienen. Folgende Pakete werden zum Compilieren benötigt: zlib1g-dev, pkgconf, libjansson-dev und deren Dependencies.
 
==== Alfred ====
Das Gateway muss die Daten zuerst als sogenannter Alfred-Master sammeln. Dazu muss "alfred" installiert werden. (Entweder aus den Distributionsquellen oder selbst kompilieren, funktioniert analog zum batman-adv (siehe oben))


Zuerst den Alfred-Master pro Hood starten (irgendwo in Autostart):
Dann muss pro bedienter Hood (also für jedes batX Interface) ein Alfred master gestartet werden (beispielsweise mit in die Interfacekonfiguration oder wie unten als systemd-Service ...):
<pre>
<pre>
root@vm3-gw-cd1:/usr/sbin# cat /etc/fastd/fff.fuerth/up.sh
~# cat /etc/systemd/system/alfred-bayreuth.service
#!/bin/sh
[Unit]
/sbin/ifup $INTERFACE
Description=Alfred Master
batctl gw_mode server 32mbit
After=network-online.target
alfred -m -i bat0 -u /var/run/a0.sock &
 
[Service]
Type=simple
ExecStart=/usr/sbin/alfred -m -i br-bayreuth -b bat2 -u /var/run/alfred-bayreuth.sock
WorkingDirectory=/tmp
RestartSec=10
Restart=always
 
[Install]
WantedBy=multi-user.target
</pre>
</pre>
den Socket pro Hood einfach um eins hochzählen, a1.sock a2.sock usw.


Danach bauen wir Alfred-json
Hinweis: Wenn in der eigenen Konfiguration keine separate Bridge verwendet wird, muss beim Parameter -i das bat-Interface angegeben werden; also bei -i und -b das selbe Interface.
 
==== Alfred Monitoring Proxy ====
Die gesammelten Daten müssen nun noch periodisch an das Monitoring gesendet werden.
 
Dazu kann alfred-json von kratz00 (https://github.com/kratz00/alfred-json) in Kombination mit einem passenden curl-Skript verwenden werden. Zunächst muss alfred-json kompiliert werden (siehe README).
Zusätzlich zu den in der Readme angegebenen Packeten muss noch make sowie pkg-config installiert werden.
 
Danach noch das curl-Script anlegen (auf eigenes Zeug anpassen! Pfade der inneren for-loop über die Sockets prüfen!):
 
<pre>
<pre>
git clone https://github.com/kratz00/alfred-json
~# cat /usr/sbin/alfred-monitoring-proxy
cd alfred-json/
mkdir build
cd build/
cmake ../
make
sudo su
make install
</pre>
</pre>
danach noch das Script anlegen (auf eigenes Zeug anpassen! Pfade prüfen! Socket-Pfad im up.sh des fastd für die jeweilige Hood):
<pre>
<pre>
root@vm3-gw-cd1:/var/log# cat /usr/sbin/alfred-c
#!/bin/bash
#!/bin/bash


Zeile 68: Zeile 122:
for fetch_id in $fetch_ids
for fetch_id in $fetch_ids
do
do
    tmp=$(/bin/mktemp)
for socket in /var/run/alfred-*.sock
    echo "{\"$fetch_id\": " > $tmp
do
    /usr/local/bin/alfred-json -r "$fetch_id" -s /var/run/alfredbat0.sock >> $tmp
tmp=$(mktemp)
    echo "}" >> $tmp
 
    if [ "$zip" = "1" ]; then
echo "{\"$fetch_id\": " > $tmp
        gzip $tmp
alfred-json -r "$fetch_id" -s "$socket" >> $tmp
        tmp="$tmp.gz"
echo "}" >> $tmp
        HEADER='-H "Content-Encoding: gzip" --compressed'
    fi
    /usr/bin/curl -k -v -H "Content-type: application/json; charset=UTF-8" $HEADER -X POST --data-binary @$tmp $api_url
    /bin/rm "$tmp"
done


for fetch_id in $fetch_ids
if [ "$zip" = "1" ]; then
do
gzip $tmp
    tmp=$(/bin/mktemp)
tmp="$tmp.gz"
    echo "{\"$fetch_id\": " > $tmp
HEADER='-H "Content-Encoding: gzip" --compressed'
    /usr/local/bin/alfred-json -r "$fetch_id" -s /var/run/alfredbat1.sock >> $tmp
fi
    echo "}" >> $tmp
    if [ "$zip" = "1" ]; then
        gzip $tmp
        tmp="$tmp.gz"
        HEADER='-H "Content-Encoding: gzip" --compressed'
    fi
    /usr/bin/curl -k -v -H "Content-type: application/json; charset=UTF-8" $HEADER -X POST --data-binary @$tmp $api_url
    /bin/rm "$tmp"
done


for fetch_id in $fetch_ids
curl -v -H "Content-type: application/json; charset=UTF-8" $HEADER --data-binary @$tmp $api_url
do
    tmp=$(/bin/mktemp)
    echo "{\"$fetch_id\": " > $tmp
    /usr/local/bin/alfred-json -r "$fetch_id" -s /var/run/alfredbat2.sock >> $tmp
    echo "}" >> $tmp
    if [ "$zip" = "1" ]; then
        gzip $tmp
        tmp="$tmp.gz"
        HEADER='-H "Content-Encoding: gzip" --compressed'
    fi
    /usr/bin/curl -k -v -H "Content-type: application/json; charset=UTF-8" $HEADER -X POST --data-binary @$tmp $api_url
    /bin/rm "$tmp"
done


for fetch_id in $fetch_ids
rm "$tmp"
do
done
    tmp=$(/bin/mktemp)
    echo "{\"$fetch_id\": " > $tmp
    /usr/local/bin/alfred-json -r "$fetch_id" -s /var/run/alfredbat3.sock >> $tmp
    echo "}" >> $tmp
    if [ "$zip" = "1" ]; then
        gzip $tmp
        tmp="$tmp.gz"
        HEADER='-H "Content-Encoding: gzip" --compressed'
    fi
    /usr/bin/curl -k -v -H "Content-type: application/json; charset=UTF-8" $HEADER -X POST --data-binary @$tmp $api_url
    /bin/rm "$tmp"
done
done
</pre>
</pre>


ausführbar machen:
<pre>
chmod +x /usr/sbin/alfred-c
</pre>


Einen Cronjob drüber:
Und einen  passenden Cronjob dafür anlegen:
<pre>
<pre>
*/5 * * * * sleep 70; /usr/sbin/alfred-c
1-59/5 * * * * sleep 9; /usr/sbin/alfred-monitoring-proxy
</pre>
</pre>


Der sleep-Befehl ist wichtig. Das Argument von sleep sollte irgendwo zwischen 65 und 80 Sekunden liegen. Zwei Alfred Master in der selben Hood dürfen NIE zu gleichen Zeit Daten schicken. Details zu den Zeitslot direkt im Anschluss.
'''WICHTIG:''' Bitte im nächsten Abschnitt den optimalen Zeitpunkt für das senden bestimmen!
 
fertig :)


==== Wahl des korrekten Delays (sleep) ====
==== Wahl des korrekten Delays (sleep) ====
Zeile 191: Zeile 199:
1-59/5 * * * * Befehl
1-59/5 * * * * Befehl
</pre>
</pre>


Das löst dann 00:01, 00:06, 00:11 usw. aus, also im beginnend bei 1 bis 59 in 5-er Schritten
Das löst dann 00:01, 00:06, 00:11 usw. aus, also im beginnend bei 1 bis 59 in 5-er Schritten
Zeile 198: Zeile 207:
</pre>
</pre>


Das löst dann 00:02, 00:07, 00:12 usw. aus, also im beginnend bei 2 bis 59 in 5-er Schritten


Das löst dann 00:02, 00:07, 00:12 usw. aus, also im beginnend bei 2 bis 59 in 5-er Schritten.
In Kombination mit sleep gibt es also für 130 Sekunden folgende Lösungen:
In Kombination mit sleep gibt es also für 130 Sekunden folgende Lösungen:


Zeile 205: Zeile 214:
*/5 * * * * sleep 130; Befehl
*/5 * * * * sleep 130; Befehl
</pre>
</pre>


oder besser:
oder besser:
Zeile 224: Zeile 234:
# Copyright Adrian Schmutzler, 2018.
# Copyright Adrian Schmutzler, 2018.
# License GPLv3
# License GPLv3
#
# v1.2.1 - 2018-01-12
# - Added "grep fff" to support L2TP
#
#
# v1.2 - 2018-01-12
# v1.2 - 2018-01-12
Zeile 272: Zeile 285:
Sowohl die Verwendung des Skriptes als auch welche Daten zur Verfügung gestellt werden bleibt dem Nutzer überlassen.
Sowohl die Verwendung des Skriptes als auch welche Daten zur Verfügung gestellt werden bleibt dem Nutzer überlassen.


Soll z.B. keine stats_page angezeigt werden, einfach stats_page="" einstellen.
Soll z.B. keine stats_page angezeigt werden, einfach statslink="" einstellen.


== network ==
== network ==


Für keyxchangev2 werden neue Subnetze benötigt. Jede Hood aus dem KeyxchangeV2 ist ein eigenes Subnetz aus dem 10.83/16 und muss dort auch auf der Netz Seite registriert werden.
Für keyxchangev2 werden neue Subnetze benötigt. Jede Hood aus dem KeyxchangeV2 ist ein eigenes Subnetz aus dem 10.83.0.0/16 und muss dort auch auf der [https://wiki.freifunk-franken.de/w/Portal:Netz#10.83.0.0.2F16_.28decentraliced_keyXchange_network.29.2C_dynamische_Vergabe Netz Seite] registriert werden.
Dazu werden absofort auch IPv6 Netze verwendet, diese müssen auch hier registriert werden: https://wiki.freifunk-franken.de/w/Portal:Netz/IPv6
Dazu werden absofort auch IPv6 Netze verwendet, diese müssen auch hier registriert werden: https://wiki.freifunk-franken.de/w/Portal:Netz/IPv6


/etc/network/interfaces
/etc/network/interfaces
<pre>
<pre>
device: bat0
iface bat0 inet static
iface bat0 inet manual
    address 10.83.x.1/y
post-up ifconfig $IFACE up
 
     ##Einschalten post-up:
    post-up ip rule add iif $IFACE table fff
     # IP des Gateways am B.A.T.M.A.N interface:
    post-down ip rule del iif $IFACE table fff
     post-up ip addr add 10.83.X.1/22 dev $IFACE
 
    ## Sollten hier ip-rules für 10.0.0.0/8 oder ähnlich Interface-unabhängige Dinge stehen,
    ## bietet es sich an, diese anstatt dessen an das loopback Interface zu hängen, da diese
    ## für das ganze Freifunk-Netz gelten und entsprechend nur einmal benötigt werden und nicht
    ## von speziellen Interfaces abhängig sein sollten.
 
     ## Je nachdem, wie der DHCP Server gestartet wird, ist hier möglicherweise noch folgendes nötig
    post-up invoke-rc.d isc-dhcp-server restart
 
     # ip route
    post-up ip route replace 10.83.x.0/y dev $IFACE proto static table fff
     post-down ip route del 10.83.x.0/y dev $IFACE proto static table fff
 
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::1/64 dev $IFACE nodad
     post-up ip -6 addr add fe80::BLA:BLA:BLA/64 dev $IFACE #wird für radvd benötigt!!
     post-up ip -6 addr add fe80::fff:1/64 dev $IFACE nodad
     post-up ip -6 addr add fd43:5602:29bd:X::1/64 dev $IFACE
     post-up ip -6 addr add fe80::IRGENDWAS/64 dev $IFACE
    # Regeln, wann die fff Routing-Tabelle benutzt werden soll:
 
    post-up ip rule add iif $IFACE table fff
     post-up ip -6 rule add iif $IFACE table fff
     post-up ip -6 rule add iif $IFACE table fff
     post-up ip rule add from 10.0.0.0/8 table fff
     post-down ip -6 rule del iif $IFACE table fff
     post-up ip rule add to 10.0.0.0/8  table fff
 
     # Route in die Fuerther Hood:     
    # "catchall"
     post-up ip route replace 10.83.X.0/22 dev $IFACE proto static table fff
     post-up ip -6 rule add from all iif $IFACE lookup fff
     post-up ip -6 route replace fd43:5602:29bd:X::/64 dev $IFACE proto static table fff # PREFIX ANPASSEN!
 
    # Start des DHCP Servers:
     # ip route   
     post-up invoke-rc.d isc-dhcp-server restart
     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


    ##Ausschalten post-down:
    # Loeschen von oben definieren Routen, Regeln und Interface:
    post-down ip route del 10.83.X.0/22 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 ifconfig $IFACE down


# VPN Verbindung in die Fuerther Hood
# VPN
iface ffffuerthVPN inet manual
iface ffffuerthVPN inet manual
     post-up batctl -m bat0 if add $IFACE
     post-up batctl -m bat0 if add $IFACE
     post-up ifconfig $IFACE up
     post-up ip link set up $IFACE
     post-up ifup bat0
     post-up ifup bat0
     post-down ifdown bat0
     post-down ifdown bat0
     post-down ifconfig $IFACE down
     port-down ip link set down $IFACE
</pre>
 
Die Interfaces müssen nicht manuell (ifup bla) gestartet werden, dies erledigt fastd.
 
Jedes Interface wird an eine eigene Link Local Adresse gebunden (fe80::IRGENDWAS/64), über die es von anderen Diensten - beispielsweise radvd - angesprochen werden kann.
 
 
'''ACHTUNG:''' Die oben stehende Konfiguration enthält keine IP(6)-Rules, die dem Server sagen, dass er für die entsprechenden Subnetze in die fff-table gucken muss!
 
Am einfachsten lässt sich das durch das statische Anfügen von wenigen rules beim starten des loopback-Interfaces lösen:
 
<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.
</pre>
</pre>


== fastd ==
== fastd ==


Fastd wird komplett anders als früher konfiguriert:
fastd wird komplett anders als früher konfiguriert.
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen#FastD_Start-_und_Verwaltungsscript
Das früher nötige Verwaltungsscript darf '''KEINESFALLS(!!)''' ausgeführt werden, auch der Cronjob ist nicht mehr nötig. Falls die IP noch im alten KeyXchange eingetragen ist, sollte sie hieraus unbedingt entfernt werden (KeyXchange Admin fragen) Bitte nur noch folgende Anleitung folgen:
das *.sh Script darf KEINESFALLS(!!) mehr angelegt/ausgeführt werden, auch der Cronjob ist nicht mehr nötig. Falls die IP noch im alten KeyXchange eingetragen ist, sollte sie hieraus unbedingt entfernt werden (KeyXchange Admin fragen) Bitte nur noch folgende Anleitung folgen:


/etc/fastd/ffffuerthVPN/fastd.conf
<pre>
<pre>
root@vm3-gw-cd1:/etc/fastd/fff.fuerth# cat down.sh
# Log errors to stderr
#!/bin/sh
/sbin/ifdown $INTERFACE
root@vm3-gw-cd1:/etc/fastd/fff.fuerth# cat fff.fuerth.conf
# Log warnings and errors to stderr
log level error;
log level error;
# Log everything to a log file
 
log to syslog as "ffffuerth" level info;
# Log warnings to a log file
log to syslog as "ffffuerthVPN" level warn;
 
# Set the interface name
# Set the interface name
interface "ffffuerthVPN";
interface "ffffuerthVPN";
# Support xsalsa20 and aes128 encryption methods, prefer xsalsa20
 
#method "xsalsa20-poly1305";
# Disable encryption
#method "aes128-gcm";
method "null";
method "null";
# Bind to a fixed port, IPv4 only
# Bind to a fixed port, IPv4 only
bind any:10004;
bind any:10004;
# fastd need a key but we don't use them
 
# fastd need a key but we don't use them: generate by "fastd --generate-key"
secret "c00a286249ef5dc5506945f8a3b413c0928850214661aab866715203b4f2e86a";
secret "c00a286249ef5dc5506945f8a3b413c0928850214661aab866715203b4f2e86a";
# Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE)
# Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE)
# (see MTU selection documentation)
# (see MTU selection documentation)
mtu 1426;
mtu 1426;
on up "/etc/fastd/fff.fuerth/up.sh";
 
on post-down "/etc/fastd/fff.fuerth/down.sh";
on up "/etc/fastd/up.sh";
on down "/etc/fastd/down.sh";
 
secure handshakes no;
secure handshakes no;
on verify "/etc/fastd/fff.fuerth/verify.sh";


root@vm3-gw-cd1:/etc/fastd/fff.fuerth# cat up.sh  
on verify "/etc/fastd/verify.sh";
#!/bin/sh
</pre>
/sbin/ifup $INTERFACE
 


root@vm3-gw-cd1:/etc/fastd/fff.fuerth# cat verify.sh  
/etc/fastd/down.sh
<pre>
#!/bin/sh
#!/bin/sh
return 0
/sbin/ifdown $INTERFACE
</pre>


root@vm3-gw-cd1:/etc/fastd/fff.fuerth#
</pre>


/etc/fastd/up.sh
<pre>
<pre>
root@vm3-gw-cd1:/home/christiand# cat /etc/systemd/system/fastd.service
#!/bin/sh
[Unit]
/sbin/ifup $INTERFACE
Description=fastd
</pre>


[Service]
ExecStart=/usr/bin/fastd -c /etc/fastd/fff.fuerth/fff.fuerth.conf
Type=simple


[Install]
/etc/fastd/verify.sh
WantedBy=multi-user.target
<pre>
#!/bin/sh
return 0
</pre>
</pre>


danach:
danach:
Zeile 380: Zeile 423:
systemctl start fastd
systemctl start fastd
</pre>
</pre>


Der Server muss dann händisch in den keyxchangev2 eingetragen werden. Dazu sind folgende Infos nötig:
Der Server muss dann händisch in den keyxchangev2 eingetragen werden. Dazu sind folgende Infos nötig:
* IP Adresse (aktuell v4)
* IP Adresse des Gateways
* Port von fastd
* Port von fastd
* Public Key von fastd (die Router müssen den Pub-Key vom Gateway kennen sonst funktioniert es nicht, das Gateway muss KEINE Keys vom Router kennen)
* Public Key von fastd (die Router müssen den Pub-Key vom Gateway kennen sonst funktioniert es nicht, das Gateway muss KEINE Keys vom Router kennen)
* Servername
* Servername
* Hood
* Hood
<br>
Weiterhin erforderlich ist ein [[Freifunk-Gateway_aufsetzen#B.A.T.M.A.N_Gateway_Selection|B.A.T.M.A.N Gateway Selection]] Script.


=== Gateways untereinander verbinden ===
=== Gateways untereinander verbinden ===
Die Gateways müssen sich im fastd auch noch untereinander verbinden, hier fehlt noch $config
Die Gateways sollten sich im Hood-Layer2 auch noch untereinander verbinden, das ist aktuell noch nicht umgesetzt.
 
am besten wird es sein, sich die json vom keyxchange zu holen und alle Gateways (auser sich selbst) in das peers Verzeichnis eintragen, dann sollte fastd sich darum kümmern. Dies regelmäßig per Cronjob tun.


== babel ==
== babel ==
Zeile 397: Zeile 441:
siehe [[Freifunk-Gateway_aufsetzen/Babel|hier]]
siehe [[Freifunk-Gateway_aufsetzen/Babel|hier]]


== GRE TUnnel ==
== GRE Tunnel ==


Die GRE Tunnel brauchen auch eine ipv6 aus dem Transfernetz.
Die GRE Tunnel brauchen nun auch eine IPv6 aus dem Transfernetz. (siehe babel-Seite oben)


<pre>
Es müssen dann noch folgende IP-Rules existieren (beispielsweise wie oben beschrieben am loopback-Interface):
...
post-up ip -6 addr add fd43:5602:29bd:ffff::X dev XXXXX
...
</pre>
 
ip -6 rule show sollte noch folgende Einträge bekommen:
* from all to fc00::/7 lookup fff  
* from all to fc00::/7 lookup fff  
* from fc00::/7 lookup fff
* from fc00::/7 lookup fff
Zeile 413: Zeile 451:
== radvd ==
== radvd ==


radvd muss mindestens 2.16 installiert sein, prüfen mit
Damit radvd nicht die fe80::1 als Source-IP verwendet (geht ziemlich kaputt), muss mindestens Version 2.16 installiert sein. Das kann man so überprüfen:
 
<pre>
<pre>
radvd -v
radvd -v
</pre>
</pre>


wird benötigt für AdvRASrcAddress


In Debian bis 9 ist nur 2.15 integriert.
In den Debian 9 Packetquellen wird leider noch 2.15 ausgeliefert.
Man kann radvd aber aus Debian 10 (aktuell testing) backporten.


install radvd from buster:
Damit nicht alle Pakete auf die buster-Version aktualisiert werden:


add /etc/apt/preferences.d/limit-buster
/etc/apt/preferences.d/limit-buster
<pre>
<pre>
Package: *
Package: *
Zeile 430: Zeile 469:
Pin-Priority: 150
Pin-Priority: 150
</pre>
</pre>
add /etc/apt/sources.list.d/buster.list
 
 
Dann die buster Packetquellen einfügen:
 
/etc/apt/sources.d/buster.list
<pre>
<pre>
deb http://ftp.de.debian.org/debian/ buster main
deb http://ftp.de.debian.org/debian/ buster main
</pre>
</pre>
* apt-get update
* apt-get -t buster install radvd


in der config bitte das prefix anpassen!
 
Und radvd installieren:
<pre>
apt-get update
apt-get -t buster install radvd
</pre>
 
 
radvd muss dann in jeder Hood Router Advertisements senden und die entsprechende ULA als Autonomous Prefix announcen:
 
/etc/radvd.conf
<pre>
<pre>
root@vm3-gw-cd1:/etc/fastd/fff.fuerth# cat /etc/radvd.conf
interface bat0 {  
interface bat0 {  
         AdvSendAdvert on;
         AdvSendAdvert on;
        MinRtrAdvInterval 60;
        MaxRtrAdvInterval 300;
AdvDefaultLifetime 0;
AdvDefaultLifetime 0;
         AdvRASrcAddress {
         AdvRASrcAddress {
                 fe80::b41e:49ff:XXXX:XXXX;
                 fe80::IRGENDWAS;
         };
         };
         prefix fd43:5602:29bd:X::/64 {  
         prefix fd43:5602:29bd:x::/64 {  
                 AdvOnLink on;  
                 AdvOnLink on;  
                 AdvAutonomous on;  
                 AdvAutonomous on;  
Zeile 457: Zeile 505:
</pre>
</pre>


ACHTUNG:
Die fe80:: die bei AdvRASrcAddress eingetragen ist muss fest an das batX Interface gebunden werden, bitte eigene fe80 generieren, sie muss pro Hood Unique sein:


<pre>
'''ACHTUNG:''' Die fe80:: die bei AdvRASrcAddress eingetragen ist muss fest an das batX Interface gebunden werden. (siehe interface-config oben). Die Adresse zufällig zu generieren bietet sich an, damit die Adressen in jeder Hood eindeutig sind. Es muss die gleiche Adresse sein, die in /etc/network/interfaces  an das jeweilige batX Interface gebunden wurde.
    post-up ip -6 addr add fe80::b41e:49ff:XXXX:XXXX dev $IFACE
 
</pre>


AdvRASrcAddress ist nötig damit die route spezifisch zu einem Gateway gesetzt wird (Client sucht sich Gateway aus) und nicht per fe80::1 anycast wird (Standardmäßig nutzt radvd die kleinste fe80 Adresse und das ist bei uns immer fe80::1 und diese hängt per nodad am batX).
AdvRASrcAddress ist nötig, damit die Router Advertisements nicht von der fe80::1 gesendet werden. Denn wenn zwei Gateways verschiedene Router Advertisements von der gleichen Link Local Adresse senden, sind die Clients verwirrt und es kommt unter Umständen zu einer instabilen Verbindung.
Wie sich das am Ende ausbalanciert muss mit vielen Routern und Clients getestet werden, gerade wenn eine IPv6 default Route gesetzt wird da PublicV6 verteilt wird.


<pre>
<pre>
/etc/init.d/radvd restart
systemctl restart radvd
</pre>
</pre>


== ntp Server ==
== ntp Server ==


Es werden routbare v6 Adressen aus den ULA Bereich verwendet. Jede Hood kann, muss aber nicht einen eigenen ntp Server bereit stellen. Aktuell sind folgende NTP Server in betrieb und können verwendet werden:
Es werden routbare v6 Adressen aus den ULA Bereich verwendet. Jede Hood kann, muss aber nicht einen eigenen ntp Server bereit stellen. Aktuell sind folgende NTP Server in Betrieb und können verwendet werden:
* fd43:5602:29bd:ffff::1
* fd43:5602:29bd:ffff::1
* fd43:5602:29bd:7d::2
* fd43:5602:29bd:ffff::42


== http ==
== http ==
hier wird noch ein http Server benötigt den man so konfigurieren kann, das es pro eingehendes Interface mit gleicher IP (jedes batX bekommt eine fe80::1/64 mit nodad damit auch mehrere GWs in einer Hood die IP haben können!) eine andere Hoodfile zurück gibt. Die aktuelle Hoodfile kann vom keyxchangev2 bezogen werden und muss regelmäßig (Cronjob, alle 5 Minuten) auf den Gateways aktualisiert werden
Es wird ein http Server benötigt, der auf Port 2342 das Hoodfile ausliefert.
 
'''<span style="color:red">Dieser Schritt sollte erst ausgeführt werden, wenn der Server im KeyXchange eingetragen ist. Sonst erhält man das Hoodfile einer falschen Hood (die richtige ist ja nicht eingetragen) und verteilt dieses u.U. weiter (= Bumm, nicht gut)! Auch ein manuelles Herunterladen ohne Cronjob hat diesen Effekt.</span>'''
 
Das aktuellste Hoodfile kann vom keyxchangev2 bezogen werden und '''muss''' regelmäßig (Cronjob, alle 5 Minuten) auf dem Gateway aktualisiert werden.
 
Hier die ID für die Hoodfile raus suchen.
http://keyserver.freifunk-franken.de/v2/hoods.php?hoodfile=1


Cronjob:
Cronjob:
<pre>
<pre>
*/5 * * * * wget "http://keyserver.freifunk-franken.de/v2/index.php?lat=49.4814&long=10.966" -O /var/www/html/keyxchangev2data
*/5 * * * * wget "http://keyserver.freifunk-franken.de/v2/index.php?hoodid=DEINE_HOOD_ID" -O /var/www/fuerth/keyxchangev2data
</pre>
</pre>


Koordinaten auf die Hood anpassen:
 
'''Achtung, da die Hoodfile auf allen Gateways exakt identisch sein muss, darf sie keinesfalls verändert werden (z.b. formatieren oder Zeichen hinzufügen o.ä.).'''
 
Die Router beziehen die Datei wechselseitig von verschiedenen Quellen (KeyXchange, Gateways, etc.). Unterscheidet sich die Checksumme, wird hier jeweils neu umkonfiguriert, was bei verschiedenen Files auf zwei GWs dann gerne mal alle 5 Minuten passiert und das Netz lokal kaputt macht.
 
Koordinaten und Pfad müssen für jede Hood angepasst werden:
http://keyserver.freifunk-franken.de/v2/hoods.php
http://keyserver.freifunk-franken.de/v2/hoods.php


Mittlerweile ist die Firmware angepasst und der Webserver muss auf Port 2342 lauschen! Zeile 103: https://github.com/FreifunkFranken/firmware/blob/master/src/packages/fff/fff-hoods/files/usr/sbin/configurehood
Mehr Details zum Hood file: [[Hood file]]
 
===Für mehrere Hoods===
Man benötigt einen Webserver, der (für die gleiche Adresse) für verschiedene Interfaces verschiedene Dateien ausliefern kann.
 
Am einfachsten ist das zu realisieren, indem man den Webserver auf mehreren Ports lauschen lässt und aus und Pakete vom jeweiligen batX Port 2342 auf den jeweiligen Port redirected.
 
Beispiel '''nginx''':
<pre>
~# cat /etc/nginx/sites-enabled/nuernberg
server {
listen [::]:2001;
root /var/www/fuerth;
}
</pre>


Für mehrere Hoods:
Für weitere Hoods analog.
Im Prinzip braucht man einen Webserver, welcher aus der jeweiligen Hood heraus unter fe80::1 erreichbar ist, damit das File keyxchangev2data abgerufen werden kann. Am einfachsten ist das zu realisieren, indem man den Webserver auf mehreren Ports lauschen lässt und aus und Pakete vom jeweiligen batX Port 2342 auf den jeweiligen Port redirected. Die gewählten Ports zwischen 2001-2003 sind beliebig gewählt, your mileage may vary.


Beispiel Apache:
Beispiel '''Apache''':
<pre>
<pre>
/etc/apache2/ports.conf
~# cat /etc/apache2/ports.conf
Listen 2001
Listen 2001
Listen 2002
Listen 2002
Listen 2003
.
.
.
.


/etc/apache2/sites-available/bat.conf:
~# cat /etc/apache2/sites-available/bat.conf:
<VirtualHost *:2001>
<VirtualHost *:2001>
         ServerAdmin webmaster@localhost
         ServerAdmin webmaster@localhost
         DocumentRoot /var/www/html/bat1
         DocumentRoot /var/www/fuerth
         ErrorLog ${APACHE_LOG_DIR}/error.log
         ErrorLog ${APACHE_LOG_DIR}/error.log
         CustomLog ${APACHE_LOG_DIR}/access.log combined
         CustomLog ${APACHE_LOG_DIR}/access.log combined
Zeile 511: Zeile 581:
<VirtualHost *:2002>
<VirtualHost *:2002>
         ServerAdmin webmaster@localhost
         ServerAdmin webmaster@localhost
         DocumentRoot /var/www/html/bat2
         DocumentRoot /var/www/nuernberg
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
 
<VirtualHost *:2003>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html/bat3
         ErrorLog ${APACHE_LOG_DIR}/error.log
         ErrorLog ${APACHE_LOG_DIR}/error.log
         CustomLog ${APACHE_LOG_DIR}/access.log combined
         CustomLog ${APACHE_LOG_DIR}/access.log combined
Zeile 525: Zeile 588:
.
.


und dann noch das Redirect einbauen in /etc/fastd/fff.HOODNAME1/up.sh:
~# a2ensite bat
ip6tables -t nat -A PREROUTING -i bat1 -p tcp -d fe80::1 --dport 2342 -j REDIRECT --to-port 2001
</pre>
Und in den up.sh der anderen Hoods:
ip6tables -t nat -A PREROUTING -i bat2 -p tcp -d fe80::1 --dport 2342 -j REDIRECT --to-port 2002
ip6tables -t nat -A PREROUTING -i bat3 -p tcp -d fe80::1 --dport 2342 -j REDIRECT --to-port 2003


mkdir /var/www/html/bat1
mkdir /var/www/html/bat2
mkdir /var/www/html/bat3
..


a2ensite bat
Und dann braucht man noch die entsprechenden Redirects.
 
Diese müssen entweder mit iptables-persistent reboot-safe gemacht werden oder irgendwie anders zuverlässig beim Serverstart eingetragen werden (z.B. an die batX interface-config anhängen)
Cronjob:
*/5 * * * * wget "http://keyserver.freifunk-franken.de/v2/?lat=99.0023&long=77.8507" -O /var/www/html/bat1/keyxchangev2data
WICHTIG: KOORDINATEN DER HOOD ANPASSEN!
Analog müssen für die anderen bat-Verzeichnisse Cronjobs angelegt werden.


<pre>
ip6tables -t nat -A PREROUTING -i bat0 -p tcp -d fe80::1 --dport 2342 -j REDIRECT --to-port 2001
ip6tables -t nat -A PREROUTING -i bat1 -p tcp -d fe80::1 --dport 2342 -j REDIRECT --to-port 2002
ip6tables -t nat -A PREROUTING -i bat2 -p tcp -d fe80::1 --dport 2342 -j REDIRECT --to-port 2003
ip6tables -t nat -A PREROUTING -i bat0 -p tcp -d fe80::fff:1 --dport 2342 -j REDIRECT --to-port 2001
ip6tables -t nat -A PREROUTING -i bat1 -p tcp -d fe80::fff:1 --dport 2342 -j REDIRECT --to-port 2002
ip6tables -t nat -A PREROUTING -i bat2 -p tcp -d fe80::fff:1 --dport 2342 -j REDIRECT --to-port 2003
</pre>
</pre>


 
===Bonus===
 
Es sollte noch in jedem Hood-Verzeichnis ein File "gateway" mit dem Servernamen (z.B. "fff-hof-gw3") liegen. So kann man beim Debuggen gleich sehen, welcher Server hier lauscht.
Fastd und Apache neustarten.
Es sollte noch in jedem Verzeichnis, in dem ein keyxchangev2data liegt, ein File "gateway" liegen mit dem Servernamen z.b. "fff-hof-gw3" (ohne Anführungszeichen). So kann man beim Debuggen gleich sehen, welcher Server hier lauscht.

Aktuelle Version vom 10. Februar 2019, 00:19 Uhr

ACHTUNG

DIESE ANLEITUNG IST VERALTET. KEINESFALLS VERWENDEN!!

Dieses hier verwenden: https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen




















Hier ist grob zusammengefasst, was bei den Gateways für den KeyxchangeV2 anders ist, als bei den KeyxchangeV1 Gateways. Es sind nur Beispieldateien und müssen pro Hood unbedingt angepasst werden! Ungetestet!

Batman

Entweder batman-adv und batctl aus Debian 9 verwenden (2016.4) oder selbst kompilieren:

Zuerst git Repositories klonen:

git clone https://git.open-mesh.org/batman-adv.git
git clone https://git.open-mesh.org/batctl.git


Jeweils die aktuellste stabile Version auschecken:

git checkout v2017.3


Jeweils kompilieren und installieren:

make
sudo make install

Dafür ist mindestens build-essential, libnl-3-dev, libnl-genl-3-dev, make, pkg-config, linux-headers nötig. Bitte ergänzen, ob noch mehr notwendig ist.

Am Ende sollte 'batctl -v' sowohl für batctl, als auch für batman-adv eine Version größer 2013.4 ausgeben. (wie in diesem Beispiel 2017.3...)

# modprobe batman-adv && batctl -v
batctl 2017.3 [batman-adv: 2017.3]


ACHTUNG: Selbst kompilierte Kernelmodule funktionieren nach einem Kernelupdate nicht mehr und müssen unbedingt neu kompiliert und eingefügt werden!

Alfred Master aufsetzen

Die Nodewatcher Daten aus dem Alfred werden nicht mehr von einer zentralen VM ans Monitoring geschickt. Das übernehmen jetzt die Gateways.

Alfred

Das Gateway muss die Daten zuerst als sogenannter Alfred-Master sammeln. Dazu muss "alfred" installiert werden. (Entweder aus den Distributionsquellen oder selbst kompilieren, funktioniert analog zum batman-adv (siehe oben))

Dann muss pro bedienter Hood (also für jedes batX Interface) ein Alfred master gestartet werden (beispielsweise mit in die Interfacekonfiguration oder wie unten als systemd-Service ...):

~# cat /etc/systemd/system/alfred-bayreuth.service 
[Unit]
Description=Alfred Master
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/sbin/alfred -m -i br-bayreuth -b bat2 -u /var/run/alfred-bayreuth.sock
WorkingDirectory=/tmp
RestartSec=10
Restart=always

[Install]
WantedBy=multi-user.target

Hinweis: Wenn in der eigenen Konfiguration keine separate Bridge verwendet wird, muss beim Parameter -i das bat-Interface angegeben werden; also bei -i und -b das selbe Interface.

Alfred Monitoring Proxy

Die gesammelten Daten müssen nun noch periodisch an das Monitoring gesendet werden.

Dazu kann alfred-json von kratz00 (https://github.com/kratz00/alfred-json) in Kombination mit einem passenden curl-Skript verwenden werden. Zunächst muss alfred-json kompiliert werden (siehe README). Zusätzlich zu den in der Readme angegebenen Packeten muss noch make sowie pkg-config installiert werden.

Danach noch das curl-Script anlegen (auf eigenes Zeug anpassen! Pfade der inneren for-loop über die Sockets prüfen!):

~# cat /usr/sbin/alfred-monitoring-proxy
#!/bin/bash

api_url="https://monitoring.freifunk-franken.de/api/alfred"
fetch_ids="64"

for fetch_id in $fetch_ids
do
	for socket in /var/run/alfred-*.sock
	do
		tmp=$(mktemp)

		echo "{\"$fetch_id\": " > $tmp
		alfred-json -r "$fetch_id" -s "$socket" >> $tmp
		echo "}" >> $tmp

		if [ "$zip" = "1" ]; then
			gzip $tmp
			tmp="$tmp.gz"
			HEADER='-H "Content-Encoding: gzip" --compressed'
		fi

		curl -v -H "Content-type: application/json; charset=UTF-8" $HEADER --data-binary @$tmp $api_url

		rm "$tmp"
	done
done


Und einen passenden Cronjob dafür anlegen:

1-59/5 * * * *  sleep 9; /usr/sbin/alfred-monitoring-proxy

WICHTIG: Bitte im nächsten Abschnitt den optimalen Zeitpunkt für das senden bestimmen!

Wahl des korrekten Delays (sleep)

Das Zusammenspiel zwischen nodewatcher, Alfred und Monitoring ist komplex. Entsprechend gibt es mehr und weniger sinnvolle Zeiten, wann der Alfred Master seine Daten an das Monitoring sendet. Die folgende Tabelle soll bei der Wahl eines geeigneten Delays behilflich sein.

Anstatt eines fixen Delays ist auch eine Variante mit random möglich. Die Grenzen sollten dabei die angegebenen Bereiche nicht verlassen!

WICHTIG: Sind mehrere Alfred Master in einer Hood sollten diese ihre Daten nie gleichzeitig schicken! (Empfohlener Abstand min. 5 sec.)


Wartezeit nach Erreichen von */5 Kommentar
0 - 50 sec. Reservierter Zeitslot (nodewatcher)
  • In dieser Zeit generiert der nodewatcher die Daten und verschickt diese per Alfred.
  • Findet die Anfrage in diesem Zeitraum statt, werden die Daten von 5 Minuten zuvor verwendet.
50 - 85 sec. Empfohlener Zeitslot
  • Optimal zwischen 65 und 80 sec.
85 - 120 sec. Reservierter Zeitslot (Netmon-VM)
  • Bei einer anderen Anfrage sollten keine Fehler auftreten, aber die Last wird unnötig erhöht
120 - 175 sec. Möglicher Zeitslot
  • Die Daten werden noch rechtzeitig für die Statistiken geliefert
  • Die Routerdaten selbst sind weniger aktuell im Vergleich zum empfohlenen Slot
175 - 185 sec. Reservierter Zeitslot (Erstellung der Statistiken)
  • Findet hier eine Anfrage statt kann es gelegentlich zu Fehlern kommen
185 - 300 sec. Freier Zeitslot
  • Die Daten werden NACH Erstellung der Statistiken geliefert und müssen entsprechend lange warten
  • Optimal ist dieser Zeitslot für den zweiten Alfred Master einer Hood, sodass der Abstand zwischen den Anfragen etwa gleich ist (=> effektives Update alle 2.5 Minuten)
  • Ein Setzen auf nahe 300 Sekunden sollte vermieden werden

Tipps:

Handelt es sich um mehr als eine Minute Delay, kann die Cron Syntax ausgenutzt werden:

1-59/5 * * * * Befehl


Das löst dann 00:01, 00:06, 00:11 usw. aus, also im beginnend bei 1 bis 59 in 5-er Schritten

2-59/5 * * * * Befehl


Das löst dann 00:02, 00:07, 00:12 usw. aus, also im beginnend bei 2 bis 59 in 5-er Schritten. In Kombination mit sleep gibt es also für 130 Sekunden folgende Lösungen:

*/5 * * * * sleep 130; Befehl


oder besser:

2-59/5 * * * * sleep 10; Befehl

Zwei Minuten plus 10 Sekunden sind 130 Sekunden, aber man vermeidet den langen Sleep.

GWinfo Skript aufsetzen

Wir erhalten im Monitoring von den Routern auch Gateway-Daten, allerdings nur die MAC-Adresse des VPN Interfaces. Um dies mit den Gateway-Namen und ggf. weiteren Informationen zu unterfüttern, kann folgendes Skript verwendet und z.B. per Cron alle 5 Minuten ausgeführt werden (hier ist kein sleep o.ä. notwendig).

#!/bin/sh
#
# Gateway data script for FFF Monitoring
# Copyright Adrian Schmutzler, 2018.
# License GPLv3
#
# v1.2.1 - 2018-01-12
# - Added "grep fff" to support L2TP
#
# v1.2 - 2018-01-12
# - Added batctl command and vpnif
#
# v1.1 - 2018-01-12
# - Initial Version
#

# Config
api_url="http://monitoring.freifunk-franken.de/api/gwinfo"
batctlpath=/usr/local/sbin/batctl # Adjust to YOUR path!
hostname="MyHost" # Namen nicht zu lang machen, kein hostname.fff.irgendwas
admin1="Admin"
admin2=
admin3=
statslink="" # Provide link to stats page (MRTG or similar)

# Code
tmp=$(/bin/mktemp)
echo "{\"hostname\":\"$hostname\",\"stats_page\":\"$statslink\",\"netifs\":[" > $tmp

comma=""
for netif in $(ls /sys/class/net); do
	if [ "$netif" = "lo" ] ; then
		continue
	fi
	mac="$(cat "/sys/class/net/$netif/address")"
	batctl="$("$batctlpath" -m "$netif" if | grep "fff" | sed -n 's/:.*//p')"
	echo "$comma{\"mac\":\"$mac\",\"netif\":\"$netif\",\"vpnif\":\"$batctl\"}" >> $tmp
	comma=","
done

echo "],\"admins\":[" >> $tmp

comma=""
[ -n "$admin1" ] && echo "\"$admin1\"" >> $tmp && comma=","
[ -n "$admin2" ] && echo "$comma\"$admin2\"" >> $tmp && comma=","
[ -n "$admin3" ] && echo "$comma\"$admin3\"" >> $tmp

echo "]}" >> $tmp


/usr/bin/curl -k -v -H "Content-type: application/json; charset=UTF-8" -X POST --data-binary @$tmp $api_url
/bin/rm "$tmp"

Sowohl die Verwendung des Skriptes als auch welche Daten zur Verfügung gestellt werden bleibt dem Nutzer überlassen.

Soll z.B. keine stats_page angezeigt werden, einfach statslink="" einstellen.

network

Für keyxchangev2 werden neue Subnetze benötigt. Jede Hood aus dem KeyxchangeV2 ist ein eigenes Subnetz aus dem 10.83.0.0/16 und muss dort auch auf der Netz Seite registriert werden. Dazu werden absofort auch IPv6 Netze verwendet, diese müssen auch hier registriert werden: https://wiki.freifunk-franken.de/w/Portal:Netz/IPv6

/etc/network/interfaces

iface bat0 inet static
    address 10.83.x.1/y

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

    ## Sollten hier ip-rules für 10.0.0.0/8 oder ähnlich Interface-unabhängige Dinge stehen,
    ## bietet es sich an, diese anstatt dessen an das loopback Interface zu hängen, da diese
    ## für das ganze Freifunk-Netz gelten und entsprechend nur einmal benötigt werden und nicht
    ## von speziellen Interfaces abhängig sein sollten.

    ## Je nachdem, wie der DHCP Server gestartet wird, ist hier möglicherweise noch folgendes nötig
    post-up invoke-rc.d isc-dhcp-server restart

    # ip route
    post-up ip route replace 10.83.x.0/y dev $IFACE proto static table fff
    post-down ip route del 10.83.x.0/y dev $IFACE proto static table fff

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::fff: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
iface ffffuerthVPN inet manual
    post-up batctl -m bat0 if add $IFACE
    post-up ip link set up $IFACE
    post-up ifup bat0
    post-down ifdown bat0
    port-down ip link set down $IFACE

Die Interfaces müssen nicht manuell (ifup bla) gestartet werden, dies erledigt fastd.

Jedes Interface wird an eine eigene Link Local Adresse gebunden (fe80::IRGENDWAS/64), über die es von anderen Diensten - beispielsweise radvd - angesprochen werden kann.


ACHTUNG: Die oben stehende Konfiguration enthält keine IP(6)-Rules, die dem Server sagen, dass er für die entsprechenden Subnetze in die fff-table gucken muss!

Am einfachsten lässt sich das durch das statische Anfügen von wenigen rules beim starten des loopback-Interfaces lösen:

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.

fastd

fastd wird komplett anders als früher konfiguriert. Das früher nötige Verwaltungsscript darf KEINESFALLS(!!) ausgeführt werden, auch der Cronjob ist nicht mehr nötig. Falls die IP noch im alten KeyXchange eingetragen ist, sollte sie hieraus unbedingt entfernt werden (KeyXchange Admin fragen) Bitte nur noch folgende Anleitung folgen:

/etc/fastd/ffffuerthVPN/fastd.conf

# Log errors to stderr
log level error;

# Log warnings to a log file
log to syslog as "ffffuerthVPN" level warn;

# Set the interface name
interface "ffffuerthVPN";

# Disable encryption
method "null";

# Bind to a fixed port, IPv4 only
bind any:10004;

# fastd need a key but we don't use them: generate by "fastd --generate-key"
secret "c00a286249ef5dc5506945f8a3b413c0928850214661aab866715203b4f2e86a";

# Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE)
# (see MTU selection documentation)
mtu 1426;

on up "/etc/fastd/up.sh";
on down "/etc/fastd/down.sh";

secure handshakes no;

on verify "/etc/fastd/verify.sh";


/etc/fastd/down.sh

#!/bin/sh
/sbin/ifdown $INTERFACE


/etc/fastd/up.sh

#!/bin/sh
/sbin/ifup $INTERFACE


/etc/fastd/verify.sh

#!/bin/sh
return 0


danach:

systemctl enable fastd
systemctl start fastd


Der Server muss dann händisch in den keyxchangev2 eingetragen werden. Dazu sind folgende Infos nötig:

  • IP Adresse des Gateways
  • Port von fastd
  • Public Key von fastd (die Router müssen den Pub-Key vom Gateway kennen sonst funktioniert es nicht, das Gateway muss KEINE Keys vom Router kennen)
  • Servername
  • Hood


Weiterhin erforderlich ist ein B.A.T.M.A.N Gateway Selection Script.

Gateways untereinander verbinden

Die Gateways sollten sich im Hood-Layer2 auch noch untereinander verbinden, das ist aktuell noch nicht umgesetzt.

babel

siehe hier

GRE Tunnel

Die GRE Tunnel brauchen nun auch eine IPv6 aus dem Transfernetz. (siehe babel-Seite oben)

Es müssen dann noch folgende IP-Rules existieren (beispielsweise wie oben beschrieben am loopback-Interface):

  • from all to fc00::/7 lookup fff
  • from fc00::/7 lookup fff

radvd

Damit radvd nicht die fe80::1 als Source-IP verwendet (geht ziemlich kaputt), muss mindestens Version 2.16 installiert sein. Das kann man so überprüfen:

radvd -v


In den Debian 9 Packetquellen wird leider noch 2.15 ausgeliefert. Man kann radvd aber aus Debian 10 (aktuell testing) backporten.

Damit nicht alle Pakete auf die buster-Version aktualisiert werden:

/etc/apt/preferences.d/limit-buster

Package: *
Pin: release n=buster
Pin-Priority: 150


Dann die buster Packetquellen einfügen:

/etc/apt/sources.d/buster.list

deb http://ftp.de.debian.org/debian/ buster main


Und radvd installieren:

apt-get update
apt-get -t buster install radvd


radvd muss dann in jeder Hood Router Advertisements senden und die entsprechende ULA als Autonomous Prefix announcen:

/etc/radvd.conf

interface bat0 { 
        AdvSendAdvert on;
	AdvDefaultLifetime 0;
        AdvRASrcAddress {
                fe80::IRGENDWAS;
        };
        prefix fd43:5602:29bd:x::/64 { 
                AdvOnLink on; 
                AdvAutonomous on; 
        };
        route fc00::/7 {
        };
};


ACHTUNG: Die fe80:: die bei AdvRASrcAddress eingetragen ist muss fest an das batX Interface gebunden werden. (siehe interface-config oben). Die Adresse zufällig zu generieren bietet sich an, damit die Adressen in jeder Hood eindeutig sind. Es muss die gleiche Adresse sein, die in /etc/network/interfaces an das jeweilige batX Interface gebunden wurde.


AdvRASrcAddress ist nötig, damit die Router Advertisements nicht von der fe80::1 gesendet werden. Denn wenn zwei Gateways verschiedene Router Advertisements von der gleichen Link Local Adresse senden, sind die Clients verwirrt und es kommt unter Umständen zu einer instabilen Verbindung.

systemctl restart radvd

ntp Server

Es werden routbare v6 Adressen aus den ULA Bereich verwendet. Jede Hood kann, muss aber nicht einen eigenen ntp Server bereit stellen. Aktuell sind folgende NTP Server in Betrieb und können verwendet werden:

  • fd43:5602:29bd:ffff::1
  • fd43:5602:29bd:7d::2
  • fd43:5602:29bd:ffff::42

http

Es wird ein http Server benötigt, der auf Port 2342 das Hoodfile ausliefert.

Dieser Schritt sollte erst ausgeführt werden, wenn der Server im KeyXchange eingetragen ist. Sonst erhält man das Hoodfile einer falschen Hood (die richtige ist ja nicht eingetragen) und verteilt dieses u.U. weiter (= Bumm, nicht gut)! Auch ein manuelles Herunterladen ohne Cronjob hat diesen Effekt.

Das aktuellste Hoodfile kann vom keyxchangev2 bezogen werden und muss regelmäßig (Cronjob, alle 5 Minuten) auf dem Gateway aktualisiert werden.

Hier die ID für die Hoodfile raus suchen. http://keyserver.freifunk-franken.de/v2/hoods.php?hoodfile=1

Cronjob:

*/5 * * * * wget "http://keyserver.freifunk-franken.de/v2/index.php?hoodid=DEINE_HOOD_ID" -O /var/www/fuerth/keyxchangev2data


Achtung, da die Hoodfile auf allen Gateways exakt identisch sein muss, darf sie keinesfalls verändert werden (z.b. formatieren oder Zeichen hinzufügen o.ä.).

Die Router beziehen die Datei wechselseitig von verschiedenen Quellen (KeyXchange, Gateways, etc.). Unterscheidet sich die Checksumme, wird hier jeweils neu umkonfiguriert, was bei verschiedenen Files auf zwei GWs dann gerne mal alle 5 Minuten passiert und das Netz lokal kaputt macht.

Koordinaten und Pfad müssen für jede Hood angepasst werden: http://keyserver.freifunk-franken.de/v2/hoods.php

Mehr Details zum Hood file: Hood file

Für mehrere Hoods

Man benötigt einen Webserver, der (für die gleiche Adresse) für verschiedene Interfaces verschiedene Dateien ausliefern kann.

Am einfachsten ist das zu realisieren, indem man den Webserver auf mehreren Ports lauschen lässt und aus und Pakete vom jeweiligen batX Port 2342 auf den jeweiligen Port redirected.

Beispiel nginx:

~# cat /etc/nginx/sites-enabled/nuernberg
server {
	listen [::]:2001;
	root /var/www/fuerth;
}

Für weitere Hoods analog.

Beispiel Apache:

~# cat /etc/apache2/ports.conf
Listen 2001
Listen 2002
.
.

~# cat /etc/apache2/sites-available/bat.conf:
<VirtualHost *:2001>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/fuerth
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:2002>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/nuernberg
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
.
.

~# a2ensite bat


Und dann braucht man noch die entsprechenden Redirects. Diese müssen entweder mit iptables-persistent reboot-safe gemacht werden oder irgendwie anders zuverlässig beim Serverstart eingetragen werden (z.B. an die batX interface-config anhängen)

ip6tables -t nat -A PREROUTING -i bat0 -p tcp -d fe80::1 --dport 2342 -j REDIRECT --to-port 2001
ip6tables -t nat -A PREROUTING -i bat1 -p tcp -d fe80::1 --dport 2342 -j REDIRECT --to-port 2002
ip6tables -t nat -A PREROUTING -i bat2 -p tcp -d fe80::1 --dport 2342 -j REDIRECT --to-port 2003
ip6tables -t nat -A PREROUTING -i bat0 -p tcp -d fe80::fff:1 --dport 2342 -j REDIRECT --to-port 2001
ip6tables -t nat -A PREROUTING -i bat1 -p tcp -d fe80::fff:1 --dport 2342 -j REDIRECT --to-port 2002
ip6tables -t nat -A PREROUTING -i bat2 -p tcp -d fe80::fff:1 --dport 2342 -j REDIRECT --to-port 2003

Bonus

Es sollte noch in jedem Hood-Verzeichnis ein File "gateway" mit dem Servernamen (z.B. "fff-hof-gw3") liegen. So kann man beim Debuggen gleich sehen, welcher Server hier lauscht.