Freifunk-Gateway aufsetzen

TODO

• fastdstart in ein git legen und verlinken
• olsrd.conf in ein git legen und verlinken
• squid.conf in ein git legen und verlinken

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 Mailingliste.

Vorraussetzungen

• ssh-Zugang zum Server
• Root Zugriff auf den Server. Entweder man ist "root" (Annahme in diesem Artikel) oder man kann Befehle mit "root-Rechten" durch ein vorgesetztes "sudo" ausführen sowie die Möglichkeit auf dem Server Kernelmodule zu laden (kann nicht jeder VServer!)
• Grundlegende Netzwerkkenntnisse
  • IPv4 und Netzmaske
  • Devices
  • Routing (Default Route, Interfaces, Routing-Table)
• Kentnisse
  • im Umgang mit Texteditoren (der im Artikel verwendete Editor kann durch beliebig andere ersetzt werden, z.B. durch "nano")
  • im Umgang mit der Linux Shell (z.B. Kommandozeilenparameter, Shell-Scripte, Umleitungen)
  • in der (selbständigen Nach-)Installation von (fehlenden) Software-Paketen
  • im Kompilieren von Software-Quellen

Referenzen / Andere Freifunk HowTo's

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

Anforderungen an Gateways

Die Anforderungen an das Gateway sind an sich niedrig. Wichtig ist, dass die Möglichkeit besteht, eigene Kernel-Module zu laden und das monatliche Traffic-Kontingent nicht zu niedrig ist. Entsprechend sind OpenVZ, Linux-vServer und ähnliche Containerlösungen nicht geeignet.

Hardware:

• CPU: 1x (64Bit)
• RAM: 256MB .. 1GB
• HDD: > 5 GB
• NIC: 1x

Software:

• Debian Jessie (8) 64Bit Kernel
• fastd v17
• openvpn
• B.A.T.M.A.N. adv 2013.4.0
• dhcpd
• olsr
• bind9

Pauschal gibt es keine Mindestanforderungen für den Trafficverbrauch, folgende Staffelung könnte aber dabei helfen, sich eine Vorstellung davon zu machen, was in etwa pro Monat notwendig ist:

• Dauerlast von 2 Mbit/s: ~633 GB
• Dauerlast von 6 Mbit/s: ~1.9 TB
• Dauerlast von 10 Mbit/s: ~3.2 TB
• Dauerlast von 25 Mbit/s: ~8 TB

Nach den Erfahrungen vom Lübecker Freifunk-Projekt liegt der Traffic-Verbrauch bei zwei Gateways bei ca. 2TB im Monat je Gateway. Auf unserem derzeitigen Gateway haben wir in den letzten Monaten derartige Werte gehabt, wobei sich das Projekt noch aufbaut:

• Januar '13: 243 GB
• Februar '13: 309 GB

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

Ungetestet:

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

Einige Freifunknetze mieten auch VMs in Osteuropa. Da die VMs noch nicht an ihre Grezen stößt könnte man diese auch mitnutzen. Ansprechpartner wäre s0ma.

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.

vServer-Anbieter die empfehlenswert sind

• de-punkt (Databurg, FFM)
  • Schneller Speicher, gut bezahlbar, KVM, nur Traffic-Flat™® das übliche.
• Hetzner (Falkenstein)
  • Bezahlbar, 6.90€/TB Extratraffic, 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]

Grundinstallation des Servers

Vom ausgesuchten Hoster lassen wir uns eine aktuelle Linux-Distribution installieren oder ausliefern, wobei sich die Anleitung auf ein Debian 8 / Jessie bezieht.

Repositories und Update

Als erstes werfen wir einen Blick in...

vi /etc/apt/sources.list

...und schauen, inwieweit auf die gleichen Software-Repositories verwiesen wird:

 
deb http://security.debian.org/ jessie/updates main
deb-src http://security.debian.org/ jessie/updates main

deb http://ftp.de.debian.org/debian/ jessie main contrib non-free
deb-src http://ftp.de.debian.org/debian/ jessie main contrib non-free

deb http://ftp.de.debian.org/debian/ jessie-updates main
deb-src http://ftp.de.debian.org/debian/ jessie-updates main

Danach bringen wir das System auf einen aktuellen Stand:

apt-get update

apt-get upgrade

Sicherheit

Den SSH-Zugang besser schützen durch:

• Änderung des Ports
• login nur mit key
• Siehe hier für genaue Anleitung:

apt-get install fail2ban

und einrichten

So,nun sollte der Server ausreichend abgesichert sein.

B.A.T.M.A.N. adv 2013.4.0 Kernel-Modul

Batman-Adv aus Jessie ist zu neu. Hier muss manuell das alte B.A.T.M.A.N. advanced 2013.4.0 gebaut werden.

Hierfür benötigen wir minimal die Paketquellen build-essential, linux-headers-amd64 und git:

apt-get install build-essential linux-headers-amd64 git

Die Softwarequellen müssen heruntergeladen... cd ~

git clone https://github.com/freifunk-gluon/batman-adv-legacy

cd batman-adv-legacy

... und kompiliert und installiert werden:

make

make install

Hinweis: Sollten noch Paketquellen fehlen, wird dies während des Kompilierens gemeldet. Die Software-Quellen müssen nachinstalliert werden und der letzte Kompilierungs- und Installationsschritt so lange wiederholt werden, bis die Software erfolgreich erstellt wurde.

