Freifunk-Gateway aufsetzen

Achtung: Die Seite wird aktuell für den KeyxchangeV2 umgebaut. Daher könnte sie zeitweise Inkonsistenzen enthalten und wird sich inhaltlich stark verändern. Den letzten V1-Stand gibt es hier

Preface

Für das Aufsetzen eines Freifunk-Gateway gibt es kein universelles Kochrezept. Auch erfahrene Admins erfahren bei der Installation kleinere und grössere Herausforderungen, die es zu überwinden gilt. Unterschiedliche Softwareinstallationen, Netzwerkkonfigurationen, Hoster und VPN Anbieter können Anpassungen zu der hier präsentierten Vorgehensweise notwendig werden lassen, z.B. indem Pakete nach installiert werden oder Netzwerkkonfigurationen angepasst werden müssen. Um dies zu erleichtern, versucht der Artikel nicht nur die Konfiguration darzulegen, die in diesem spezifischen Fall funktioniert hat ("Know-How"), sondern versucht auch kurz auf die Hintergründe einzugehen, um ggf. eine Anpassung zu erleichern ("Know-Why").

Freifunk Franken ist "Development in Progress", d.h. eine Konfiguration die heute funktioniert, wird morgen durch eine andere und vielleicht sogar bessere abgelöst. Ein einmal aufgesetztes Gateway muss sich so der Entwicklung anpassen.

Für Rat und Tat empfiehlt sich die Freifunk Franken Development und die Freifunk Franken Gateway Mailingliste.

Zum den Änderungen vom KeyxchangeV1 zum KeyxchangeV2 Gateway geht's hier: https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/keyxchangev2

Referenzen / Andere Freifunk HowTo's

• http://wiki.freifunk.net/Freifunk_Hamburg/Gateway
• http://wiki.mag.lab.sh/wiki/Freifunk_Fulda/Gateway

Voraussetzungen

Was der Server können muss

• Öffentliche IPv4 und IPv6 Adresse
• Kernelmodule laden
• Nur relativ wenig CPU und RAM nötig
• dafür relativ viel Traffic (Je nach Größe und Anzahl der Hoods durchaus im ein- bis niedrigen zweistelligen TB Bereich)

Was der Betreiber mitbringen sollte

• Grundlegende Kenntnisse mit IP-Routing (IPv4 und IPv6)
• Motivation, etwas [jede Menge] dazuzulernen und sich aktiv mit der Materie auseinanderzusetzen.
• Das Freifunk Netz ist der optimale Ort, um sich in dieser Richtung neue Kenntnisse anzueignen - zumindest wenn man sich dann auch damit (und. v.a. mit den auftretenden Problemen) auseinandersetzt.
• Es gibt viele nette Leute im IRC, die immer gerne helfen, wenn die Motivation da ist, sich auch selbst mit dem Problem zu befassen.
• Für die schnelle Abstimmung unter den GW Betreibern sollte sich jeder Betreiber auf der freifunk-gateway Mailingliste setzen. Die "große" Liste und die dev-Liste sind ebenfalls hilfreich.
• Ohne Vorkenntnisse ist es schwierig aber ganz und gar nicht unmöglich ein Gateway aufzusetzen. Soweit es nicht bei dem Kenntnisstand bleiben soll, wird auch hier gerne geholfen.
• Bereitschaft mitzuhelfen, das Wiki aktuell zu halten, damit die Ressourcenplanung (IPs!) funktioniert und für Notfälle die wichtigsten Infos und Ansprechpartner zu den Servern vorhanden sind. Die wichtigsten Seiten sind Server, Portal:Netz und Portal:Netz/IPv6.
• Ein wenig Zeit - sowohl fürs Aneignen des Verständnisses als auch fürs Aufsetzen an sich. Gehe erstmal von ganz grob 5-20 Stunden Arbeitszeit aus, um von einem "nackten" Server zu einem voll funktionstüchtigen GW zu kommen, der ja doch aus recht vielen verschiedenen Diensten besteht. Nach der Ersteinrichtung sollte man regelmäßig ein wenig Zeit investieren, um zu schauen, ob alles in Ordnung ist, Updates zu fahren, Änderungen in der Infrastruktur nachzupflegen etc.

Was das Gateway können muss

• fastd VPN
• Batman (Compat15)
• DHCP
• Router Advertisements
• Routing
• Babel Routing Protokoll
• Webserver für Hoodfiles

Näheres ist unter Dienste beschrieben.

Anonymisierung (Störerhaftung)

Sofern der Server nicht über einen Uplink verfügt, wo es egal ist was durchgeht (unseriöse Bulletproof-Hoster), möchte man vermutlich den Traffic aus dem Freifunk-Netz durch ein VPN ins Internet schieben.

Auf längere Sicht, wäre es natürlich wünschenswert, wenn die Problematik der Störerhaftung in ihrer derzeitigen Form wegfällt um beispielsweise eine dezentralere Infrastruktur zu erlauben.

