Freifunk-Gateway aufsetzen/keyxchangev2 VERALTET

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!

Batman

Hab ich leider schon installiert :( Wer es noch vor sich hat bitte hier dokumentieren, hilfreich vermutlich:

https://www.open-mesh.org/projects/open-mesh/wiki/UsingBatmanGit

am Ende sollte bei

root@vm3-gw-cd1:/home/christiand# modinfo batman-adv
filename:       /lib/modules/4.9.0-3-amd64/updates/net/batman-adv/batman-adv.ko
alias:          net-pf-16-proto-16-family-batadv
alias:          rtnl-link-batadv
version:        2017.2-6-ge43855a
description:    B.A.T.M.A.N. advanced
author:         Marek Lindner <mareklindner@neomailbox.ch>, Simon Wunderlich <sw@simonwunderlich.de>
license:        GPL
srcversion:     78D5FE0D577C2CC76BC6FFC
depends:        libcrc32c,bridge,crc16
vermagic:       4.9.0-3-amd64 SMP mod_unload modversions 
root@vm3-gw-cd1:/home/christiand# 

Bei Version etwas größer als 2013.4 stehen (wie in diesem Beispiel 2017.2...)

Alfred Master aufsetzen

folgt...

network

/etc/network/interfaces

device: bat0
iface bat0 inet manual
post-up ifconfig $IFACE up
    ##Einschalten post-up:
    # IP des Gateways am B.A.T.M.A.N interface:
    post-up ip addr add 10.83.8.1/22 dev $IFACE
    post-up ip -6 addr add fe80::1/128 dev $IFACE
    post-up ip -6 addr add fd43:5602:29bd:4::1/64  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.83.8.0/22 dev $IFACE proto static table fff
    post-up ip -6 route replace fd43:5602:29bd:4::/64 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.83.0.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
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

fastd

root@vm3-gw-cd1:/etc/fastd/fff.fuerth# cat down.sh 
#!/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 everything to a log file
log to syslog as "ffffuerth" level info;
# Set the interface name
interface "ffffuerthVPN";
# Support xsalsa20 and aes128 encryption methods, prefer xsalsa20
#method "xsalsa20-poly1305";
#method "aes128-gcm";
method "null";
# Bind to a fixed port, IPv4 only
bind any:10004;
# fastd need a key but we don't use them
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/fff.fuerth/up.sh";
on post-down "/etc/fastd/fff.fuerth/down.sh";
secure handshakes no;
on verify "/etc/fastd/fff.fuerth/verify.sh";
root@vm3-gw-cd1:/etc/fastd/fff.fuerth# cat up.sh 
#!/bin/sh
/sbin/ifup $INTERFACE
root@vm3-gw-cd1:/etc/fastd/fff.fuerth# cat verify.sh 
#!/bin/sh
return 0
root@vm3-gw-cd1:/etc/fastd/fff.fuerth# 

root@vm3-gw-cd1:/home/christiand# cat /etc/systemd/system/fastd.service 
[Unit]
Description=fastd

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

[Install]
WantedBy=multi-user.target

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 (aktuell v4)
• 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

Gateways untereinander verbinden

Die Gateways müssen sich im fastd auch noch untereinander verbinden, hier fehlt noch $config

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

root@vm3-gw-cd1:/etc/fastd/fff.fuerth# cat /etc/babeld.conf 
# For more information about this configuration file, refer to
# # babeld(8)
#
 interface vm1fffgwcd1 wired true max-rtt-penalty 128
 export-table 10
 import-table 10
 
# redistribute local ip ::/0 le 0 metric 128
 redistribute metric 128
# redistribute local ip 10.0.0.0/8
# redistribute local deny
#
 local-port 33123
# #local-port-readwrite 34567
# 
root@vm3-gw-cd1:/etc/fastd/fff.fuerth# 

GRE TUnnel

Die GRE Tunnel brauchen auch eine ipv6 aus dem Transfernetz.

...
post-up ip -6 addr add fd43:5602:29bd:ffff::1 dev vm1fffgwcd1
...

radvd

root@vm3-gw-cd1:/etc/fastd/fff.fuerth# cat /etc/radvd.conf 
interface bat0 { 
        AdvSendAdvert on;
        MinRtrAdvInterval 60; 
        MaxRtrAdvInterval 300;
	AdvDefaultLifetime 0;
        prefix fd43:5602:29bd:4::/64 { 
                AdvOnLink on; 
                AdvAutonomous on; 
        };
        route fc00::/7 {
        };
};

/etc/init.d/radvd restart

ntp Server

jedes Gateway muss unter fe80::1 einen ntp Server bereit stellen! evtl. wird doch eine routbare ula v6 verwendet? Noch unsicher!

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) 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