Nach erfolgreicher Erstellung kann das B.A.T.M.A.N Kernel Modul per modprobe händisch eingebunden werden:

modprobe batman-adv

Es sollte dann im Kernel-log .... dmesg | grep batman-adv

... mit einem Eintrag gelistet werden:

   batman_adv: B.A.T.M.A.N. advanced 2013.4.0 (compatibility version 14) 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:

vi /etc/modules

..der Eintrag "batman-adv" hinzugefügt wird:

batman-adv

B.A.T.M.A.N adv 2013.4.0 batctl

Gleiches gilt für batctl, ein Kommandozeilenprogramm zur B.A.T.M.A.N Konfiguration. Die alte Version 2013.4.0 muss selber gebaut werden, da die Debian 8 / Jessie Paketquellen zu neu sind.

Herunterladen und Entpacken der Softwarequellen: cd ~

wget http://downloads.open-mesh.org/batman/releases/batman-adv-2013.4.0/batctl-2013.4.0.tar.gz

tar xzf batctl-2013.4.0.tar.gz

cd batctl-2013.4.0

Kompilieren und Installieren:

make

make install

Hinweis: Auch hier müssen ggf. fehlende Quellen händisch nachinstalliert und das Kompilieren und Installieren bis zum Erfolg wiederholt werden.

FastD

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

Hierfür müssen wir ein neues Repository in der Datei /etc/apt/sources.list deklarieren:

vi /etc/apt/sources.list

Dort fügen wir folgendes Repository an:

deb http://repo.universe-factory.net/debian/ sid main
deb-src http://repo.universe-factory.net/debian/ sid main

Danach die PGP Schlüssel holen: gpg --keyserver hkp://pool.sks-keyservers.net --recv-key 16EF3F64CB201D9C

gpg -a --export 16EF3F64CB201D9C | apt-key add -

Datenbankupdate der Paketverwaltung: apt-get update

Installation von fastd: apt-get install fastd

Bind9

Als DNS Server nehmen wir hier den de-facto-Standard bind: apt-get install bind9

OLSR

Als Routing-Protokoll, um die einzelnen Hoods später zu einem Freifunk-Franken weit kommunizierenden Netz zu verbinden, wird OLSR installiert: apt-get install olsrd

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

Für das Gateway suchen wir uns unter Portal:Netz eine IPv4 Adresse aus dem statischen Range der Hood aus. Für Fürth läuft der Bereich für die statischen Adressen z.B. von 10.50.32.1 - 10.50.32.255. Hiervon suchen wir uns eine freie Adresse aus, und reservieren diese, indem wir sie weiter unten in die Tabelle der statischen IPs eintragen. So sind z.Zt. 10.50.32.1 (ro1.freifunk-franken.de) bis 10.50.32.5 (klee) reserviert. Die nächste freie IPv4 in der Fürther Hood wäre (im Moment) 10.50.32.6, die als IP für ein neues Gateway reserviert werden könnte.

Die Fürther Hood hat den IP-Bereich 10.50.32.0-10.50.32.255. Als Netzwerk wird dieser Bereich mit 10.50.32.0/21 deklariert, d.h. die ersten 21 Bit der IP identifizieren das Netzwerk "Fürther Hood" und die restlichen 11 Bit stehen zur IP Vergabe zur Verfügung, wobei Anfang (10.50.32.0) und Ende des Bereiches (10.50.39.255) reserviert sind und nicht, weder statisch noch dynamisch durch DHCP, belegt werden dürfen. Eine alternative Schreibweise zu 10.50.32.0/21 ist das Double "Network 10.50.32.0" und "Netmask 255.255.248.0". Ein entsprechender IP-Rechner zur analogen Anwendung in anderen Hoods findet sich z.B. hier.

Ebenso sollte man einen DHCP-Bereich innerhalb des IP-Bereichs der jeweiligen Hood, die der GW bedienen soll, reservieren (d.h. in die oberer Tabelle unter Portal:Netz eintragen). Jeder DHCP-Server vergibt dynamisch IPv4 Adressen an Clients aus einem vorher definierten Adressbereich. Dieser Adressbereich sollte sich:

• innerhalb des IP-Range der Hood bewegen
• sich nicht mit dem Adressbereich überschneiden, den andere DHCP Server in der Hood verwalten
• sich nicht mit dem Bereich der statischen Adressen der Hood überschneiden

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. Vom gesamten IP-Bereich der Fürther Hood vergibt z.B. das Gateway fff-nue1 die Teilmenge 10.50.35.0 - 10.50.36.255 an Clients und teilt ihnen auf dem Weg auch gleich mit, wie sie Domain-Namen in IPs auflösen und auf welchem Weg sie ins Internet oder in andere Hoods kommen.

Routing Tabelle für Freifunk

Fürs Routing im Freifunk Franken Netz wird eine eigene Routing Tabelle namens "fff" deklariert.

Dies geschieht indem man in der Datei /etc/iproute2/rt_tables ... vi /etc/iproute2/rt_tables

... folgendes am Ende einfügt:

10     fff

Unsere Freifunk Routing Tabelle lässt sich später durch ip route show table fff anzeigen, sobald wir die Tabelle mit Einträgen füllen.

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

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 ifconfig $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 add 10.50.32.0/21 dev $IFACE 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.8/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

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 oben 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 werden. 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.