Folgende VPN-Anbieter sind zu diesem Zeitpunkt jedoch empfehlenswert:

• Mullvad (Schweden, Niederlande)
  • Bis zu drei gleichzeitige Verbindungen
  • Kann man anonym mit Bitcoin bezahlen
  • Serverauswahl über die ausgelieferte OpenVPN-Konfiguration
    • Server in den Niederlanden sind abends oft stark ausgelastet
  • (Gute Erfahrungen in Lübeck)

• Integrity VPN (Schweden, Port80)
  • Drittes Oktett durch Auswahl des normalerweise per round.robin-dns ausgewählten OpenVPN-Servers bestimmbar, das letzte Oktett ist immer gleich. Somit muss man sich keine dynamisch vergebenen IP-Adressen mit anderen teilen. Verbindungen daher durch die Anzahl der OpenVPN-Server (derzeit 3; unterschiedliche Ports nicht ausprobiert) beschränkt.
  • Hat eine überaus seriöse Webseite und eine Ltd. erfunden.™
  • Hat schon mal was von IPv6 gehört. Nutzt es zurzeit jedoch nur für SEO.
  • Blockiert Port 25 derzeit nicht.
  • Ist ein ein neuer Anbieter, der _bisher_ unausgelastet wirkt.
  • sind derzeit noch nicht nicht overselled und haben ihren Krams scheinbar halbwegs sauber konfiguriert

• Ipredator (Schweden, Niederlande, Deutschland)
  • (Glänzen nicht durch Kompetenz, da sie lange Zeit nur PPTP angeboten haben)
  • Mögen schnelle Reconnects nicht -> manchmal muss man OpenVPN ein paar Stunden deaktivieren, bevor es wieder funktioniert.
  • Möchten bald auch IPv6 anbieten.
  • Angeblich Reseller von relakks

• Cyberghost
  • blockt alle SMTP Ports!!

• Perfect Privacy

• AzireVPN

Ungetestet:

• Anonine VPN (Portlane)
• privacy.io (Portlane)
• prq.se (Eigenes Netz, teuer)
• Arethusa VPN (Loggen in Frankreich, andere Server angeblich nicht)

Anbindung an andere Netze

Es gibt drei relativ relevante Netzwerke bei denen es sich lohnt, das lokale Netz damit zu verbinden:

• InterCity-VPN zwischen den meisten Freifunknetzen
  • BGP
  • kleine Übsicht der http://www.ddmesh.de/topology/ic-vpn-verbindungen.html
  • Mehr Infos http://wiki.freifunk.net/IC-VPN

• DN42
  • BGP
  • Experimentelles Darknet zur Erprobung von Routing-Technologien und so weiter, wird privat betrieben. Viel interessantes Zeugs™
  • Hat Routen ins ChaosVPN und IC-VPN, wer faul ist bei der Konfiguration deckt damit also alles™ ab nicht alle Routen vom IC-VPN oder ChaosVPN werden im DN42 verteilt, ob man das will kann ggf nochmal besprechen.

• ChaosVPN
  • Tinc
  • Relativ großes „Darknet“ zwischen vielen Hackerspaces auf der ganzen Welt.

Server-Anbieter die empfehlenswert sind

• de-punkt (Databurg, FFM)
  • Schneller Speicher, gut bezahlbar, KVM, nur Traffic-Flat™® das übliche.
• Hetzner (Falkenstein)
  • Bezahlbarer Extratraffic 1,19 €/TB, KVM