Der untere Abschnitt definiert einen VPN Tunnel in die Fürther Hood. Der Name des Interfaces im Beispiel (ffffuerthVPN) kann individuell neu vergeben werden.

FastD Start- und Verwaltungsscript

Für die Konfiguration von fastd erstellen wir eine Datei in /etc/fastd mit dem Befehl:

touch /etc/fastd/fff_beispiel_fastd.sh

danach öffnen wir diese:

vi /etc/fastd/fff_beispiel_fastd.sh

und fügen folgendes Skript ein:

#!/bin/sh

SERVER="yes"
SERVERNAME="beispiel"

hood="hood eintragen"
project="fff"
port=10004

SERVERNAME="$SERVERNAME.$hood"

hostname=$SERVERNAME

if [ ! -d /etc/fastd ]
then
        mkdir /etc/fastd
fi

if [ ! -d /etc/fastd/$project.$hood ]
then
        mkdir /etc/fastd/$project.$hood
        mkdir /etc/fastd/$project.$hood/peers

        echo "# Log warnings and errors to stderr" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "log level error;" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "# Log everything to a log file" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "log to syslog as \"${project}${hood}\" level info;" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "# Set the interface name" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "interface \"${project}${hood}VPN\";" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "# Support xsalsa20 and aes128 encryption methods, prefer xsalsa20" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "#method \"xsalsa20-poly1305\";" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "#method \"aes128-gcm\";" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "method \"null\";" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "# Bind to a fixed port, IPv4 only" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "bind any:${port};" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "# Secret key generated by \"fastd --generate-key\"" >> /etc/fastd/$project.$hood/$project.$hood.conf
              echo "secret \"$(fastd --generate-key | grep -i Secret | awk '{print $2}')\";" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "# Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE)" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "# (see MTU selection documentation)" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "mtu 1426;" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "on up \"/etc/fastd/${project}.${hood}/up.sh\";" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "on post-down \"/etc/fastd/${project}.${hood}/down.sh\";" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "# Include peers from the directory 'peers'" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "include peers from \"/etc/fastd/${project}.${hood}/peers\";" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "secure handshakes no;" >> /etc/fastd/$project.$hood/$project.$hood.conf

        echo "#!/bin/sh" >> /etc/fastd/$project.$hood/down.sh
        echo "/sbin/ifdown \$INTERFACE" >> /etc/fastd/$project.$hood/down.sh
        chmod +x /etc/fastd/$project.$hood/down.sh

        echo "#!/bin/sh" >> /etc/fastd/$project.$hood/up.sh
        echo "/sbin/ifup \$INTERFACE" >> /etc/fastd/$project.$hood/up.sh
        chmod +x /etc/fastd/$project.$hood/up.sh
fi

pubkey=$(fastd -c /etc/fastd/$project.$hood/$project.$hood.conf --show-key --machine-readable)
port=$(grep ^bind /etc/fastd/$project.$hood/$project.$hood.conf | cut -d: -f2 | cut -d\; -f1)

# fire up
if [ "$(/sbin/ifconfig -a | grep -i ethernet | grep ${project}${hood}VPN)" = "" ]
then
/bin/rm /var/run/fastd.$project.$hood.pid
fastd -c /etc/fastd/$project.$hood/$project.$hood.conf -d --pid-file /var/run/fastd.$project.$hood.pid
fi

# register
wget -T15 "http://mastersword.de/~reddog/fff/?name=$hostname&port=$port&key=$pubkey" -O /tmp/fastd_${project}.${hood}_output
if [ "$?" != "0" ]
then
        echo "Update failed"
        echo "Exiting, no clean up, no refresh"
        exit
fi

touch /tmp/fastd_${project}.${hood}_starting

filenames=$(cat /tmp/fastd_${project}.${hood}_output| grep ^#### | sed -e 's/^####//' | sed -e 's/.conf//g')
for file in $filenames
do
grep -A100 ^####$file.conf$ /tmp/fastd_${project}.${hood}_output | grep -v ^####$file.conf$ | grep -m1 ^### -B100 | grep -v ^### | sed 's/ float;/;/g' > /etc/fastd/$project.$hood/peers/$file
echo 'float yes;' >> /etc/fastd/$project.$hood/peers/$file
done

echo "Lösche alte:"

find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print
find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print | xargs /bin/rm /tmp/fastd_${project}.${hood}_starting

#reload
kill -HUP $(cat /var/run/fastd.$project.$hood.pid)

exit 0

Zum Schluss geben wir noch ein

chmod +x /etc/fastd/fff_beispiel_fastd.sh

ein.

Das Skript konfiguriert fastd, indem es

• einen Schlüssel generiert, sollte keiner existieren
• diesen Schlüssel mit dem Keyserver austauscht
• die fastd Konfigurationsdatei anlegt
• den fastd Dämonen startet

Lediglich der Servername und die Hood müssen oben im Skript händisch angepasst werden. Der Dateiname des Skripts kann individuell angepasst werden.

Hinweis: Das Gateway wird standardmässig in die Default-Hood eingebunden. Es wird hier lediglich ein Name für die Konfigurationsdatei und der Gateway Name definiert. Die Zuordnung des Gateways zu der Hood erfolgt später über den KeyXchange (siehe unten).

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.

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

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

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_fuerth_fastd.sh) &

Alternativ oder zusätzlich kann auch ein Cronjob angelegt werden, der das Skript z.B. alle 10 Minuten ausführt: crontab -e

Nun folgendes eingeben:

*/10 * * * * sh /etc/fastd/fff_fuerth_fastd.sh

und

/etc/init.d/cron restart

OpenVPN-Tunnel einrichten

Die Einrichtung eines OpenVPN Tunnels kann von Anbieter zu Anbieter variieren. Im Laufe der Zeit sollte die Dokumentation so um funktionierende Konfigurationen verschiedener Anbieter erweitert werden.

Mullvad

Mullvad liefert in der Datei mullvadconfig.zip, die notwendigen Schlüssel (ca.crt, mullvad.crt, mullvad.key) als auch eine Konfigurationsdatei (mullvad_linux.conf) mit, die später angepasst werden muss.

Man kopiert nun die zip-Datei auf das Gateway, entpackt sié und kopiert das Kundenummern-Verzeichnis mit dem Dateien ca.crt, crl.pem, mullvad.crt, mullvad.key, mullvad_linux.conf nach /etc/openvpn:

Von dem lokalen Rechner kopieren wir die zip Datei per scp für Windows oder Linux auf das Gateway.

Als unverbindliche Richtschnur für Linux: scp mullvadconfig.zip root@<ipv4 des Gateways>:/root

Danach loggen wir uns auf dem Gateway ein und entpacken die Datei: ssh root@<ipv4 des Gateways>

unzip mullvadconfig.zip

cd <Kundennummernverzeichnis>

cp * /etc/openvpn

/etc/openvpn/ sollte mit dem Inhalt des entpackten mullvadconfig.zip Archivs dann so aussehen:

ca.crt	crl.pem  mullvad.crt  mullvad.key  mullvad_linux.conf  mullvad_up  mullvad_windows.conf.ovpn  

Wichtiger Hinweis: Wer sich nicht von seinem Gateway aussperren möchte, sollte so lange den Rechner nicht neu starten, wie die openvpn Konfiguration nicht wie unten angepasst wurde. Wenn es doch passiert, ist evtl. noch ein Zugriff auf das Gateway über die hoster-Konsole möglich.

Wir legen ein benutzerspezifisches start-up Script namens mullvad-up an: touch /etc/openvpn/mullvad-up

öffnen die Datei: vi /etc/openvpn/mullvad-up

und füllen sie mit folgendem Inhalt:

#!/bin/bash
logger -t OPENVPN VPN Gateway: /sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff
/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE

Das Skript definiert in der fff-Routingtabelle zunächst den VPN Anbieter als Standard-Gateway ("/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff"). D.h. Traffic, der über das Freifunk-Netz hereinkommt (Definiert über die fff IP rules) und für den keine anderweitigen Routinginformationen bekannt sind (z.B. Internet Traffic), wird pauschal in Richtung des VPN Gateways geschickt (IP ${route_vpn_gateway}, Device ${dev}). Das Default-Gateway für Traffic, der nicht freifunkbezogen ist, bleibt unangetastet, um sich nicht selber auszusperren. Da wir Anfragen vieler Clients (verschiedene IPs) über eine VPN IP schieben, müssen wir darüber hinaus "Network Adress Translation" (NAT) betreiben ("iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE"). Dies ist auch erforderlich, da der Freifunk IPv4 Adressbereich 10.0.0.0/8 für lokale Netze reserviert ist und nicht im Internet geroutet wird.

Das Skript mullvad-up muss ferner ausführbar sein: chmod +x /etc/openvpn/mullvad-up

Dieses spezifische Routing muss zwingend in mullvad_linux.conf eingepflegt werden: vi /etc/openvpn/mullvad_linux.conf

und hier die Konfiguration entsprechend geändert werden:

.
.
.
# Allow calling of built-in executables and user-defined scripts.
script-security 2

# Parses DHCP options from openvpn to update resolv.conf
#up /etc/openvpn/update-resolv-conf
#down /etc/openvpn/update-resolv-conf

# Enable Freifunk specific Routing
route-noexec
route-delay 3
route-up    /etc/openvpn/mullvad_up
.
.
.

Script security muss auf "2" stehen, damit benutzerspezifische Skripte ausgeführt werden dürfen. Unser Freifunk spezifisches Routing wird über "route-up /etc/openvpn/mullvad_up" ausgeführt, wobei wir vorher openvpn mit "route-noexec" verbieten, automatisch selber Routen anzulegen. Aus Sicherheitsgründen führen wir einen kleinen Zeitpuffer von 3 Sekunden ein ("route-delay 3"). Vorhandene Start/Stop-Skripte (up/down) sollten auskommentiert werden.

Wer möchte, kann in mullvad_linux.conf auch Länder definieren, über die der VPN Traffic laufen soll (Ein- /Auskommentieren).

Der openvpn Tunnel kann nun testweise gestartet werden: cd /etc/openvpn

/usr/sbin/openvpn mullvad_linux.conf &

und sollte exemplarisch und im Auszug folgendes zurück liefern:

Sun Sep  6 12:45:20 2015 OpenVPN 2.3.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec  1 2014
Sun Sep  6 12:45:20 2015 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08
Sun Sep  6 12:45:20 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
.
.
.
Sun Sep  6 12:45:23 2015 /sbin/ip link set dev tun0 up mtu 1500
Sun Sep  6 12:45:23 2015 /sbin/ip addr add dev tun0 10.114.0.45/16 broadcast 10.114.255.255
Sun Sep  6 12:45:23 2015 /sbin/ip -6 addr add fdef:e287:a479:72::102b/112 dev tun0
Sun Sep  6 12:45:23 2015 /etc/openvpn/mullvad_up tun0 1500 1558 10.114.0.45 255.255.0.0 init
Sun Sep  6 12:45:23 2015 Initialization Sequence Completed