• colorhost (über 23media, Global Switch, FFM)
• Untersagt Nutzung für Freifunk (http://colorhost.de/server/vserver/kvm/small/)
  • Achtung: Nur Xen oder Xen HVM funktionieren
• xirra (Core-Backbone, NBG)
  • KVM, TB-Traffic zu 5,95€. Langweilig und funktioniert. Pflegt bisher einen guten Kontakt zu Kunden.
• BuyVM
  • Begrenztes Angebot, das in Stößen rausgegeben wird. 2.50$/TB Extratraffic. Nur KVM ist brauchbar für diesen Zweck. USA Ost- und Südküste. TOS sagt, dass man da theoretisch kein weiteres VPN ins Netz brauchen würde.
• webhod
  • 9,99 € für die kleinste KVM im Monat[1]

Server-Anbieter die nicht empfehlenswert sind

• WRZhost
  • Aktivierung des V-Servers erst auf mehrfache Nachfrage, anschließend falsches Betriebssystem. Außerdem nur OpenVZ und somit nicht für FreiFunk nutzbar. Für andere Zwecke sicher brauchbar, da gut angebunden und offshore.

Dienste

B.A.T.M.A.N.

B.A.T.M.A.M. wird bei uns als Layer2 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.

Die Version, die beim Kernel von Debian Stretch mit dabei ist (v2016.4) ist Compat15, was die aktuell verwendete Compat-Version ist. (siehe hier)

Wenn man möchte, kann man sich die aktuellste Version aus dem Open-Mesh Git kompilieren und installieren.

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

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

B.A.T.M.A.N. Advanced wird mit dem Tool batctl gesteuert. Das muss entsprechend installiert werden. Hier kann ebenfalls die Version aus den Debian Paketquellen oder die selbstkompilierte verwendet werden.

apt install batctl

FastD

Die Verbindung zwischen Gateway und zentralen Routern wird über einen fastd-Tunnel realisiert.

Die fastd-Version aus den Stretch Paketquellen ist aktuell und kann (und sollte) verwendet werden.

apt install fastd

l2tp Tunneldigger

Die Verbindung zwischen Gateway und zentralen Routern kann auch über einen l2tp Tunnel hergestellt werden.

Installation und Konfiguration des Tunneldigger-Brokers: L2TP und Tunneldigger

Babel

Innerhalb von Freifunk Franken wird Babel als IP-Routingprotokoll verwendet. Damit sind alle Gateways und damit alle Hoods miteinander verbunden. Das ist für hoodübergreifenden Traffic, DNS-Verkehr, wenn kein eigener bzw. nur ein Stub eingerichtet wird, für Verbindungen ins IC-VPN etc. wichtig.

Für Linux kann babeld aus den Stretch Paketquellen als Daemon für Babel verwendet werden. apt install babeld

Auch hier gilt wieder: Die Version aus den Debian Paketquellen ist nicht super aktuell, in babeld-1.8.0 gab es einige Änderungen.
Auch babeld kann selbst kompiliert werden. Sourcen gibts hier

babeld importiert und exportiert alle Routen in/aus einer Routingtabelle. Es bietet sich an, für fff eine neue Tabelle anzulegen und zu benennen. Dazu Tabellennummer und Name in /etc/iproute2/rt_tables eintragen:

10	fff

Tunnel für den Backbone

TODO

Grundinstallation des Servers

Die Installation des Betriebssystems, Absicherung des Servers, Installieren von Updates usw. sind NICHT Gegenstand dieser Anleitung. Trotzdem kurz einige Hinweise.

Folgendes sollte unbedingt beachtet werden

• Betriebssystem aktuell halten. Bei Linux wird dafür für gewöhnlich eine Paketverwaltung verwendet
  • Bei Debian ist das apt
  • apt update aktualisiert die Paketquellen
  • apt upgrade aktualisiert die Pakete
• Sicherheit
  • SSH Login nur mit Keys, Login per Passwort abschalten (siehe hier
  • root-Login per SSH höchstens per Key, besser abschalten
  • Siehe hier für weitere Hinweise.

IP-Forwarding

Um Anfragen, die das Gateway erreichen, weiterzuleiten, muss IP-Forwarding aktiviert werden.

Manuell geht dies über: echo "1" > /proc/sys/net/ipv4/ip_forward

echo "1" > /proc/sys/net/ipv6/conf/default/forwarding

echo "1" > /proc/sys/net/ipv6/conf/all/forwarding

1. Sonst landen ICMP-Fehlerpakete auf eth0 - mit source-IP 10.50.x.y...
2. https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

echo 1 > /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr

Dauerhaft lässt sich IP-Forwarding in /etc/sysctl.conf aktivieren: vi /etc/sysctl.conf

.. um dort die Abschnitte einzukommentieren, die das Forwarding steuern:

.
.
.
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
#  Enabling this option disables Stateless Address Autoconfiguration
#  based on Router Advertisements for this host
net.ipv6.conf.all.forwarding=1
.
.
.

Um ICMP-Fehlerpakete auf eth0 zu vermeiden, die als src-IP 10.50.x.y haben (böseböse!) dann noch

# Sonst landen ICMP-Fehlerpakete auf eth0 - mit source-IP 10.50.x.y...
# https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
net.ipv4.icmp_errors_use_inbound_ifaddr = 1

einfügen

Routing Tabelle für Freifunk

Für die Routen im Freifunk Franken Netz sollte eine eigene Routingtabelle deklariert werden.

Dazu Tabellennummer und Name in /etc/iproute2/rt_tables eintragen:

10     fff

Der Inhalt der Routingtabelle kann später mit ip route show table fff angezeigt werden.

Konfigurieren des Freifunk-Gateways

Nachdem nun die erforderlichen Softwarepakete auf dem Gateway installiert wurden, kann man das Gateway als solches einrichten. Die Konfiguration wird exemplarisch für das Einrichten eines GW's in der Fürther Hood beschrieben, wobei erläutert wird, welche Anpassungen für nicht-Fürther Hoods gemacht werden müssen.

IPv4 des Gateways, IP-Bereich der Hood und DHCP Range des Gateway

Das Gateway benötigt eine IP aus jedem verbundenen Layer-2 Netz.

Für jede Hoods sucht man sich dafür unter Portal:Netz bzw. Portal:Netz/IPv6 eine IPv4 bzw. IPv6 Adresse (bei IPv4 aus dem statischen Bereich) der Hood aus.
Damit es keine Doppelbelegungen gibt, muss diese auch gleich "reserviert" werden, indem das Wiki entsprechend editiert wird.

Für die Peerings verwenden wir Adressen aus einem speziell dafür vorgesehenen Bereich.
Die Adressen werden mit einer /32 Netzmaske an die Peering-Interfaces gehängt, um die entsprechenden Routen kümmert sich dann babel. So spart man sich ein paar IPv4 Adressen, da nicht immer ein /31 Subnetz für ein Peering drauf geht und (wenn auch unsauber) für jedes Peeringinterface die gleiche Adresse genutzt werden kann.
Bei IPv6 genügen die Link-Local Adressen.

Möchte man auf seinem Gateway Dienste unabhängig von den Hoods anbieten, kann dafür die Peering-IP (für IPv6 ist daher ebenfalls ein Bereich dafür vorgesehen) gut verwendet werden.

An dieser Stelle sollte man sich unbedingt mit Subnetzen und der CIDR-Notation vertraut machen, falls einem das (noch) Fremdworte sind.
Ein entsprechender IP-Rechner findet sich z.B. hier.

Für die Hoods muss bei IPv4 noch ein Bereich festgelegt werden, aus dem dann später Adressen verteilt werden. Dieser muss:

• innerhalb des Subnetzes der Hood liegen.
• innerhalb der Hood eindeutig sein. (Darf sich nicht mit dem Adressbereich überschneiden, den andere DHCP Server in der Hood verwalten)
• vollständig außerhalb des statischen Bereichs der Hood liegen.

Gleichzeitig teilt der DHCP-Server den Clients mit, welchen DNS-Server und welches Default-Gateway die Clients verwenden sollen. Die Gesamtgröße aller verwalteten DHCP-Bereiche des Servers hat so direkten Einfluss auf die Arbeitslast, die der den Clients zugeteilte DNS-Server und der zugeteilte Internet-Gateway später sehen.

Bei IPv6 wird nur Gateway, DNS-Server und Subnetz per Router Advertisement in der Hood bekannt gemacht, den Rest erledigen die Clients.

fastd

https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/VPN/fastd

B.A.T.M.A.N Netzwerk-Interface, fff Routingregeln und -tabelle

https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/interface

Testen von B.A.T.M.A.N, fastd und Autostart

Hierfür booten wir das Gateway am besten erst mal neu: reboot & exit und starten das fast.d Startskript manuell: /etc/fastd/fff_beispiel_fastd.sh & Beim Erststart werden Schlüsselpaare generiert und ausgetauscht, es kann also etwas dauern.

Danach sollte der Aufruf von... pgrep fastd ... mit der Prozess-ID beantwortet werden: Fastd läuft in dem Fall.

Ein Aufruf von ifconfig: ifconfig

sollte die neu erstellten Interfaces bat0 und ffffuerthVPN zurückliefern. Exemplarisch und als Auszug:

bat0      Link encap:Ethernet  HWaddr ea:95:50:07:f7:27  
          inet addr:10.50.32.5  Bcast:0.0.0.0  Mask:255.255.248.0
          inet6 addr: fe80::e895:50ff:fe07:f727/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1089992 errors:0 dropped:0 overruns:0 frame:0
          TX packets:849698 errors:0 dropped:1728 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:141311612 (134.7 MiB)  TX bytes:1052934594 (1004.1 MiB)

.
.
.
ffffuerthVPN Link encap:Ethernet  HWaddr e6:3b:f3:b7:fc:db  
          inet6 addr: fe80::e43b:f3ff:feb7:fcdb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1426  Metric:1
          RX packets:32389694 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2699525 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:4193328694 (3.9 GiB)  TX bytes:1384843740 (1.2 GiB)
.
.
.

Aus dem ifconfig Auszug für bat0 sollte die eingerichtete IP des Gateways und die Netzmaske hervorgehen. + IPv6

Die Abfrage der IP-Regeln: ip rule

sollte die oben definierten Regeln wieder spiegeln (fff Tabelle für Traffic, der entweder über bat0 oder 10.0.0.0/8 rein- oder rausgeht):

32757:	from all to 10.0.0.0/8 lookup fff 
32758:	from 10.0.0.0/8 lookup fff 
32759:	from all iif bat0 lookup fff 

Eine Abfrage der fff-Routing Tabelle ip route show table fff

sollte die B.A.T.M.A.N Route (Device bat0) in das Netzwerk der eingerichtete Hood ergeben. In diesem Beispiel ist es die Fürther Hood:

10.50.32.0/21 dev bat0  scope link

ganze IPv6 Zeug fehlt noch

Ein Aufruf von "batctl o" batctl o

ergibt eine Liste der MAC-Adressen von unseren nächsten Nachbarn. Exemplarisch und als Auszug:

[B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: ffffuerthVPN/e6:3b:f3:b7:fc:db (bat0)]
  Originator      last-seen (#/255)           Nexthop [outgoingIF]:   Potential nexthops ...
96:43:c4:2e:73:68    0.004s   (255) 96:43:c4:2e:73:68 [ffffuerthVPN]: 96:43:c4:2e:73:68 (255)
.
.
.

Auf neues Batman updaten (Versionsanzeiger)

Hat soweit alles geklappt, kann das Startscript /etc/fastd/fff_beispiel_fastd.sh bei jedem Systemstart ausgeführt werden, indem es z.B. in /etc/rc.local eingetragen wird: vi /etc/rc.local Hier spendieren wir einen Eintrag, der fastd mit 10 Sekunden Verzögerung bei jedem Systemstart mitstartet:

# launch fastd with 10 seconds delay
(sleep 10; sh /etc/fastd/fff_beispiel_fastd.sh) &

Zusätzlich muss ein Cronjob angelegt werden, der das Skript z.B. alle 10 Minuten ausführt: crontab -e Nun folgendes eingeben:

*/5 * * * * sleep 10; sh /etc/fastd/fff_beispiel_fastd.sh

und /etc/init.d/cron restart

radvd

https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/radvd

ntp Server

https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/ntp

http Server für Hoodfile

https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/http

Alfred Master aufsetzen

https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/Alfred

OpenVPN-Tunnel einrichten

https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/VPN-Exit

DNS Server

https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/DNS

B.A.T.M.A.N Gateway Selection

ACHTUNG: Dieses Script sollte erst aktiviert werden wenn sicher feststeht das:

• Babel alle Routen übertragen hat, "ip r s table fff" gibt viele routen zu 10.x.x.x und 172.x.x.x aus
• Der Server als Gateway in den KeyXchange eingetragen ist (muss man wissen, falls unbekannt bitte an die dev Liste fragen oder einen KeyXChange Admin)
• Ein funktionierender DHCP Server läuft

Man sich also prinzipiell sicher ist, das der Server komplett fertig ist. Dies sollte der allerletzte Schritt sein wenn der Server eigentlich schon Online ist.

Wird das Script vorher aktiviert, announced man sich im Batman als Gateway obwohl man keine IPs vergibt (oder nicht richtig routet). Dies führt dazu das Clients keine IPs oder kein Routing ins Freifunknetz bekommen was sehr unschön ist.

Ab Version 0.5.1 der Router Firmware ist die B.A.T.M.A.N Gateway Selection aktiviert worden. Der Router wählt sein bevorzugtes Gateway anhand der Verbindungsqualität und dessen noch verfügbaren Bandbreite aus und selektiert das GW für die Clients vor.

Die noch verfügbare Bandbreite muss vom Gateway an die Router annonciert werden. Hierfür muss man vorab die maximal zur Verfügung stehende Up- und Downloadkapazität des Gateways festlegen. Dies kann z.B. unter folgenden Gesichtspunkten geschehen:

• Bandbreite der Netzanbindung (z.B. 100 Mbit/sec, gesplittet in 50 Mbit/sec up/down)
• Freier Traffic des Hosters (z.B.: 5 TByte/Monat, entspricht einer Grundlast von 15 Mbit/sec, z.B. gesplittet in 5 Mbit/sec down, 10 Mbit/sec up)
• Erfahrungswerten / eigenes Ermessen
• Bandbreite, bei dem der Gateway Prozessor ausgelastet ist

Eventuell muss zuerst bc nachinstalliert werden, falls nicht vorhanden: apt-get install bc

Wir sollten nur die Bandbreite annoncieren, die tatsächlich noch frei ist: Also unsere Gesamtkapazität abzüglich der verwendeten Bandbreite. Hierfür kann man ein Skript verwenden, dass die aktuell verwendete (zeitlich gemittelte) Bandbreite vom Gateway ausliest, mit der Gesamtkapazität vergleicht und die noch freie Bandbreite an die GW Selection weitergibt.

Importieren des Skripts aus einer Vorlage: wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/dyn_announce_gw_bw.sh -P /usr/local/bin/

Alternativ kann das Skript auch als leere Datei erstellt werden: touch /usr/local/bin/dyn_announce_gw_bw.sh

Wir machen das Skript ausführbar und öffnen die Datei: chmod +x /usr/local/bin/dyn_announce_gw_bw.sh

vi /usr/local/bin/dyn_announce_gw_bw.sh

Und Füllen dieses mit Inhalt oder editieren den importierten Inhalt:

#!/bin/bash
gwsel_lockfile="/tmp/gwsel_lockfile"  # lockfile to allow for low bandwidth settings 

if [ -z "$1" ]; then
        echo
        echo "usage: $0 <network-interface> <update_interval [sec]> <total BW up [Mbit/sec]> <total BW down [Mbit/sec]>"
        echo
        echo "e.g. $0 eth0 60 10 10"
        echo
        exit
fi

while true
do
    if [ ! -e ${gwsel_lockfile} ]; then    # lockfile not present
        # Bandwidth currently used (time averaged)
        R1=$(cat "/sys/class/net/$1/statistics/rx_bytes")
        T1=$(cat "/sys/class/net/$1/statistics/tx_bytes")
        sleep "$2"
        R2=$(cat "/sys/class/net/$1/statistics/rx_bytes")
        T2=$(cat "/sys/class/net/$1/statistics/tx_bytes")
        TkbitPS=$(echo "scale=0; ($T2 - $T1) / 1024 * 8 / $2" | bc -l)
        RkbitPS=$(echo "scale=0; ($R2 - $R1) / 1024 * 8 / $2" | bc -l)
#        echo "BW used      -- up $1: $TkbitPS kBit/s; down $1: $RkbitPS kBit/s"

        # Remaining bandwidth available; cut-off negative values
        Tavail_kbitPS=$(echo "scale=0; if (($3 * 1024 - $TkbitPS) >0) ($3 * 1024 - $TkbitPS) else 0" | bc -l)
        Ravail_kbitPS=$(echo "scale=0; if (($4 * 1024 - $RkbitPS) >0) ($4 * 1024 - $RkbitPS) else 0" | bc -l)
#        echo "BW available -- up $1: $Tavail_kbitPS kBit/s; down $1: $Ravail_kbitPS kBit/s"
    else                                     # lockfile present
        Tavail_kbitPS=0
        Ravail_kbitPS=0
        sleep "$2"
    fi

    if [ `pidof dhcpd` != "" ]; then
        for bat in /sys/class/net/bat*; do
            iface=${bat##*/}
            batctl -m $iface gw_mode server "${Ravail_kbitPS}kbit/${Tavail_kbitPS}kbit"
        done
    else
        for bat in /sys/class/net/bat*; do
            iface=${bat##*/}
            batctl -m $iface gw_mode off
        done
        rm /var/run/dhcpd.pid >/dev/null 2>&1
        /etc/init.d/isc-dhcp-server restart
    fi
done

Achtung: Wenn man ein bat Interface hat, das nicht Gateway ist muss man dies aus der letzten Schleife ausschließen da sonst dort ebenfalls die Gatewayselection aktiviert wird und man eine Bandbreite announced.

Das Skript übernimmt als Parameter:

• Netzwerkinterface, das es zu überwachen gilt (i.d.R. eth0)
• Updateintervall in Sekunden, in denen ein neuer Wert durch die B.A.T.M.A.N GW Selection annonciert wird (Um nicht allzu volatil auf Kurzzeitschwankungen im Durchsatz zu reagieren empfiehlt sich ein Mittelungsintervall zwischen 30 und 120 Sekunden)
• Upload Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)
• Download Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)

Bei Existenz des oben definierten Lockfiles "/tmp/gwsel_lockfile", annonciert das Gateway nur noch eine minimale Bandbreite. Dies dient dazu, möglichst keine neuen Clients zu akquirieren, z.B. weil gerade der VPN Tunnel ausgefallen ist und nur noch eine Babel Defaultroute mit geringer Bandbreite verfügbar ist.

Ein Aufruf für eth0 als Interface, ein Update alle 5 Minuten, 12 Mbit/sec maximaler Upload und 10 Mbit/sec maximaler Download wäre z.B.: /usr/local/bin/dyn_announce_gw_bw.sh eth0 300 12 10

Bei Debian 9 muss das Interface angepasst werden. Als Beispiel: /usr/local/bin/dyn_announce_gw_bw.sh ens18 300 12 10

Um die Gateway Selection beim Systemsstart zu aktivieren, können wir das Skript z.B. in rc.local aufrufen: vi /etc/rc.local

um dort, leicht zeitverzögert, o.a. Befehl einzupflegen, wobei die Parametrisierung noch Gateway-spezifisch angepasst werden muss:

.
.
.
#enable batman GW selection with 15 seconds delay
(sleep 15; /usr/local/bin/dyn_announce_gw_bw.sh eth0 300 12 10) &
.
.
.

auf den Routern kann der vorselektierte Gateway mit

batctl gwl

angeguckt werden.

Gatewayselection abschalten wenn Lease voll

Wenn man mit den dhcp Leases am Limit ist, sollte das Script angepasst werden das es die Gatewayselection abschaltet wenn nur noch wenige Leases offen sind. Dazu muss vor den letzten "done" folgender Teil hinzugefügt werden, Beispiel für Hood Erlangen auf nue2-gw1. Das grep muss auf die entsprechende IP Range angepasst werden und der IF Vergleich auf die maximale Menge an Leases, man sollte dabei noch einen Puffer offen halten.

# Erlangen schalten wir die Gatewayselection zur Sicherheit bei 450 leases ab, damit noch etwas Puffer nach oben ist! 
leasecount=$(/usr/sbin/dhcp-lease-list --parsable --lease /var/lib/dhcp/dhcpd.leases 2>&1 | grep "10.50.6" | wc -l) 
if [ $leasecount -gt 450 ] 
then 
batctl -m bat1 gw_mode off 
fi

DHCP Server

https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/DHCP

GRE-Tunnel zu anderen Gateways

Um die einzelnen Hoods miteinander zu verbinden, werden die jeweiligen Gateways über GRE-Tunnel miteinander verbunden. Es reicht dabei nicht, den GRE Tunnel nur auf einem Gateway einzurichten, vielmehr müssen beide zu verbindende Gateways konfiguriert werden. Hierfür muss man mit dem Admin des jeweiligen Tunnelpartners in Kontakt treten => Server.

Der GRE-Tunnel wird in /etc/network/interfaces... vi /etc/network/interfaces

...mit folgenden noch auf das Gateway anzupassenden Einträgen deklariert:

auto <tunnel>
iface <tunnel> inet static
 address <Eigene IPv4 (Freifunk Netz)>
 pre-up ip -4 tunnel add $IFACE mode gre local <Eigene IPv4 (Internet)> remote <IPv4 des Tunnelpartners (Internet)> ttl 255
#pre-up ip -6 tunnel add $IFACE mode ip6gre local <Eigene IPv6 (Internet)> remote <IPv6 des Tunnelpartners (Internet)> ttl 255

 up ifconfig $IFACE multicast
 pointopoint <IPv4 des Tunnelpartners (Freifunk Netz)>
 post-up iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu
 post-up ip rule add iif $IFACE table fff
 post-up ip -6 rule add iif $IFACE table fff
 post-up ip rule add from 10.50.0.0/16 table fff
 post-up ip rule add to 10.50.0.0/16 table fff
 post-down ip rule del iif $IFACE table fff
 post-down ip -6 rule del iif $IFACE table fff
 post-down ip rule del from 10.50.0.0/16 table fff
 post-down ip rule del to 10.50.0.0/16 table fff
 post-down iptables -t mangle -D POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu
 post-down ip tunnel del $IFACE

Der Tunnelname, die Internetadresse beider Tunnelpartner und die Freifunkadresse beider Tunnelpartner müssen hierbei eingefügt werden. Für GRE-Tunnel wurde der Adressbereich 10.50.252.0/22 in Portal:Netz reserviert, in denen beiden Tunnelpartnern eine dezidierte IPv4 zugewiesen wird. Das Vorgehen wurde gewählt, um auch Hood-übergreifend Tunnel erstellen zu können. Hier verwendete IP-Adressen müssen in die Tabelle eingetragen werden und so als belegt gekennzeichnet werden.

Beispiel: Um als fff-nue1 einen Tunnel zu ro1 aufzubauen, können die IP-Adressen wie folgt gewählt werden:

<tunnel>                                  ro1
<Eigene IPv4 (Freifunk Netz)>             fff-nue1      10.50.252.1
<IPv4 des Tunnelpartners (Freifunk Netz)> ro1           10.50.252.0
<Eigene IPv4 (Internet)>                  fff-nue1      31.172.33.99
<IPv4 des Tunnelpartners (Internet)>      ro1           176.126.221.7

In der Partnerkonfiguration für ro1 werden die Rollen entsprechend vertauscht:

<tunnel>                                  fff-nue1
<Eigene IPv4 (Freifunk Netz)>             ro1           10.50.252.0
<IPv4 des Tunnelpartners (Freifunk Netz)> fff-nue1      10.50.252.1
<Eigene IPv4 (Internet)>                  ro1           176.126.221.7
<IPv4 des Tunnelpartners (Internet)>      fff-nue1      31.172.33.99         

Der Tunnel kann über den Aufruf von ifup <tunnel> ...aufgebaut werden, wobei <tunnel> der Name des GRE-Interfaces ist (im Beispiel ro1)

Nach Aufruf von ifconfig.. ifconfig sollten wir einen Eintrag für den Tunnel (in diesem Beispiel ro1) vorfinden:

.
.
.
ro1       Link encap:UNSPEC  HWaddr B0-7B-1C-73-30-30-3A-35-00-00-00-00-00-00-00-00  
          inet addr:10.50.252.1  P-t-P:10.50.252.0  Mask:255.255.255.255
          inet6 addr: fe80::200:5efe:b07b:1c73/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1476  Metric:1
          RX packets:160913 errors:0 dropped:0 overruns:0 frame:0
          TX packets:146654 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:66984353 (63.8 MiB)  TX bytes:10675001 (10.1 MiB)
.
.
.

Babel

Die Einrichtung von Babel wird unter https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/Babel erklärt.

Gatewayinfos an das Monitoring senden

Damit das Monitoring weiß, wie es dem Gateway geht bitte https://github.com/adrianschmutzler/fff-monitoring/blob/master/gwinfo/sendgwinfo.sh nach /usr/local/bin/sendgwinfo.sh herunterladen und chmod +x setzen.

Danach noch einen neuen crontab Eintrag mit

*/5 *   * * *   root    /usr/local/bin/sendgwinfo.sh

setzen

Einbringen des Gateways in die Hood / Keyserver

Abschliessend muss das Gateway im Keyserver als Gateway der entsprechenden Hood eingetragen werden. Hierfür benötigt man einen Keyserver-Administrator => Server.

Bevor man das Gateway der Hood zuordnet, empfiehlt sich ein persönliches Review durch einen erfahrenen Gateway-Admin. Das neue Gateway kann auch versuchsweise zunächst einer Test-Hood zugeordnet werden, um es erstmal auf korrekte Funktion zu überprüfen.

Der DHCP-Server sollte als letzter Schritt aktiviert werden (s.o.)

Problem nf_conntrack

Bei vielen Clients und vorallem NAT und anderen Iptables kann es passieren das die nf_conntrack auf den Server voll läuft. Wenn dies passiert fängt der Server an Pakete zu verwerfen und ist dann nur noch schwer erreichbar. Zu erkennen ist das auch wenn dmesg unmengen von

nf_conntrack: table full, dropping packet

um sich wirft.

Folgendes sollte man im Auge behalten:

Ermitteln des conntrack_max

cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max

Debian9:

cat /proc/sys/net/nf_conntrack_max

Ermitteln des aktuellen conntrack count

/sbin/sysctl net.netfilter.nf_conntrack_count

sollte die aktuell Größe nahe an die maximale Größe kommen, kann diese vergrößert werden:

sysctl -w net.netfilter.nf_conntrack_max=131072
echo 32768 > /sys/module/nf_conntrack/parameters/hashsize

zu beachten ist, das eine größere conntrack auch mehr Arbeitsspeicher fordert. Unter 4GB sollte sie nicht vergrößert werden. Der hashsize sollte 1/4 des conntrack_max Wertes betragen Der Wert kann auch permamenent angepasst werden:

vi /etc/sysctl.conf  // Am Ende einfügen
net.netfilter.nf_conntrack_count = 131072
vi /etc/rc.local
echo 32768 > /sys/module/nf_conntrack/parameters/hashsize

zusätzlich kann das unnötig lange Timeout verringert werden um den conntrack count schon von Grund auf kleiner zu halten:

vi /etc/sysctl.conf // Am Ende einfügen
net.ipv4.netfilter.ip_conntrack_generic_timeout = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 54000

bzw. die Werte sofort setzen:

sysctl -w net.ipv4.netfilter.ip_conntrack_generic_timeout=120
sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=54000

Quelle: [2]

ARP Cache erhöhen

ACHTUNG: Das ganze ist noch nicht intensiv getestet, bitte bei Änderungen beobachten! Default ist im Linux der Arp Cache relativ klein. Wenn man mehrmals hintereinander die Menge an ARP Einträgen im Cache abfragt (z.b. ip neigh show | wc -l) und man feststellt das der Cache regelmäßig aufgeräumt wird (Zahl springt alle paar Sekunden wieder auf einen deutlich kleineren Wert zurück) sollte man den Wert erhöhen um die Arp Requests im Netz zu verringern. Dies geht über sysctl Variablen:

sysctl -w net.ipv6.neigh.default.gc_thresh1=128
sysctl -w net.ipv6.neigh.default.gc_thresh2=512
sysctl -w net.ipv6.neigh.default.gc_thresh3=1024
sysctl -w net.ipv4.neigh.default.gc_thresh1=128
sysctl -w net.ipv4.neigh.default.gc_thresh2=512
sysctl -w net.ipv4.neigh.default.gc_thresh3=1024

die oben angegeben Werte sind die default Werte. Weitere Infos zu den Werten: https://wiki.manitu.de/index.php/Server:Fehlermeldung_%22kernel:_Neighbour_table_overflow%22

Ich hab z.b. auf nue2gw3 mit ~2400 Clients die Werte auf 2048 4096 8192 gesetzt.

Port Sperren

Es empfiehlt sich folgende Ports / IPs zu sperren

Ausgehend:

• tcp-25
• tcp-137
• udp-137
• ip-10.0.0.0/8
• ip-172.16.0.0/12
• ip-192.168.0.0/16
• ip-100.64.0.0/10
• ip-169.254.0.0/10
• ip-192.0.0.0/24
• ip-192.0.2.0/24
• ip-198.18.0.0/15
• ip-198.51.100.0/24
• ip-203.0.113.0/24
• ip-0.0.0.0/8

Gateways, welche beim Hoster Hetzner stehen, sollte weitere Vorkehrungen treffen. Hetzner monitored den Traffic, den die Gateways verursachen. Sollten Verbindungsversuche zu nicht gerouteten IPs dabei sein, generiert Hetzner Abuse und schickt es (Achtung!) nicht an die hinterlegte Abuse-Adresse. Was man dagegen tun kann ist hier beschrieben: Hetzner