Wichtig ist hierbei, dass in der vorletztes Zeile unser Freifunk-spezifisches Routing durchgeführt wird.

Das VPN-Gateway sollte nun als Default Route in der fff-Routingtabelle auftauchen: ip route show table fff | grep default

Exemplarisch wäre eine Ausgabe für das Tunnel-Device tun0 und dem VPN-Gateway 10.114.0.1:

default via 10.114.0.1 dev tun0

Auch ein ifconfig Eintrag für das Tunnel Device... ifconfig

...sollte jetzt existieren (Exemplarisch und im Auszug):

.
.
.
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.114.0.76  P-t-P:10.114.0.76  Mask:255.255.0.0
          inet6 addr: fdad:bdef:735d:72::104a/112 Scope:Global
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:1012476 errors:0 dropped:0 overruns:0 frame:0
          TX packets:640206 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:1250196616 (1.1 GiB)  TX bytes:84979294 (81.0 MiB)
.
.
.

Wenn alles geklappt hat, kann man (sofern openvpn nicht korrekt beim Systemstart geladen wird), den openvpn Tunnel in der /etc/rc.local bei jedem Systemstart laden: vi /etc/rc.local

und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:

# launch vpn with 5 seconds delay
(sleep 5; cd /etc/openvpn ; /usr/sbin/openvpn mullvad_linux.conf >> /var/log/mullvad_vpn.log &) &

DNS Server

In der einfachsten Konfiguration betreiben wir den DNS Server als Caching Nameserver, d.h. alle Anfragen Domainnames in IP Adressen zu wandeln, die schon mal durch den Server gelaufen sind, werden selber beantwortet. Ansonsten wird ein anderer DNS-Server aus dem Freifunk-Netz oder dem Internet angefragt.

Hierfür editieren wir die Datei named.conf.options... vi /etc/bind/named.conf.options

...und tragen die DNS Server, die wir anfragen wollen, wenn wir die Information nicht selber haben, als forwarders ein:

.
.
.
forwarders  {
              10.50.32.1;
              10.50.32.2;
              8.8.8.8;
            };
allow-query { 
              127.0.0.1/8; 
              10.0.0.0/8; 
            };
.
.
.	

In diesem Fall werden die Freifunk Gateways ro1 (10.50.32.1) und fff-nue1 (10.50.32.2) der Fürther Hood als auch Google DNS (8.8.8.8) als Forwarders definiert. Für andere Hoods muss die lokale Adresse der Freifunk DNS Server unter Portal:Netz ermittelt werden (z.B. 10.50.48.1 für ro1 in der Ansbacher Hood). Darüber hinaus ist es sinnvoll, nur Anfragen zu beantworten, die das Gateway selber stellt (localhost; 127.0.0.1/8) oder die aus dem Freifunk Netz kommen (10.0.0.0/8). Der zugehörige Parameter heißt "allow-query".

Neustart des DNS-Servers mit der neuen Konfiguration: /etc/init.d/bind9 restart

Testen können wir, indem wir auf dem Gateway das Gateway selber als DNS-Server eintragen. Das Gateway beantwortet seine DNS-Anfragen quasi selbst. Hierfür kommentieren wir bestehende Nameserver in resolv.conf aus ... vi /etc/resolv.conf

...und tragen stattdessen localhost ein:

localhost	
#nameserver 8.8.8.8

Ein DNS Resolve für freifunk-franken.de ... dig freifunk-franken.de

...sollte von uns selber (Server localhost; 127.0.0.1) beantwortet werden:

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5819
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:
;freifunk-franken.de. IN A
;; ANSWER SECTION:
freifunk-franken.de. 3599 IN A 31.172.113.113	
.
. 
.
;; Query time: 117 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Sep 08 14:16:32 EEST 2015
;; MSG SIZE  rcvd: 275

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

In der nächsten Version der Router Firmware wird voraussichtlich B.A.T.M.A.N Gateway Selection aktiviert. 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

B.A.T.M.A.N Gateway Selection wird über batctl gw_mode server auf dem Gateway aktiviert.

Die maximal nutzbare Bandbreite (download / upload) kann über batctl gw_mode server 5mbit/10mbit eingestellt werden, wobei die Up- und Downloadrate entsprechend den obigen Überlegungen angepasst werden kann.

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

um dort, leicht zeitverzögert, o.a. Befehle einzupflegen:

#enable batman GW selection with 15 seconds delay
(sleep 15; batctl gw_mode server; batctl gw_mode server 5mbit/10mbit) &

DHCP Server

Die DHCP Konfiguration kann schon mal vorbereitet werden, sollte aber erst mit als letzter Schritt scharf geschaltet werden. Ein DHCP-Server, der Clients nicht funktionierende DNS-Server oder ein nicht funktionierendes Gateway mitteilt, sperrt diese aus dem Freifunk Netz aus.

In isc-dhcp-server definieren wir ... vi /etc/default/isc-dhcp-server

... das der DHCP Server für das B.A.T.M.A.N Device Anfragen beantworten soll:

INTERFACES="bat0"

Nachfolge Konfiguration wird in auskommentierter Form vorbereitet und sollte erst im letzten Schritt durch Einkommentieren und durch einen Neustart des DHCP Servers... /etc/init.d/isc-dhcp-server restart ...aktiviert werden.

Die Konfiguration wird in dhcpd.conf vorgenommen: vi /etc/dhcp/dhcpd.conf

und folgender Konfigurationsblock zunächst auskommentiert eingefügt, wobei Gateway und Hood spezifische Änderungen noch eingepflegt werden müssen:

.
.
.
### Freifunk Franken
#option domain-name "freifunk-franken.de";
#option domain-name-servers 10.50.16.1;
#authoritative;
### Fuerth
#subnet 10.50.32.0 netmask 255.255.248.0 {                  # Netzwerk und Netzmaske der Fuerther Hood
#        range 10.50.38.0 10.50.39.254;                     # IP-Range die der DHCP-Server innerhalb der Fuerther Hood verwaltet 
#        option routers 10.50.32.5;                         # Default-Gateway, dass Clients mitgeteilt wird 
#        option domain-name-servers 10.50.32.5, 10.50.32.1; # Name-Server, die Clients mitgeteilt werden
#}

Netzwerk und Netzmaske müssen derjenigen der Hood des Gateways entsprechen. Im Beispiel ist dies Fürth, für z.B. Hassberge hieße der Eintrag "subnet 10.50.56.0 netmask 255.255.252.0".

Der IP-Bereich (Range), die der DHCP-Server in der Hood verwaltet, wurde zuvor unter Portal:Netz reserviert.

Unter Routers wird den Clients das Default-Gateway mitgeteilt: Das Gateway, über das Clients das Internet oder eine andere Hood erreichen. In unserem Beispiel routet das aufgesetzte Gateway selber via VPN ins Internet oder via olsr (später) in andere Hoods. Als Default-Gateway wird also die eigene statische IP des Gateways, aus der eigenen Hood, die in Portal:Netz reserviert wurde, verwendet.

Ähnlich verhält es sich mit den Nameservern: Auf unserem Gateway wurde ein DNS Server eingerichtet, also kann der domain-name-server unser eigenes Gateway, mit der reservierten statische IP aus der Hood, wie in Portal:Netz, sein. Als Backup empfiehlt sich ein weiterer DNS-Server aus der Hood, in unserem Beispiel ro1 in der Fürther.

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 iptunnel add $IFACE mode gre local <Eigene IPv4 (Internet)> remote <IPv4 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 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 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 iptunnel del $IFACE

Der Tunnelname, die Internetadresse beider Tunnelpartner und die Freifunkadresse beider Tunnelpartner müssen hierbei eingefügt 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.32.2
<IPv4 des Tunnelpartners (Freifunk Netz)> ro1           10.50.32.1
<Eigene IPv4 (Internet)>                  fff-nue1      31.172.113.124
<IPv4 des Tunnelpartners (Internet)>      ro1           176.126.237.51

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

Nach einem Restart des Routers reboot & exit kann man nachschauen, ob der Tunnel aufgebaut wurde.

Hierfür rufen wir... ifconfig

auf, und sollten 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.32.2  P-t-P:10.50.32.1  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)
.
.
.

OLSR

Mittels OLSR können die Gateways selbstständig Routinginformationen austauschen. Ähnlich wie B.A.T.M.A.N einzelne Router innerhalb einer Hood vermesht, handelt es sich bei olsr um ein mesh zwischen den Gateways. Es ermöglicht ein Freifunk Franken internes Routing: z.B. kann eine beliebige IPv4 aus der Nürnberger Hood von aus der Fürth Hood aus erreicht werden.

OLSR wird in der Datei... vi /etc/olsrd/olsrd.conf

... konfiguriert. Hier werden Routen untereinander ausgetauscht. Da unser Beispiel-Gateway ins Netz der Fürther Hood eingebunden ist, teilen wir dies andern Gateways über den Eintrag 10.50.32.0/21 mit:

.
.
.
# HNA IPv4 routes
# syntax: netaddr netmask
# Example Internet gateway:
# 0.0.0.0 0.0.0.0

Hna4
{
#   Internet gateway:
#   0.0.0.0      0.0.0.0
#   more entries can be added:
#   192.168.1.0  255.255.255.0
10.50.32.0/21
}
.
.
.

Hier wird das olsr Webinterface auf port 8080 konfiguriert:

.
.
.
LoadPlugin "olsrd_httpinfo.so.0.1"
{
  # defaults to 1978
  PlParam "Port" "8080"
  # if you dont set these, the default is to listen only on the loopback device
  #PlParam "Host"   "80.23.53.22"
  #PlParam "Net"    "10.0.0.0 255.0.0.0"
  PlParam "Net" "0.0.0.0 0.0.0.0"
  #PlParam "Host"  "127.0.0.1"
}
.
.
.

Ferner wird der VPN-Tunnel (hier tun0) per persönlich angepasstem ping Kommando auf sein Funktion hin überwacht. Sollte der VPN-Tunnel ausfallen, ermöglicht olsr ein automatisches Re-Routing:

.
.
.
LoadPlugin "olsrd_dyn_gw.so.0.5"
{
  # Here parameters are set to be sent to the
  # plugin. Theese are on the form "key" "value".
  # Parameters ofcause, differs from plugin to plugin.
  # Consult the documentation of your plugin for details.

  # Example: dyn_gw params

  # how often to check for Internet connectivity
  # defaults to 5 secs
  PlParam     "Interval"   "5"

  # if one or more IPv4 addresses are given, do a ping on these in
  # descending order to validate that there is not only an entry in
  # routing table, but also a real internet connection. If any of
  # these addresses could be pinged successfully, the test was
  # succesful, i.e. if the ping on the 1st address was successful,the
  # 2nd won't be pinged
  PlParam     "Ping"       "8.8.8.8"
  PlParam     "Ping"       "82.165.230.17"
  PlParam     "pingcmd"    "ping -c 1 -q -I tun0 %s"
}
.
.
.

Folgender Konfigurationsblock muss ans Ende der Konfigurationsdatei angefügt werden. Es ermöglich olsr die Manipulation der fff-Routingtabelle:

.
.
.
# Specify the proto tag to be used for routes olsr inserts into kernel
# currently only implemented for linux
# valid values under linux are 1 .. 254
# 1 gets remapped by olsrd to 0 UNSPECIFIED (1 is reserved for ICMP redirects)
# 2 KERNEL routes (not very wise to use)
# 3 BOOT (should in fact not be used by routing daemons)
# 4 STATIC
# 8 .. 15 various routing daemons (gated, zebra, bird, & co)
# (defaults to 0 which gets replaced by an OS-specific default value
# under linux 3 (BOOT) (for backward compatibility)
#
RtProto 8
#
# Specifies the routing Table olsr uses
# RtTable is for host routes, RtTableDefault for the route to the default
# internet gateway (2 in case of IPv6+NIIT) and RtTableTunnel is for
# routes to the ipip tunnels, valid values are 1 to 254
# There is a special parameter "auto" (choose default below)
# (with smartgw: default is 254/223/224)
# (without smartgw: default is 254/254/254, linux main table)
#
RtTable 10
RtTableDefault 10
RtTableTunnel 10
#
# Specifies the policy rule priorities for the three routing tables and
# a special rule for smartgateway routing (see README-Olsr-Extensions)
# Priorities can only be set if three different routing tables are set.
# if set the values must obey to condition
# RtTablePriority < RtTableDefaultOlsrPriority
# < RtTableTunnelPriority < RtTableDefaultPriority.
# There are two special parameters, "auto" (choose fitting to SmartGW
# mode) and "none" (do not set policy rule)
# (with smartgw: default is none/32776/32776/32796)
# (without smartgw: default is none/none/none/none)
#
# RtTablePriority auto
# RtTableDefaultOlsrPriority auto
# RtTableTunnelPriority auto
# RtTableDefaultPriority auto

Das Freifunk Franken intere Routing kann nun getestet werden.

Zunächst einmal starten wir olsr neu: /etc/init.d/olsrd restart

Die Routinginformationen des olsr-meshes sollten in der fff-Routingtabelle auftauchen: ip route show table fff

Exemplarischer Auszug:

.
.
.
10.50.32.1 via 10.50.32.1 dev ro1  proto gated  metric 2 onlink 
10.50.32.2 via 10.50.32.2 dev nue1  proto gated  metric 2 onlink 
10.50.40.0/21 via 10.50.32.1 dev ro1  proto gated  metric 2 onlink 
.
.
.

Eine IP4 aus der Nürnberger Hood (10.50.40.0/21) sollte z.B. von Fürth aus (10.50.32.0/21) erreichbar sein:

ping 10.50.40.1

Antwort:

PING 10.50.40.1 (10.50.40.1) 56(84) bytes of data.
64 bytes from 10.50.40.1: icmp_seq=1 ttl=64 time=12.7 ms
64 bytes from 10.50.40.1: icmp_seq=2 ttl=64 time=12.4 ms
^C
--- 10.50.40.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 12.414/12.572/12.731/0.194 ms

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

Transparent Proxy

Auf dem Gateway kann (aber muss nicht) ein Proxy-Server installiert werden, der Dateien (z.B. Bilder), die schon mal angefragt wurden, nicht aus dem Internet holt, sondern als "lokal" gespeicherte Datei direkt vom Gateway bereitstellt. Die Clients werden dabei über den Proxy gezwungen, d.h. das Gateway leitet die Anfragen pauschal an den Proxy weiter, welcher entscheidet ob der die Anfrage selber bedient oder Gateway-extern anfragt.

Die Einrichtung eines Proxys ist optional, d.h. der Proxy ist für die Funktion des Gateways nicht notwendig. Proxy-Server reduzieren Antwortzeiten und Traffic für sich häufig wiederholende Anfragen (z.B. Spiegel Online, Windows Update).

Installation

Installiert wird der de-facto-Standard squid: apt-get install squid3

Für die kommende Konfiguration stoppen wir squid wieder: /etc/init.d/squid3 stop

und erstellen schon mal benötigte Verzeichnisse und vergeben die Rechte dazu: mkdir /usr/local/squid/

mkdir /usr/local/squid/var/

mkdir /usr/local/squid/var/cache/

mkdir /var/log/squid3/

chown proxy /usr/local/squid/var/cache/

chown proxy /var/log/squid3/

Konfiguration

Die mit installiere Konfigurationsdatei squid.conf ist sehr umfangreich und bietet eine gute Dokumentationsbasis, ist damit aber auch etwas unhandlich.

Aus diesem Grund empfiehlt es sich, die Datei umzubenennen: mv /etc/squid3/squid.conf /etc/squid3/squid.conf.orig

Danach erstellen und öffnen wir eine neue Konfigurationsdatei... touch /etc/squid3/squid.conf

vi /etc/squid3/squid.conf

...und füllen diese mit Inhalt, der allerdings noch auf das Gateway angepasst werden muss:

 
# cache size in MB / no. of subdirectories / no. of subsubdirectories
cache_dir ufs /usr/local/squid/var/cache/ 100 16 256

#maximum object size in cache (default: 4 MB)
#maximum_object_size 128 MB
maximum_object_size 4 MB

# Memory used for caching
cache_mem 32 MB

# No access log
#access_log /var/log/squid3/access.log combined
access_log none

# Hostname shown in messages
visible_hostname fff

# Bind Squid to port ... and configure as transparent proxy 
http_port 3128 intercept
# In addition a forward proxy is required
http_port 3129

refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern .               0       20%     4320

# Allow connects from Freifunk Franken network
acl fff src 10.50.0.0/16 

# DNS by Freifunk-IP of localhost and Google DNS
dns_nameservers 10.50.32.5 8.8.8.8

# Privacy options                  
via off
forwarded_for off
header_access From deny all
header_access Server deny all
header_access WWW-Authenticate deny all
header_access Link deny all
header_access Cache-Control deny all
header_access Proxy-Connection deny all
header_access X-Cache deny all
header_access X-Cache-Lookup deny all
header_access Via deny all
header_access Forwarded-For deny all
header_access X-Forwarded-For deny all
header_access Pragma deny all
header_access Keep-Alive deny all


# Bind outgoing address to Freifunk-Server IP to allow for VPN Routing 
tcp_outgoing_address 10.50.32.5
udp_outgoing_address 10.50.32.5

acl SSL_ports port 443          # https
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http

acl CONNECT method CONNECT
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow fff
http_access allow localhost
http_access deny all

Hier müssen angepasst werden:

• cache_dir: Die Gesamtgröße des Caches (hier: 100 MByte) muss so bemessen sein, dass auf der Partition auch bei Maximalgröße des Caches noch Speicher frei bleibt. Squid Standardeinstellung ist 100 MB bei 16 Verzeichnissen und jeweils 256 Unterverzeichnissen. Freier Speicherplatz kann mit "df -h" ermittelt werden.
• dns_nameservers: Hier sollten die Freifunk-IPv4 des Gateways (in diesem Beispiel 10.50.32.5) und eine externe IP (hier Google DNS 8.8.8.8) eingetragen werden. Wichtig ist, nicht localhost einzutragen, da die Anfrage im Zusammenspiel mit der "outgoing address" (s.u.) über die fff-Routingtabelle laufen muss.
• tcp_outgoing_address und udp_outgoing_address: Diese beide Einträge sind elementar wichtig. Zwar funktioniert der Proxy auch ohne, routet aber nicht über das VPN sondern direkt vom Gateway ins Internet. Damit die fff-Routingtabelle verwendet wird, für die als Default-Gateway eine VPN Verbindung eingerichtet ist, tragen wir hier die Freifunk-IP des Gateways ein (10.50.<irgendwas>). In diesem Beispiel ist die Freifunk-IPv4 des Gateways die 10.50.32.5.
• access_log: Das Access log sollte deaktiviert bleiben (access_log none), da es ein lebendiges Beispiel für Vorratsdatenspeicherung ist und die log-Dateien auch sehr schnell, sehr groß werden.

Danach erstellen wir die Verzeichnisstruktur des Proxy: squid3 -z

Jetzt sind wir fast fertig. Wir starten den Proxy: /etc/init.d/squid3 start

Anfragen, die auf Port 80 (http) reinkommen, müssen nun noch auf Port 3128 umgeleitet werden. Auf Port 3128 lauscht unser Proxy, http-Anfragen werden quasi transparent (oder zwangsweise) über den Proxy geleitet : iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128

Damit unsere Portumleitung mit jedem Start von Squid eingerichtet und mit jedem Stopp aufgehoben wird, pflegen wir sie (nicht ganz sauber) im squid start/stop Skript mit ein: vi /etc/init.d/squid3

und fügen zwei iptables Einträge nach dem Start und vor dem Stopp von Squid ein:

.
.
.
start () {
	cache_dir=`find_cache_dir cache_dir`
	cache_type=`grepconf cache_dir`

	#
	# Create run dir (needed for several workers on SMP)
	#
	create_run_dir

	#
	# Create spool dirs if they don't exist.
	#
	if test -d "$cache_dir" -a ! -d "$cache_dir/00"
	then
		log_warning_msg "Creating $DESC cache structure"
		$DAEMON -z -f $CONFIG
	fi

	umask 027
	ulimit -n 65535
	cd $cache_dir
	start-stop-daemon --quiet --start \
		--pidfile $PIDFILE \
		--exec $DAEMON -- $SQUID_ARGS < /dev/null
        # Use as transparent proxy
        iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128
	return $?
}

stop () {
	PID=`cat $PIDFILE 2>/dev/null`
        # Use as transparent proxy
        iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128
	start-stop-daemon --stop --quiet --pidfile $PIDFILE --exec $DAEMON  
	#
	#	Now we have to wait until squid has _really_ stopped.
	#
.
.
.