Freifunk MWU Gateway Doku
Release 0.1 beta
Freifunk-MWU
14.04.2016
Inhaltsverzeichnis
1
Beschreibung
1
2
Intro
2.1 Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Netzplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Gluon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3
6
10
3
Konfiguration
3.1 Grundkonfiguration
3.2 Netzwerk Interfaces
3.3 Policy Routing . . .
3.4 DNS-DHCP-IP . . .
3.5 fastd . . . . . . . .
3.6 A.L.F.R.E.D. . . . .
3.7 Apache . . . . . . .
3.8 IC-VPN . . . . . . .
3.9 Internet-Exit . . . .
3.10 Aufräumarbeiten . .
.
.
.
.
.
.
.
.
.
.
11
11
14
15
17
20
22
24
26
29
43
4
Betrieb
4.1 Funktionstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Backend Scripte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
47
51
53
5
Mitwirken
57
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
i
ii
KAPITEL 1
Beschreibung
In dieser Anleitung wird beschrieben, wie wir unsere Gateway-Server für Freifunk aufsetzen. Freifunk Mainz, Wiesbaden & Umgebung versorgt mit dieser Gateway Infrastruktur mehrere Communities, aktuell Freifunk-Mainz und
Freifunk-Wiesbaden.
Aus diesem Grund sind alle Konfigurationen darauf ausgelegt, sofern möglich und sinnvoll, die Communities logisch zu trennen. An dieser Stelle sei darauf hingewiesen, dass es sich also nicht um eine Gateway Anleitung für den
Infrastrukturaufbau für eine einzige Community handelt. Es ist aber durchaus möglich die hier aufgezeigten Konfigurationen dahingehend zu adaptieren.
Ziel des Ganzen soll nicht eine Auflistung von Konfigurationen sein, eher wollen wir am Beispiel derer unsere Gedankengänge und Hintergründe dazu beleuchten.
Die aktuelle Konfiguration der Gates ist jederzeit im gateway-configs.git zu finden.
Grundsätzlich dienen bei der Konfiguration eines neuen Gateways die bekannte Konfiguration der bestehenden Gates
als Vorbilder. Trotzdem werden hier wichtige Punkte explizit beschrieben und zusammengefasst.
Geschrieben in Zusammenarbeit von Freifunk-Mainz and Freifunk-Wiesbaden als freifunk-mwu auf GitHub.
Eine augenfreundliche Version dieser Dokumentation findet sich unter ffmwu-gateway-doku.readthedocs.org!
1
Freifunk MWU Gateway Doku, Release 0.1 beta
2
Kapitel 1. Beschreibung
KAPITEL 2
Intro
2.1 Voraussetzungen
• voller Root Zugriff für alle Admins
• öffentliche IPv4 Adresse
• öffentliche IPv6 Adresse
• voller Kernelzugriff
– Linux direkt installiert,
– oder als KVM-Instanz (OpenVZ o.ä. nicht möglich)
• Momentan: Ubuntu 14.04 LTS Server
2.1.1 Betrieb und Zugang
Wir stellen mit einem oder mehreren Gateways in Vereinshand eine Basisversorgung sicher.
Gerne sollen weitere Gateways aufgesetzt werden. Redundanz schafft Vertrauen!
Wer ein weiteres Gate betreiben möchte, muss sich vor der Installation in einigen technischen Punkten mit der AdminGruppe abstimmen. Möglichst viele Informationen sollen auch in dieser Dokumentation zu finden sein.
Am Besten wird der Gate-Betreiber gleich Teil des Admin-Teams :)
Jeder Admin muss die Möglichkeit haben jederzeit an jeder Stelle jedes beliebige Problem fixen zu können (und zu
dürfen). Die technischen Details zur Umsetzung sind der Admin-Gruppe bekannt.
2.1.2 Schema
Was wir für Dienste aufsetzen und wie diese inneinandergreifen lässt sich am Besten anhand einer schematischen
Darstellung erklären:
3
Freifunk MWU Gateway Doku, Release 0.1 beta
2.1.3 Funktionen & dafür benötigte Software
Momentan kommen auf allen Gateways eine Ubuntu Server 14.04 LTS Installation zum Einsatz. Jeweils angepasst auf
die entsprechenden Plattformen (Direkt auf dem Host, oder als KVM-Instanz).
Für viele der Gate-Funktionen wird weitere Software benötigt, die größtenteils als Pakete aus den Ubuntu- und weiteren Repositories nachinstalliert werden kann.
Siehe auch:
• Pakete
• Benötigte Repositories
Verbindung der Teilwolken
Die Nodes bauen ihr Freifunk mit dem Mesh-Protokoll B.A.T.M.A.N selbständig auf.
Da das Netz aber noch nicht dicht genug ist, dass alle Nodes sich über ihre Funk-Interfaces erreichen können, helfen
wir über eine VPN-Verbindung über das Internet nach, um einzelne Wolken zu überbrücken.
So wie über ihre Funk-Interfaces, sprechen die Nodes das B.A.T.M.A.N Protokoll auch über ihre VPN-Verbindungen.
Die Gates agieren als Fokuspunkte für dieses VPN. d.h. alle am VPN teilnehmenden Nodes verbinden sich zu den
Gates und Nodes und Gates spannen so das VPN auf.
Alle Gates verbinden sich für das VPN auch vollständig untereinander. So entsteht eine Multi-Stern-Architektur. Alle
Sternmittelpunkte sind untereinander voll vermascht.
Auf den Gates werden hierzu fastd sowie das Kernel Modul batman_adv benötigt.
Siehe auch:
• Pakete
4
Kapitel 2. Intro
Freifunk MWU Gateway Doku, Release 0.1 beta
• fastd
Mainz und Wiesbaden
Freifunk Mainz und Freifunk Wiesbaden werden als zwei getrennte Netze betrieben.
Das soll von Beginn an die Mesh-Wolken kleiner halten. Mesh-Protokolle skalieren nicht sehr gut, wenn viele Knoten
teilnehmen. (Grenze ab ca. 200 Nodes)
Das bedeutet, dass es zwei B.A.T.M.A.N Wolken gibt, was wiederum bedeutet, dass es auch zwei fastd VPNs pro
Gateway gibt.
Aus Gründen der Effizienz unterstützen die Gates aktuell jeweils beide Netze.
Siehe auch:
• Netzplan
Sollten die Netze in Zukunft stark wachsen, könnten weitere Aufteilungen nötig werden.
DHCP für die Clients
Nodes, Clients und Gates sind über ein Layer-2-Netz miteinander verbunden (B.A.T.M.A.N, s. o.).
Bemerkung: Oben ist zu lesen, dass es zwei Layer-2-Netze gibt. Im Folgenden wird immer eines davon betrachtet;
das andere funktioniert analog.
Die Gates halten auch als DHCP-Server für die Clients her.
Verfügbare IPv4-Ranges, aus denen der DHCP-Server vergeben darf, müssen innerhalb bzw. mit der Admin-Gruppe
abgestimmt werden, und werden im Netzplan festgehalten.
Hierfür wird isc-dhcp-server genutzt. Für das vorbereitende Ausrollen von IPv6 Adressen benötigen wir hier auch
radvd.
Siehe auch:
• DHCPd
• RAdvD
Übergang ins restliche Internet
Der Übergang ins Internet wird durch einen VPN-Tunnel nach Schweden oder in die Niederlande (ipredator.se, mullvad.net) getunnelt - im Falle von IPv4 ist das auch kaum anders zu realisieren, da die verwendeten Netze 10.37.0.0/16
und 10.56.0.0/16 im Internet nicht geroutet werden.
Zu diesem Zweck wird ein weiteres VPN zu einem Anbieter aufgebaut und aller Freifunk-Traffic dort entlang geschickt.
Damit dies gelingt muss auch dem Gate, in Richtung des Anbieters auch ein NATing (masquerading) erfolgen. Zur
besseren Administrierbarkeit wird jedes B.A.T.M.A.N-Interface noch in jeweils einer Netzwerk-Bridge gekapselt.
An dieser Stelle wird einiges an zusätzlicher Software gebraucht: bridge-utils, iproute, iptables & openvpn.
Siehe auch:
• Pakete
2.1. Voraussetzungen
5
Freifunk MWU Gateway Doku, Release 0.1 beta
• Netzwerk Interfaces
• Routing Tabellen
• Policy Routing
• Internet-Exit
Übergang zu anderen Freifunk-Communities (InterCityVPN)
Wie auch bei uns, so sind auch die IPv4-Netze der anderen Freifunk-Communities nicht über das restliche Internet zu
erreichen.
Damit interne Dienste auch aus anderen Städten genutzt werden können, wurde das IC-VPN als Verbindung der
Freifunk-Communities untereinander in’s Leben gerufen.
Als Software benutzen wir hier tinc und bird6.
Siehe auch:
• Pakete
• Netzwerk Interfaces
• Routing Tabellen
• Policy Routing
• icvpn
– IC-VPN
Datenschutz auf dem Gateway
Unsere Gateways loggen keinen Traffic!
Alles was existiert sind die zur Laufzeit benötigten Verbindungsdaten. DHCP-Leases, Batman Protokolldaten und die
ARP-Tabelle.
Diese werden nur im Arbeitsspeicher vorgehalten, ist das Gateway aus (z.B. die Herren in Grün nehmen den Server
mit), sind diese i.d.R. weg.
Siehe auch:
• Logging
2.2 Netzplan
Freifunk Mainz & Freifunk Wiesbaden sind TCP/IP-basierte Netzwerke. Deshalb haben die beteiligten Computer
(Clients, Gates und die Knoten) jeweils IP-Adressen, die eindeutig sein müssen.
Wird (z. B. aus Versehen) eine Adresse mehrfach verwendet, so führt das zu Problemen im Betrieb.
Andererseits müssen alle Adressen im Freifunk Mainz oder Freifunk Wiesbaden zum dem selben Adressbereich, sowie
zum selben Netz gehören.
6
Kapitel 2. Intro
Freifunk MWU Gateway Doku, Release 0.1 beta
2.2.1 IPv4
Wir haben für unserer Freifunk-Communities folgende Netze zugewiesen bekommen:
• Mainz - 10.37.0.0/16 = 37
• Wiesbaden - 10.56.0.0/16 = 56
Datenpakete aus diesen Adressbereichen werden innerhalb des Freifunks vermittelt, im großen weiten Internet aber
nicht geroutet (Hintergrundinformationen dazu gibt es hier).
Unser großes 10.X.0.0/16 (mit 65536 Adressen) teilen wir uns ein wenig ein:
10.X.0.0/16 wird nicht komplett genutzt, um in Zukunft noch was auf Halde zu haben. Wachsen ist immer einfacher als schrumpfen.
Wir nutzen von diesem Netz erstmal das untere Viertel: 10.X.0.0/18:
Netz
10.X.0.0/24
10.X.1.0/24
10.X.2.0/23
10.X.4.0/22
10.X.8.0/21
10.X.16.0/22
10.X.20.0/22
10.X.24.0/22
10.X.28.0/22
10.X.32.0/22
10.X.36.0/22
10.X.40.0/22
10.X.44.0/22
10.X.48.0/22
10.X.52.0/22
10.X.56.0/22
10.X.60.0/22
(bis)
10.X.0.255
10.X.1.255
10.X.3.255
10.X.7.255
10.X.15.255
10.X.19.255
10.X.23.255
10.X.27.255
10.X.31.255
10.X.35.255
10.X.39.255
10.X.43.255
10.X.47.255
10.X.51.255
10.X.55.255
10.X.59.255
10.X.63.255
Verwendung
Gateways
¬
Backbone
User Services
¬
Client DHCP-Range
Client DHCP-Range
Client DHCP-Range
Client DHCP-Range
Client DHCP-Range
Client DHCP-Range
Client DHCP-Range
Client DHCP-Range
Client DHCP-Range
Client DHCP-Range
Client DHCP-Range
Client DHCP-Range
verteilt durch
fix
¬
fix
fix
¬
Lotuswurzel
Spinat
Zitronengras
Parmesan
Kaschu
Wasserfloh
¬
¬
¬
¬
¬
Mettigel
status
in Betrieb
frei
in Betrieb
in Betrieb
frei
in Betrieb
in Betrieb
in Betrieb
in Betrieb
in Betrieb
in Betrieb
frei
frei
frei
frei
frei
Testbetrieb
2.2.2 IPv6
Wir nutzen das IPv6 ULA Prefix fdXX:b4dc:4b1e::/48
Dieses ist bei SixXS an zentraler Stelle registriert, siehe fd37:b4dc:4b1e::/48 oder fd56:b4dc:4b1e::/48
IPv6 Subnetze haben immer eine Prefix-Länge von 64 Bit. Durch das /48 Subnetz stehen uns also 2^16 = 65536 /64
IPv6 Subnetze zur Verfügung.
Fürs erste wird allein dieses IPv6 Subnetz verwendet: fdXX:b4dc:4b1e:0000::/64 (abgekürzt:
fdXX:b4dc:4b1e::/64, siehe Address Notation).
2.2.3 Interface Bezeichnung
Wir vergeben unsere Interface-Bezeichnungen einheitlich!
eth0
Mainz
Wiesbaden
eth0
Mesh (Nodes)
mzVPN
wiVPN
B.A.T.M.A.N
mzBAT
wiBAT
Bridge
mzBR
wiBR
Intercity-VPN
Exit VPN
icVPN
exitVPN
Dies erleichtert das Scripten und Debuggen.
2.2. Netzplan
7
Freifunk MWU Gateway Doku, Release 0.1 beta
2.2.4 Namenskonvention
Als Hostname der Gateways nehmen wir “irgendwas mit Nahrung”.
2.2.5 Next Node Adressen
Die Next Node Adressen sind dafür da, um sich im Fehler- oder Troubleshootingfall mit einem Freifunk Knoten zu
verbinden.
Diese Adressen sind auf jedem Knoten gleich. Der Freifunker muss sich nur diese Adresse(n) merken und seine
Netzwerkkarte für ein Subnetz konfigurieren, in dem diese Adresse(n) liegt um auf seinen Knoten zuzugreifen.
Wir nutzen dazu die jeweils niedrigsten Adressen
• Mainz:
– IPv4: 10.37.0.1
– IPv6: fd37:b4dc:4b1e::1
• Wiesbaden:
– IPv4: 10.56.0.1
– IPv6: fd56:b4dc:4b1e::1
2.2.6 Gateway-Schema
Bevor wir ein Gateway aufsetzen definieren wir einen Namen (leichter zu merken) und ziehen eine Nummer (1 <= x
< 255).
Mit den uns zugewiesenen Netznummern sowie der Gateway-Nummer und dem Gateway-Namen werden alle benötigten Informationen abgeleitet:
• IPv4
– Das Netz von unten auffüllen (10.x.0.0/24 ist für Gateways)
• MAC-Adresse
– Privates Prefix (02:00) + IPv4-Adresse in hexadezimal
– Beispiele (für Mainz):
* 10.37.0.1 -> 02:00:0a:25:00:01
* 10.37.23.42 -> 02:00:0a:25:17:2a
* 10.37.254.2 -> 02:00:0a:25:fe:02
– Beispiele (für Wiesbaden):
* 10.56.0.1 -> 02:00:0a:38:00:01
* 10.56.23.42 -> 02:00:0a:38:17:2a
* 10.56.254.2 -> 02:00:0a:38:fe:02
– Wer zu faul zum rechnen ist, darf auch gerne den IP2MAC-Konverter nutzen.
• IPv6
– Range-Prefix (fd37:b4dc:4b1e bzw. fd56:b4dc:4b1e) + IPv4 Adresse in hexadezimal, Doppelpunkte anpassen, führende Nullen streichen
8
Kapitel 2. Intro
Freifunk MWU Gateway Doku, Release 0.1 beta
– Beispiele (für Mainz):
* gate02 -> fd37:b4dc:4b1e::0a25:0002/64
* gate05 -> fd37:b4dc:4b1e::0a25:0005/64
– Beispiele (für Wiesbaden, abgekürzt):
* gate02 -> fd56:b4dc:4b1e::a38:2/64
* gate23 -> fd56:b4dc:4b1e::a38:17/64
• DNS
– xxxx.freifunk-mwu.de -> A- + AAAA-Record
– gateXX.freifunk-mwu.de -> CNAME auf s.o.
– Reverse DNS Eintrag korrekt setzen für Haupt DNS Namen: xxxx.freifunk-mwu.de
• IC-VPN
– Soll ein gate am IC-VPN teilnehmen benötigt es dafür noch weitere Einträge. Hier kann ein gate
immer nur im Namen einer der Communities auftreten, auch wenn es technisch trotzdem für alle
Communities agiert. (s. a. IC-VPN)
– Kurzname: [Stadt][Nr], z. B. mainz2
– DNS-Eintrag zum Aufbau des Transfernetzes
ic-[stadt][Nr].freifunk-[stadt].de
->
CNAME
nach
dem
Muster
– IP-Adressen (v4 und v6) im IC-VPN-Transfernetz, z. B. 10.207.1.37, fec0: :a:cf:1:25
2.2.7 Beispiel
Gateway: Lotuswurzel - Nummer: 23
Zahlen umwandeln:
dec
10
37
0
23
56
hex
0a
25
00
17
38
und einsetzen:
Lotuswurzel
IPv4
IPv6
MAC
DNS1
DNS2
CNAME1
CNAME2
Mainz
Wiesbaden
IC-VPN
10.37.0.23
10.56.0.23
10.207.0.56
fd37:b4dc:4b1e:0a25:00017
fd37:b4dc:4b1e:a38:17 fec0: :a:cf:0:38
02:00:0a:25:00:17
02:00:0a:38:00:17
02:00:0a:cf:00:38
lotuswurzel.freifunk-mwu.de
lotuswurzel.freifunk-mwu.de
.
lotuswurzel.ffmz.org lotuswurzel.ffwi.org .
gate23.freifunk-mwu.degate23.freifunk-mwu.deic-wiesbaden1.freifunk-wiesbaden.de
gate23.ffmz.org
2.2. Netzplan
gate23.ffwi.org
.
9
Freifunk MWU Gateway Doku, Release 0.1 beta
2.3 Gluon
Gluon entstand in Lübeck aus dem Bedarf heraus, einheitliche OpenWRT-Images für Freifunk-Nutzer herauszugeben,
die bereits vorkonfiguriert und mit allen Packages versehen waren.
Da es nicht nur in Lübeck Freifunk gibt, wurden alle Elemente zusammen getragen, modularisiert, und für alle
Freifunk-Communities veröffentlicht. Vielen Dank!
Es ist ein Aufsatz, der den normalen OpenWRT Source Code hernimmt, patcht, und anhand der Konfiguration alles
zurechtrückt um den OpenWRT-Bauprozess für einen Satz unterstützter Router-Modelle zu starten. Dabei können dem
OpenWRT noch weitere Pakete untergeschoben werden.
Heraus fallen fertige Images, vorkonfiguriert, nur noch flashen ist nötig. Bonus: Die Images werden noch fein mit
elliptischen Kurven signiert, um ein automatisches Updaten zu ermöglichen (Autoupdater ist ein Standard OpenWRTPaket für Gluon)
2.3.1 Hintergrund zu Gluon
Ein bisschen zu den Anfängen von Gluon und viel mehr zum technischen Hintergrund kann man unter folgenden
Links erfahren:
• http://luebeck.freifunk.net/wiki/gluon (http://luebeck.freifunk.net/wiki/Firmware)
• http://luebeck.freifunk.net/wiki/fastd-schlusselverwaltung
• http://nilsschneider.net/2012/12/24/openwrt-autoupdater.html
• http://nilsschneider.net/2013/02/17/fastd-tutorial.html
2.3.2 Links & Dokumentation
• Gluon Code: https://github.com/freifunk-gluon/gluon
• Gluon Pakete:
– https://github.com/freifunk-gluon/gluon/tree/master/package
– https://github.com/freifunk-gluon/packages
• Gluon Konfiguration (site.conf) https://github.com/freifunk-gluon/gluon/tree/master/docs/site-example
• Dokumentation: http://gluon.readthedocs.org/
• Github Wiki: https://github.com/freifunk-gluon/gluon/wiki
• fastd: http://fastd.readthedocs.org/
• Doku aus Hamburg: https://wiki.freifunk.net/Freifunk_Hamburg/Firmware#Gluon
2.3.3 Gluon in MWU
Für Mainz und Wiesbaden nutzen wir den unveränderten Quellcode, frisch aus Lübeck. Unter den folgenden Links
gelangt man zu unserer Gluon Konfiguration sowie unser Packages-Repo.
• site.conf: https://github.com/freifunk-mwu/site-ffmwu
• packages: https://github.com/freifunk-mwu/packages-ffmwu
Gebaut wird mit gluon-builder-ffmwu.
10
Kapitel 2. Intro
KAPITEL 3
Konfiguration
3.1 Grundkonfiguration
3.1.1 Hostname
Den Hostnamen setzen (ohne Domain):
echo "hostname" > /etc/hostname
/etc/hosts (am Beispiel von Lotuswurzel):
127.0.0.1
144.76.209.100
localhost
lotuswurzel.freifunk-mwu.de
lotuswurzel
# The following lines are desirable for IPv6 capable hosts
::1
localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
2a01:4f8:192:520::b4dc:4b1e
lotuswurzel.freifunk-mwu.de
lotuswurzel
3.1.2 Routing Tabellen
/etc/iproute2/rt_tables:
#
# reserved values
#
255
local
254
main
253
default
0
unspec
#
# local
#
# icvpn table
23
icvpn
#local community table
41
mwu
# internet exit table
61
ffinetexit
11
Freifunk MWU Gateway Doku, Release 0.1 beta
3.1.3 Wichtige Kernel Parameter
/etc/sysctl.conf:
# Freifunk specific settings
net.ipv4.ip_forward=1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.eth0.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.eth0.accept_ra = 0
# decrease nf_conntrack_tcp_timeout_established - default=432000
net.netfilter.nf_conntrack_tcp_timeout_established=86400
# increase conntrack table size - default=65535
net.netfilter.nf_conntrack_max=262140
# <3.18 Kernel noch folgendes hinzufügen:
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
Der letzte Teil sorgt dafür, dass die Firewall ip(6)tables und arptables nicht im Bridge-Interface filtern. Wir wollen aber
auf OSI Layer 2 nichts filtern. In neueren Kerneln gibt es jetzt ein eigenes Modul (bridge_filter) das nicht automatisch
geladen wird und somit nicht aktiv ist. Ältere Kernel (<3.18) haben diese Filter per default aktiv.
Danach neuladen:
sysctl -p /etc/sysctl.conf
Damit die Parameter net.netfilter.nf_conntrack* automatisch beim Booten gesetzt werden muss das Kernel Modul nf_conntrack geladen werden. Um das zu erreichen listen wir es in der Datei /etc/modules:
...
nf_conntrack
3.1.4 Benötigte Repositories
• Freifunk MWU Repository einbinden:
add-apt-repository ppa:freifunk-mwu/freifunk-ppa
• add-apt-repository Installieren (optional):
apt-get install software-properties-common
• Neoraiders Repository einbinden (für fastd):
echo "deb https://repo.universe-factory.net/debian/ sid main" > /etc/apt/sources.list.d/freifunk
apt-key adv --keyserver keyserver.ubuntu.com --recv 16EF3F64CB201D9C
• Repo für aktuelle BIRD Version:
12
Kapitel 3. Konfiguration
Freifunk MWU Gateway Doku, Release 0.1 beta
add-apt-repository ppa:cz.nic-labs/bird
Zum Schluss:
apt-get update
apt-get dist-upgrade
3.1.5 Pakete
Pakete aus den Standard-Repos installieren:
xargs apt-get install -y
apache2
apt-transport-https
bind9
bird
bridge-utils
ethtool
git
haveged
iproute
iptables
iptables-save
iptables-persistent
isc-dhcp-server
man-db
mosh
ntp
openvpn
python-argparse
python3
python3-netifaces
radvd
rrdtool
sysfsutils
vim
vnstat
vnstati
<CTRL>-d
Pakete aus den eigenen Repositories installieren:
apt-get install -y alfred alfred-json batadv-vis batctl batman-adv-dkms fastd tinc
Python Pakete via pip:
pip3 install py-cpuinfo
3.1.6 Sysfs Parameter
In der Datei /etc/sysfs.d/99-freifunk.conf nehmen wir die nötigen sysfs-Konfigurationen vor:
# increase batman-adv hop penalty (default=15)
class/net/mzBAT/mesh/hop_penalty = 60
class/net/wiBAT/mesh/hop_penalty = 60
3.1. Grundkonfiguration
13
Freifunk MWU Gateway Doku, Release 0.1 beta
# increase multicast hash table of freifunk bridges (default=512)
class/net/mzBR/bridge/hash_max = 2048
class/net/wiBR/bridge/hash_max = 2048
Batman-adv Modifikationen müssen für jede batman-adv Instanz vorgenommen werden.
3.1.7 NTP
Da die Kisten recht viel mit Crypto machen, ist es von Vorteil eine halbwegs genaue Uhrzeit parat zu haben.
Die /etc/ntp.conf bleibt nahezu unverändert:
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
driftfile /var/lib/ntp/ntp.drift
# Specify one or more NTP servers.
server 0.de.pool.ntp.org
server 1.de.pool.ntp.org
server 2.de.pool.ntp.org
server 3.de.pool.ntp.org
# Use Ubuntu's ntp server as a fallback.
server ntp.ubuntu.com
# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1
Im DHCPd werden alle Gateways als Zeitquellen konfiguriert und verteilt.
3.2 Netzwerk Interfaces
/etc/network/interfaces
Wir richten uns hier je eine bridge pro Mesh-Wolke, die wir versorgen wollen, ein.
Auf diese bridges binden sich die Dienste (wie DHCP, DNS, NTP, etc..). Das hoch/runterfahren der VPNs oder das
(neu-)starten von Diensten kann dadurch unabhängig voneinander geschehen.
Siehe auch:
• fastd
• DHCPd
• Routing Tabellen
• Policy Routing
• Internet-Exit
Hier eine bridge mit IPv4 und IPv6 am Beispiel von Wiesbaden:
14
Kapitel 3. Konfiguration
Freifunk MWU Gateway Doku, Release 0.1 beta
auto wiBR
iface wiBR inet static
hwaddress 02:42:0a:38:00:XX
address 10.56.0.X
netmask 255.255.192.0
pre-up
/sbin/brctl addbr $IFACE
up
/sbin/ip address add fd56:b4dc:4b1e::a38:X/64 dev $IFACE
post-down
/sbin/brctl delbr $IFACE
Siehe auch:
• Routing Tabellen
• Policy Routing
• Gateway-Schema
• Interface Bezeichnung
Wir haben uns dazu entschieden jegliche Up- & Down Scripte in der /etc/network/interfaces zu verwalten. Dies gestaltet alles übersichtlicher.
Scripte für fastd:
allow-hotplug wiVPN
iface wiVPN inet6 manual
hwaddress 02:00:0a:38:00:X
pre-up
/sbin/modprobe batman-adv
post-up
/usr/sbin/batctl -m wiBAT if add $IFACE
post-up
/sbin/ip link set dev wiBAT up
Zum Schluss noch für das B.A.T.M.A.N. Interface:
allow-hotplug wiBAT
iface wiBAT inet6 manual
pre-up
/sbin/modprobe batman-adv
post-up
/sbin/brctl addif wiBR $IFACE
post-up
/usr/sbin/batctl -m $IFACE it
post-up
/usr/sbin/batctl -m $IFACE vm
post-up
/usr/sbin/batctl -m $IFACE gw
pre-down
/sbin/brctl delif wiBR $IFACE
10000
server
server 96mbit/96mbit
|| true
3.3 Policy Routing
Wir setzen auf unseren Gateways Policy Routing ein, um den Netzwerkverkehr in die richtige Routing-Tabelle zu
schubsen.
Wie Policy Routing unter Linux funktioniert kann hier nachgelesen werden:
• LARTC
• Policy-Routing
Unter Linux konfiguriert man Routing Policies über sogenannte IP Rules. Damit diese immer vorhanden sind lassen
wir diese über das rc.local-Script setzen.
/etc/rc.local:
3.3. Policy Routing
15
Freifunk MWU Gateway Doku, Release 0.1 beta
#
# IP rules
#
# Priority 7 - lookup rt_table mwu for all incoming traffic of freifunk related interfaces
ip -4 rule add from all iif mzBR lookup mwu priority 7
ip -4 rule add from all iif wiBR lookup mwu priority 7
...
<IPv4 rules für IC-VPN>
<IPv4 rules für Internet Exit>
...
ip -6 rule add from all iif mzBR lookup mwu priority 7
ip -6 rule add from all iif wiBR lookup mwu priority 7
...
<IPv6 rules für IC-VPN>
<IPv6 rules für Internet Exit>
...
# Priortiy
ip -4 rule
ip -4 rule
ip -6 rule
ip -6 rule
23 - lookup rt_table icvpn for all
add from all iif mzBR lookup icvpn
add from all iif wiBR lookup icvpn
add from all iif mzBR lookup icvpn
add from all iif wiBR lookup icvpn
incoming
priority
priority
priority
priority
traffic of freifunk bridges
23
23
23
23
# Priority 41 - lookup rt_table ffinetexit for all incoming traffic of freifunk bridges
ip -4 rule add from all iif mzBR lookup ffinetexit priority 41
ip -4 rule add from all iif wiBR lookup ffinetexit priority 41
...
<IPv4 rules für Internet Exit>
<IPv6 rules für Internet Exit>
...
# Priority 61 - at this point this is the end of policy routing for freifunk related routes
ip -4 rule add from all iif mzBR type unreachable priority 61
ip -4 rule add from all iif wiBR type unreachable priority 61
...
<IPv4 rules für Internet Exit>
...
ip -4 rule add from all iif icVPN type unreachable priority 61
ip -4 rule add from all iif eth0 type unreachable priority 61
ip -6 rule add from all iif mzBR type unreachable priority 61
ip -6 rule add from all iif wiBR type unreachable priority 61
ip -6 rule add from all iif icVPN type unreachable priority 61
...
<IPv6 rules für Internet Exit>
...
ip -6 rule add from all iif eth0 type unreachable priority 61
# Priority
ip -4 rule
ip -4 rule
ip -6 rule
ip -6 rule
107
add
add
add
add
- lookup
from all
from all
from all
from all
policies for the gateway host self originating traffic
lookup mwu priority 107
lookup icvpn priority 107
lookup mwu priority 107
lookup icvpn priority 107
Wie zu erkennen ist verwenden wir 3 Routing Tabellen:
• icvpn (wird dynamisch über BGP gefüllt)
• mwu (enthält statische Routen der Community-Netze)
16
Kapitel 3. Konfiguration
Freifunk MWU Gateway Doku, Release 0.1 beta
• ffinetexit (enthält Routen für den Internet-Verkehr)
Die IP Rules für den Internet-Exit hängen von der gewählten Variante ab, mehr Informationen dazu im Abschnitt
Internet-Exit
Zusätzlich zu den IP Rules befüllen wir über das rc.local-Script auch die Routing-Tabellen mwu und icvpn mit den
nötigen statischen Routen:
#
# IP routes
#
# static route for icvpn transfer-net
/sbin/ip -4 route add 10.207.0.0/16 proto static dev icVPN table icvpn
/sbin/ip -6 route add fec0::/96 proto static dev icVPN table icvpn
# static mainz routes for rt_table mwu
/sbin/ip -4 route add 10.37.0.0/18 proto static dev mzBR table mwu
/sbin/ip -6 route add fd37:b4dc:4b1e::/64 proto static dev mzBR table mwu
# static wiesbaden routes for rt_table mwu
/sbin/ip -4 route add 10.56.0.0/18 proto static dev wiBR table mwu
/sbin/ip -6 route add fd56:b4dc:4b1e::/64 proto static dev wiBR table mwu
3.4 DNS-DHCP-IP
3.4.1 BIND
/etc/bind/named.conf.options:
options {
directory "/var/cache/bind";
dnssec-validation auto;
auth-nxdomain no;
# conform to RFC1035
listen-on { 127.0.0.1; 10.37.0.X; 10.56.0.X; 10.207.0.X; };
listen-on-v6 { ::1; fd37:b4dc:4b1e::a25:17; fd56:b4dc:4b1e::a38:17; fec0::a:cf:0:38; };
allow-transfer { any; };
allow-query { any; };
allow-recursion { 127.0.0.1; ::1; intern-mz; intern-wi; };
};
Wichtig: listen-on, listen-on-v6 ausschließlich auf die lokalen Interfaces und die IC-VPN Interfaces zeigen lassen.
Jedes Gate ist ein Slave für DNS (DNS Master läuft auf einem Service Server).
DNS-Slave
Die /etc/bind/named.conf.local bekommt pro Mesh-Wolke (z.B. für Wiesbaden):
masters "ns-master-wi" {
fd56:b4dc:4b1e::a38:103;
};
3.4. DNS-DHCP-IP
17
Freifunk MWU Gateway Doku, Release 0.1 beta
acl "intern-wi" {
10.56.0.0/16;
fd56:b4dc:4b1e::/48;
};
// Intern Zones for Freifunk
zone "ffwi.org." {
type slave;
file "ffwi.org.db";
masters { ns-master-wi; };
};
zone "user.ffwi.org." {
type slave;
file "user.ffwi.org.db";
masters { ns-master-wi; };
};
// Reverse Zones
zone "56.10.in-addr.arpa" {
type slave;
file "56.10.in-addr.arpa.db";
masters { ns-master-wi; };
};
zone "e.1.b.4.c.d.4.b.6.5.d.f.ip6.arpa" {
type slave;
file "fd56:b4dc:4b1e_48.ip6.arpa.db";
masters { ns-master-wi; };
};
Danach einen DNS-Eintrag auf sich selbst setzen:
Siehe auch:
Lokaler DNS Resolver
3.4.2 DHCPd
Aus dem Netzplan wird sich eine Range gezogen.
In den Header der /etc/dhcp/dhcpd.conf kommt:
ddns-update-style none;
authoritative;
server-name "lotuswurzel";
log-facility local6;
default-lease-time 300;
min-lease-time 300;
max-lease-time 300;
Die Direktive server-name ist auf den Hostnamen des jeweiligen Gateways anzupassen. Wir wählen hier eine kurze
Lease Time, damit die Clients maximal 5 Minuten offline sind.
Pro Mesh-Wolke verteilen wir jeweils eine Range (z.B. für Wiesbaden):
18
Kapitel 3. Konfiguration
Freifunk MWU Gateway Doku, Release 0.1 beta
subnet 10.56.0.0 netmask 255.255.192.0 {
range 10.56.X.0 10.56.X.255;
# Use our own IP as gateway for our clients
option routers 10.56.0.X;
# DNS server to be pushed to our clients.
option domain-name-servers 10.56.0.X;
option domain-search "ffwi.org", "user.ffwi.org";
# NTP Server pushed to our clients
option ntp-servers 10.56.0.X;
# Set interface mtu
option interface-mtu 1350;
}
Wichtig: domain-name-server und ntp-servers nur auf das Gate selbst setzen.
Warnung: Obwohl der DHCPd normalerweise regelmäßig sein Lease-File aufräumen soll, wird durch ein anscheinend übermäßig restriktives AppArmor-Profil der nötige Dateizugriff unterbunden. Hier ist der relevante Bugreport, leider ist nicht absehbar wann das gefixt wird, da ISC und Ubuntu sich gegenseitig den Schwarzen Peter
zuschieben.
Der Bug verhindert, dass beim Rotieren des Lease-Files die alten Leases nicht aufgeräumt werden können, und
somit auf ewig erhalten bleiben. Dies gilt zu vermeiden.
Fix
Im Bugreport wird von einem Fix berichtet, der die ACLs des Lease-Files korrekt setzt:
Wir installieren uns zunächst das Programm acl nach, stoppen den DHCPd, und setzen die ACLs:
apt-get install acl
service isc-dhcp-server stop
setfacl -dm u:dhcpd:rwx /var/lib/dhcp
setfacl -m u:dhcpd:rwx /var/lib/dhcp
service isc-dhcp-server start
Unter etc/default/isc-dhcp-server konfigurieren wir, auf welchen Interfaces der dhcpd lauschen soll.
Wir wählen die beiden bridges:
INTERFACES="mzBR wiBR"
Siehe auch:
• Netzwerk Interfaces
• Lokaler DNS Resolver
• NTP
3.4. DNS-DHCP-IP
19
Freifunk MWU Gateway Doku, Release 0.1 beta
3.4.3 RAdvD
Die Konfigurationsdatei muss manuell angelegt werden.
Pro Mesh-Wolke verteilen wir jeweils ein Prefix.
/etc/radvd.conf (z.B. für Mainz):
interface mzBR
{
AdvSendAdvert on;
IgnoreIfMissing on;
MaxRtrAdvInterval 900;
AdvLinkMTU 1350;
prefix fd37:b4dc:4b1e::/64
{
AdvValidLifetime 864000;
AdvPreferredLifetime 172800;
};
RDNSS fd37:b4dc:4b1e::a25:X
{
FlushRDNSS off;
};
};
Wichtig:
RDNSS nur auf das Gate selbst setzen.
3.5 fastd
Ordnerstruktur:
/etc/fastd/mzVPN - Config für Mainz
/etc/fastd/mzVPN/peers - Peers für Mainz
/etc/fastd/wiVPN - Config für Wiesbaden
/etc/fastd/wiVPN/peers - Peers für Wiesbaden
Die peers aus dem git klonen:
git clone https://github.com/freifunk-mwu/peers-ffmz /etc/fastd/mzVPN/peers
git clone https://github.com/freifunk-mwu/peers-ffwi /etc/fastd/wiVPN/peers
Bemerkung: Damit die Backend Scripte zum synchronisieren der Keys korrekt funktionieren (die Änderungen pushen
dürfen), sollte man sich zunächst um die Einrichtung dessen kümmern.
Danach wird entweder die Repo-Adresse in der /etc/fastd/xyVPN/peers/.git/config direkt angepasst
oder man klont die Repos neu:
git clone ssh://github_mwu/freifunk-mwu/peers-ffxy /etc/fastd/xyVPN/peers
Für die Backend Scripte muss der Nutzer darin schreiben dürfen:
sudo chown -R admin:admin /etc/fastd/*/peers/
20
Kapitel 3. Konfiguration
Freifunk MWU Gateway Doku, Release 0.1 beta
3.5.1 Konfiguration
/etc/fastd/mzVPN/fastd.conf:
log level warn;
hide ip addresses yes;
hide mac addresses yes;
interface "mzVPN";
method "salsa2012+umac";
# new method (faster)
# Bind von v4 and v6 interfaces
bind $eure_externe_ip4:10037;
bind [$eure_externe_ip6]:10037;
include "secret.conf";
mtu 1406; # 1492 - IPv4/IPv6 Header - fastd Header...
include peers from "peers";
status socket "/var/run/fastd-mainz.status";
/etc/fastd/wiVPN/fastd.conf:
Analog zu Mainz (Ports anpassen 10037 -> 10056)
3.5.2 Schlüsselpaar generieren
Das Schlüsselpaar schreibt man sich am besten in ein Tempfile:
fastd --generate-key >> /etc/fastd/wiVPN/MEINTEMPFILE
dauert manchmal ein bisschen :) keep calm :) Wenn euch das zu langsam ist, installiert euch den haveged daemon um
mehr Entropie zu generieren.
Das ganze sieht dann so aus:
/etc/fastd/wiVPN/MEINTEMPFILE:
Secret: "0000..ffff"
Public: "ffff..0000"
daraus die passenden Files erstellen (auf das ;-Zeichen achten, Groß-/Kleinschreibung beachten! ):
/etc/fastd/wiVPN/secret.conf:
secret "0000..ffff";
/etc/fastd/wiVPN/peers/GW_Nickname (z.B. Lotuswurzel, Spinat, Popcorn):
key "ffff...0000";
Achtet auf die korrekten Schreibweisen in der Gw_Nickname und der secret.conf! Groß- und Kleinschreibung sowie
das Semikolon am Ende sind wichtig, ansonsten kann es dazu kommen, dass die Bridge, Batman und VPN interfaces
nicht hochkommen.
3.5. fastd
21
Freifunk MWU Gateway Doku, Release 0.1 beta
3.6 A.L.F.R.E.D.
A.L.F.R.E.D. soll auf allen Gateways im Slave Modus laufen, A.L.F.R.E.D. daemons im Slave Modus senden ihre
Daten zum Master. Auf dem Server, der die Freifunk Knotenkarte hostet, läuft der A.L.F.R.E.D. Master.
Darüber hinaus muss auf allen Gateways zusätzlich batadv-vis im Server Modus laufen.
Dies sorgt dafür, dass jedes Gate seine batman_adv neighbors und local client table über A.L.F.R.E.D. bekannt gibt.
Ubuntu liefert keine A.L.F.R.E.D. Pakete mit, daher verwenden wir selbstgebaute Pakete.
In unseren Paketen liefern wir für Mainz und Wiesbaden schon vorgefertigte Beispiele.
Defaults beseitigen:
service alfred stop
service batadv-vis stop
rm /etc/default/alfred
rm /etc/init/alfred.conf
rm /etc/init/batadv-vis.conf
Danach kopieren wir die vorgefertigten Beispiele an die richige Stelle:
cp
cp
cp
cp
cp
cp
/usr/share/doc/alfred/examples/alfred-mz.default /etc/default/alfred-mz
/usr/share/doc/alfred/examples/alfred-wi.default /etc/default/alfred-wi
/usr/share/doc/alfred/examples/alfred-mz.upstart /etc/init/alfred-mz.conf
/usr/share/doc/alfred/examples/alfred-wi.upstart /etc/init/alfred-wi.conf
/usr/share/doc/batadv-vis/examples/batadv-vis-mz.upstart /etc/init/batadv-vis-mz.conf
/usr/share/doc/batadv-vis/examples/batadv-vis-wi.upstart /etc/init/batadv-vis-wi.conf
Und anschließend die beiden A.L.F.R.E.D. Instanzen starten:
service alfred-mz start
service alfred-wi start
Durch die Abhängigkeiten in den A.L.F.R.E.D. Upstart Scripts wird dafür gesorgt, dass die batadv-vis Instanzen
automatisch mitgestartet und gestoppt werden.
3.6.1 Announcements
Die Gateways sollen auch ein paar Daten über sich selbst via Alfred preisgeben, damit die Kartendaten rund werden.
Wir danken ffnord an dieser Stelle für die ffnord-alfred-announce Scripte. Wir haben diese unseren Bedürfnissen
angepasst und halten sie im Branch mwu vor: ffmwu-alfred-announce-mwu
Nun clonen wir dieses Repo und wechseln in den mwu Branch:
cd ~/clones
git clone https://github.com/freifunk-mwu/ffnord-alfred-announce.git
cd ~/clones/ffnord-alfred-announce && git checkout mwu
Konfiguration
Die momentan announcten Daten sind:
• Nodeinfo
– Hardware
* model
22
Kapitel 3. Konfiguration
Freifunk MWU Gateway Doku, Release 0.1 beta
– Network
* ip addresses
* primary mac
* mesh interfaces
– Software
* autoupdater (branch/state)
* batman_adv version
* batman_adv gw_mode
* fastd version
* firmware (OS Release)
– System
* role
* site_code
– Hostname
– Node ID
– VPN Status
• Statistics
– clients
– gateway (batman has selected)
– idletime
– loadavg
– memory
– node_id
– processes
– traffic
– uptime
Da wir die announce scripte mit einem normalen Benutzer ausführen, das Announcen an sich aber root Rechte erfordern benötigen wir die folgenden Wrapper-Sripts:
mkdir ~/bin
~/bin/alfred
#!/bin/sh
exec sudo /usr/sbin/alfred $*
EOCAT
~/bin/alfred-json
#!/bin/sh
exec sudo /usr/bin/alfred-json $*
EOCAT
3.6. A.L.F.R.E.D.
23
Freifunk MWU Gateway Doku, Release 0.1 beta
~/bin/batctl
#!/bin/sh
exec sudo /usr/bin/batctl $*
EOCAT
Nun kann die crontab des Benutzers gefüllt werden (crontab -e). Die Alfred Daten sollten minütlich announced werden:
* * * * * /home/admin/clones/ffnord-alfred-announce/announce.sh -i mzBR -b mzBAT -f mzVPN -s ffmz -u
* * * * * /home/admin/clones/ffnord-alfred-announce/announce.sh -i wiBR -b wiBAT -f wiVPN -s ffwi -u
3.7 Apache
Wir wollen keine Versionsdetails über den Apache Server preisgeben.
/etc/apache2/conf-available/security.conf:
...
# ServerTokens
# This directive configures what you return as the Server HTTP response
# Header. The default is 'Full' which sends information about the OS-Type
# and compiled in modules.
# Set to one of: Full | OS | Minimal | Minor | Major | Prod
# where Full conveys the most information, and Prod the least.
#ServerTokens Minimal
ServerTokens Prod
#ServerTokens Full
3.7.1 Firmware Repositories
Jedes Gateway dient als Firmware Repository für die Knoten.
Verzeichnisstruktur:
• /var/www/html/firmware
– mainz
* stable
* beta
* experimental
– wiesbaden
* stable
* beta
* experimental
Apache Konfiguration:
/etc/apache2/sites-available/firmware-mainz.conf:
24
Kapitel 3. Konfiguration
Freifunk MWU Gateway Doku, Release 0.1 beta
<VirtualHost *:80>
ServerName firmware.freifunk-mainz.de
ServerAlias firmware.ffmz.org
ServerAdmin [email protected]
DocumentRoot /var/www/html/firmware/mainz
<Directory /var/www/html/firmware/mainz>
Options Indexes FollowSymlinks
IndexOptions FancyIndexing +FoldersFirst +HTMLTable +NameWidth=*
AllowOverride None
Order allow,deny
allow from all
</Directory>
</VirtualHost>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
/etc/apache2/sites-available/firmware-wiesbaden.conf:
<VirtualHost *:80>
ServerName firmware.freifunk-wiesbaden.de
ServerAlias firmware.ffwi.org
ServerAdmin [email protected]
DocumentRoot /var/www/html/firmware/wiesbaden
<Directory /var/www/html/firmware/wiesbaden>
Options Indexes FollowSymlinks
IndexOptions FancyIndexing +FoldersFirst +HTMLTable +NameWidth=*
AllowOverride None
Order allow,deny
allow from all
</Directory>
</VirtualHost>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
/etc/apache2/sites-available/firmware-mwu.conf:
<VirtualHost *:80>
ServerName firmware.freifunk-mwu.de
ServerAdmin [email protected]
DocumentRoot /var/www/html/firmware
<Directory /var/www/html/firmware>
Options Indexes FollowSymlinks
IndexOptions FancyIndexing +FoldersFirst +HTMLTable +NameWidth=*
AllowOverride None
Order allow,deny
allow from all
</Directory>
</VirtualHost>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Anschließend die vhosts aktivieren und den apache daemon neuladen:
a2ensite firmware-mainz.conf
a2ensite firmware-wiesbaden.conf
a2ensite firmware-mwu.conf
3.7. Apache
25
Freifunk MWU Gateway Doku, Release 0.1 beta
apachectl -t
apachectl graceful
3.8 IC-VPN
Das IC-VPN beruht darauf, dass zwischen den teilnehmenden Communities ein IP-Routing (Layer 3) stattfindet. Dafür
wird über tinc ein Transfernetz zwischen einigen Gates aufgebaut. Über dieses Transfernetz wird dann ge-route-t.
Die Routing-Einträge auf diesen vielen Routern (Gates) werden nicht manuell, sondern per BGP gepflegt (die ASN für
Wiesbaden und Mainz sind 65036 und 65037). Es gibt zwei etablierte BGP-Implmentationen: Quagga und den BIRD
Daemon; wir haben uns für letztere entschieden. Auch hier folgen wir grob der zentralen Dokumentation und es sei
auf das im Aufbau befindliche IC-VPN-Meta-Repository für die Metainformationen sowie auf das IC-VPN-ScriptsRepository für die Erzeugung der BGP Peers sowie DNS Config verwiesen.
3.8.1 tinc
Bemerkung: Bisher ist leider noch nicht bewiesen, dass das IC-VPN-Setup für mehrere Communities auf einem Gate
funktioniert.
Alle Gates der am IC-VPN teilnehmenden Communities verbinden sich in einem Transfernetz untereinander. Um
ihre virtuellen Kabel zusammenstecken zu können, bauen sie sich dafür einen virtuellen Switch über das Internet auf.
Hierbei kommt tinc vpn zum Einsatz, ein Protokoll ganz ähnlich dem von uns intern genutzten fastd .
Jedes telnehmende Gate soll einen Eintrag in der zentralen Gate-Liste haben, um IP-Adress-Kollisionen zu vermeiden.
Aus Repräsentationsgründen sollte dort jede Community auch mit mindestens einem Eintrag vertreten sein. Die Lotuswurzel besetzt dort wiesbaden1 und Spinat soll mainz2 sein. Wie jedes diese Gates später auch die andere Community
vertreten kann, sehen wir später (BIRD).
Diese Liste soll offenbar durch ein IC-VPN-Meta-Repository auf Github abgelöst werden. In dieses Repository müssen
dann Einträge in die beiden Files wiesbaden und mainz vorgenommen werden. Aktuell empfiehlt es sich, beide
Informationsquellen zu pflegen: die Liste vor Beginn der Gate-Einrichtung, das Repository im Anschluss.
Unsere Art, das tinc für das IC-VPN einzurichten ist angelehnt an die entsprechende Freifunk-weite Beschreibung.
Die Ordnerstruktur für die Konfiguration sieht so aus:
/etc/tinc/ - Basisverzeichnis
/etc/tinc/icVPN/ - Config für das IC-VPN Netz
/etc/tinc/icVPN/hosts/ - keys aller Gates aller teilnehmenden communities
Dafür benötigen wir:
mkdir /etc/tinc/icVPN
chown admin:admin /etc/tinc/icVPN
# !!!
Die öffentlichen Schlüssel aller Gates aller teilnehmenden Communities verwaltet Freifunk ebenfalls in einem ICVPN-Repository auf Github. Dieses wird einfach auf unser neues Gate dupliziert (kennen wir ja schon):
git clone https://github.com/freifunk/icvpn /etc/tinc/icVPN/
Anschließend muss das file /etc/tinc/icVPN/tinc.conf angepasst (oder angelegt) werden. Es soll dann wie
folgt aussehen, der Name ist natürlich der passende für das entsprechende Gate (in diesem Beispiel für die Lotuswurzel):
26
Kapitel 3. Konfiguration
Freifunk MWU Gateway Doku, Release 0.1 beta
Name = wiesbaden1
PrivateKeyFile = /etc/tinc/icVPN/rsa_key.priv
Mode = Switch
PingTimeout = 30
Port = 10655
Hostnames = yes
Interface = icVPN
Aus Performance Gründen soll tinc aktiv nur Verbindungen zu ausgewählten sogenannten Metanodes aufbauen. Für
alle Metanodes müssen entsprechende ConnectTo =-Zeilen in der tinc Konfigurationsdatei tinc.conf eingetragen
werden. Diese Aufgabe übernimmt das post-merge Script für uns:
cp /home/admin/clones/backend-scripts/icvpn-tinc-post-merge /etc/tinc/icVPN/.git/hooks/post-merge
/etc/tinc/icVPN/.git/hooks/post-merge
Nun legen wir noch die /etc/tinc/icVPN/tinc-up an:
#!/bin/sh
/sbin/ifconfig ${INTERFACE} hw ether 02:00:0a:cf:XX:YY
/sbin/ip link set dev $INTERFACE up
# primary address: wiesbaden1
/sbin/ip addr add dev $INTERFACE 10.207.X.Y/16 broadcast 10.207.255.255 scope link
/sbin/ip -6 addr add dev $INTERFACE fec0::a:cf:X:Y/96 preferred_lft 0
Dabei sind X und Y die entsprechenden Stellen aus der Adresse des Gates im Transfernetz; in der v4-Adresse zur Basis
10 und in der v6-Adresse zur Basis 16.
Das passende /etc/tinc/icVPN/tinc-down:
#!/bin/sh
# primary address: wiesbaden1
/sbin/ip addr del dev $INTERFACE 10.207.X.Y/16 broadcast 10.207.255.255
/sbin/ip -6 addr del dev $INTERFACE fec0::a:cf:X:Y/96
# shutdown interface
/sbin/ip link set dev $INTERFACE down
Rechte anpassen:
chmod 755 /etc/tinc/icVPN/tinc-*
Ebenso, wie alle Partnergates ihre öffentlichen Schlüssel in /etc/tinc/icVPN/hosts/ liegen haben,
braucht auch unser neues Gate so etwas. Sollen die Schlüssel von einer alten Installation übernommen werden, können wir den folgenden Schlüssel-Generierungs-Schritt auslassen und die bestehenden einfach nach
/etc/tinc/icVPN/rsa_key.priv kopiert bzw. per Pull Request in das Repository transportiert.
Ein neues Schlüsselpaar wird mit einem Aufruf erzeugt:
tincd -n icvpn -K
die vorgeschlagenen Defaults passen. Unter /etc/tinc/icVPN/wiesbaden1 (oder dem entsprechenden Namen) findet sich der Public Key, der in das Repository wandern muss. Vorher müssen allerdings die Kontaktinformationen des tinc daemon auf diesem Gate hinzugefügt werden. An den Anfang der Datei:
Address = [fqdn oder IP-Adresse]
Port = 10655
[...]
3.8. IC-VPN
27
Freifunk MWU Gateway Doku, Release 0.1 beta
Bemerkung: Solange unsere Domains im Schwebestatus hängen, sollten wir als Adresse eine IP-Adresse des Gates
verwenden. Später sollte es ein extra CNAME (nur für diesen Zweck) auf das gate werden.
Als Letztes ist noch die Zeile icVPN der Datei /etc/tinc/nets.boot hinzuzufügen. Nun kann tinc gestartet
werden.
3.8.2 BIRD
dir structure
BIRD wird für IPv4 und IPv6 gesondert konfiguriert, wobei sich die Config Files allerdings sehr ähneln. Da die
Einträge für die Nachbarrouter im IC-VPN (peers) in Kürze halbautomatisch gepflegt werden sollen und die birdKonfiguration das Einbinden von config files in config files erlaubt, werden die peers schon jetzt ausgelagert. Damit
ergibt sich diese Dateistruktur:
/etc/bird/
/etc/bird/bird.conf
/etc/bird/ebgp_peers_v4.inc
/etc/bird/bird6.conf
/etc/bird/ebgp_peers_v6.inc
peer include files
In den beiden files ebgp_peers_v4.inc und ebgp_peers_v6.inc gibt es jeweils einen Eintrag pro Peer.
Nicht jeder Peer muss v4 und v6 anbieten. Die grundlegenden Paramter für die BGP-Verbindung sind für alle (externen) Peers identisch, so dass sie in einem Template (namens ebgp_ic) zusammengefasst sind. So ist jeder einzelne
Eintrag recht kurz und folgt dem Muster:
protocol bgp [name_of_peer] from ebgp_ic {
neighbor [IP_of_peer] as [AS_of_peer];
};
Die Adresse des Peer (=neighbor) ist in der v4-Config eine v4-Adresse und entsprechend in der v6-Config eine v6Adresse.
bird config
Im Großen und Ganzen handelt es sich bei uns um eine recht normale BIRD-BGP-Konfiguration (nachdem der Versuch, in bird eine gleichberechtigte Config für zwei AS hinzubekommen gescheitert war). Die Routen zu den anderen
Communities werden über BGP abgeglichen. Die eigenen Netze, die ins IC-VPN bekannt zu geben sind, werden über
einen protocol direkt-Eintrag bestimmt.
Das Config File wird mit den üblichen Standards eröffnet:
• Die router-id muss bei uns explizit gesetzt werden und entspricht der IP des Gates im IC-VPN-Transfernetz.
Als router-id kommt in beiden Konfigurationen die v4-(sic!)-Adresse zum Einsatz.
• Wenn wir zwei Kernel Routing Tables beschicken wollen, brauchen wir auch in BIRD dafür zwei Routing
Table s. Die zweite ist eine einfache Kopie der ersten, auf der ausschließlich gearbeitet wird.
• Die Definition von Konstanten erleichtert das Leben ein wenig.
28
Kapitel 3. Konfiguration
Freifunk MWU Gateway Doku, Release 0.1 beta
Es folgt jeweils ein Block mit ein paar Funktionen, die beim Filtern der zu sendenden und der empfangenen Routen
eingesetzt werden, um beides aus unserer Sicht zu kontrollieren (wir nehmen nicht jede angebotene Route an und
schicken auch nur Routen auf unsere eigenen Netze raus).
Die dann folgenden device-, direct-, kernel- und pipe-Protokolldefinitionen dienen der Kommunikation von
BIRD in Richtung des Kernels des hosts: Ohne device-Protokoll kann BIRD fast nichts. Über das direct-Protokoll
werden die aktiven mwu-eigenen Netze gefunden, die den Peers gegenüber beworben werden sollen und über die
kernel-Protokollinstanzen wird der Host mit den von den Peers erhaltenen Routing-Informationen versorgt.
Abgesehen von der mittels include eingebundenen Liste der Peers, bilden die template s für die BGPVerbindungen den Abschluss. Es gibt je ein Template für internal BGP und für external BGP. Jeweils werden
die eigene ASN, die eigene IP-Adresse für abgehende Verbindungen, die anzuwendenden Filter und ein paar Flags definiert. Alle diese Einstellungen sind für jeweils alle iBGP- und alle eBGP-Verbindungen gleich; es ändern sich immer
nur die Daten der entsprechenden Peers. Die Peers werden in eingebundenen File (für eBGP) bzw. im Anschluss (für
iBGP) unter Bezug auf diese Template s definiert.
Ein erwähnenswerter Punkt sind die export filter-Definitionen im eBGP. Jedes Gate kann im IC-VPN nur
im Namen einer Community auftreten und auch nur eine ASN nach dort anbieten. So nennen sich Lotuswurzel,
Hinterschinken und Spinat im IC-VPN z.B. wiesbaden1, wiesbaden2 und mainz2 (resp.). Während letzteres
die ASN 65037 bewirbt, geben die beiden anderen 65036 an. Intern können alle Gates aber Pakete an alle Communities
ausliefern. Deshalb gibt z.B. Spinat an, hinter seiner 65037 auch die 65036 erreichen zu können (liefert evtl. Pakete
dann aber natürlich direkt aus); die beiden anderen Gates verfahren entsprechend anders herum ebenso. Damit der
Spinat gegenüber den beiden anderen Gates beim Routing gen Wiesbaden nicht benachteiligt wird, geben letztere
bekannt, dass die Routen über sie nach dem ASN 65036 auch noch in das ASN 65036 müssen (via Spinat: 6503765036); ebenso anders herum wieder respektive. => Bei Übernahme der Configs von einer Community in die andere
ist also auch an dieser Stelle Änderungsbedarf!
Das iBGP wir nur innerhalb einer Community gefahren (also für Gates, die im IC-VPN als Wiesbadener Gates in
Erscheinung treten nur zu anderen Wiesbadener Gates; analog für Mainzer Gates)! Dagegen bauen wir eBGP Sessions
aber weder zu Mainzer, noch zu Wiesbadener Gates auf, als nur zu mwu-externen. Die Erzeugung der include files
soll bald mal - unter Verwendung der Daten aus dem IC-VPN-Meta-Repository automagisiert werden, ist aber aktuell
noch Handarbeit.
3.9 Internet-Exit
Um den Internet-Verkehr abzuwickeln existieren mehrere Möglichkeiten. Wir gehen hier auf die folgenden zwei Varianten ein.
• VPN Provider
• Freifunk Rheinland e.V.
Achtung, die Konfiguration dieser Varianten unterscheiden sich sehr stark.
3.9.1 VPN Provider
Prinzipiell kann jeder beliebige Internet-Provider gewählt werden. Die Konfiguration hier beschreiben wir am Beispiel
von Perfect Privacy.
Als erstes entledigt man sich aller alter Konfiguration:
rm -rf /etc/openvpn/*
Eine angepasste und lauffähige Konfiguration bekommt man meist vom Anbieter, in diesem Fall auch von Perfect
Privacy, die es herunterladen und zu entpacken gilt.
Konvention für die Konfigurationsdateien:
3.9. Internet-Exit
29
Freifunk MWU Gateway Doku, Release 0.1 beta
/etc/openvpn/perfect_privacy
-> Ordner mit allen Konfigurationsdateien, Zertifikaten, etc. des P
/etc/openvpn/perfect_privacy.conf -> Symlink auf die entsprechende Konfigurationsdatei im Unterordner
Wir wählen z.B. den Exit-Server in Frankfurt, setzen den Symlink:
cd /etc/openvpn
ln -s perfect_privacy/Frankfurt.ovpn perfect_privacy.conf
Nun muss die Konfiguration aufgrund der Pfade, des Routings des unten aufgeführten Hook-Scripts angepasst werden:
dev-type tun
dev exitVPN
auth-user-pass perfect_privacy/auth/auth.txt
#redirect-gateway def1
#route-delay 2
#route-method exe
route-noexec
...
ca perfect_privacy/ca.crt
cert perfect_privacy/Frankfurt_cl.crt
key perfect_privacy/Frankfurt_cl.key
tls-auth perfect_privacy/Frankfurt_ta.key 1
down /etc/openvpn/openvpn-updown
up /etc/openvpn/openvpn-updown
Wir haben nun alles Routing-spezifische in OpenVPN deaktiviert und nutzen dafür unser eigenes Hook-Script.
/etc/openvpn/openvpn-updown:
#!/bin/sh
# http://manpages.ubuntu.com/manpages/maverick/en/man8/openvpn.8.html#contenttoc5
set -x
ENVFILE="/tmp/ovpn-env-up"
echo "$@" > "$ENVFILE"
env >> "$ENVFILE"
manage_vpn_peer_routes() {
ACTION="$1"
ip route $ACTION "$route_vpn_gateway" dev "$dev" src "$ifconfig_local" table ffinetexit
}
manage_vpn_default_routes() {
ACTION="$1"
ip route $ACTION 0.0.0.0/1 via "$route_vpn_gateway" src "$ifconfig_local" table ffinetexit
ip route $ACTION 128.0.0.0/1 via "$route_vpn_gateway" src "$ifconfig_local" table ffinetexit
}
if [ "$script_type" = "up" ]; then
manage_vpn_peer_routes add
manage_vpn_default_routes replace
elif [ "$script_type" = "down" ]; then
manage_vpn_peer_routes del
fi
exit 0
30
Kapitel 3. Konfiguration
Freifunk MWU Gateway Doku, Release 0.1 beta
Policy Routing
Wir fügen nun noch die nötigen IP Rules in die /etc/rc.local ein:
...
# Priority 7 - lookup rt_table mwu for all incoming traffic of freifunk related interfaces
...
ip -4 rule add from all iif exitVPN lookup mwu priority 7
...
ip -6 rule add from all iif exitVPN lookup mwu priority 7
...
# Priority 61 - at this point this is the end of policy routing for freifunk related routes
...
ip -4 rule add from all iif exitVPN type unreachable priority 61
...
ip -6 rule add from all iif exitVPN type unreachable priority 61
...
Siehe auch:
• Routing Tabellen
• Policy Routing
Firewall
Um das Netz des ExitVPN Anbieters via NAT mit unserem zu verbinden muss Masquerading aktiviert werden:
iptables -t nat -A POSTROUTING -s 10.37.0.0/18,10.56.0.0/18 -o exitVPN -j MASQUERADE
und speichert dann die iptables config einmalig:
iptables-save > /etc/iptables/rules.v4
3.9.2 Freifunk Rheinland e.V.
Der Freifunk Rheinland e.V. war es Leid auf VPN-Provider angewiesen zu sein und hat die Anbindung an das Internet
selbst in die Hand genommen. Dazu sind sie RIPE-Mitglied sowie Sub-LIR geworden und haben unter Anderen das
IPv6-Prefix 2a03:2260::/29 sowie noch ein IPv4-Netz ergattert: 185.66.192.0/22.
Im Laufe des Jahres 2015 hat Freifunk Rheinland eine beachtliche Infrastruktur aufgebaut. Sie peeren z.B. in Berlin, Düsseldorf und Frankfurt an sogenannten Internet Exchange Points (IXP), um deren zugewiesenen IP-Netze ins
Internet zu “announcen”.
Die RIPE-Mitgliedschaft, das Peering in den IXPs sowie die erforderliche Hardware dafür ist alles andere als günstig.
Nicht jede Freifunk Community kann sich das leisten bzw. hat überhaupt die Manpower und Know-How derartiges
zu realisieren. Deshalb bietet der Freifunk Rheinland anderen Freifunk Communities die Internet-Abwicklung über
deren Infrastrukur an.
Wichtige Informationen über den Freifunk Rheinland e.V.:
• Freifunk Rheinland Homepage
• Rheinland Backbone Documents and Policies
• Backbone-announce Mailing-Liste
• Kategorie Rheinland Backbone im Freifunk Forum
3.9. Internet-Exit
31
Freifunk MWU Gateway Doku, Release 0.1 beta
• Ticket-System
• Autonomous System Number AS201701
– BGP Infos über dieses AS gibts bei bgp.he.net
• Videos über das Rheinland Backbone
– Wie funktioniert der Rheinland Backbone?
– Wie funktioniert AS201701?
Freifunk MWU IP-Netze
Wir haben vom Freifunk Rheinland folgende IP-Netze erhalten:
• Mainz
– 2a03:2260:11a::/48
– 185.66.195.32/30
• Wiesbaden
– 2a03:2260:11b::/48
– 185.66.195.36/30
Technischer Aufbau
Übersicht über die GRE-Endpunkte von Freifunk Rheinland:
• Berlin
– bb-a.ak.ber / 185.66.195.0
– bb-b.ak.ber / 185.66.195.1
• Düsseldorf
– bb-a.ix.dus / 185.66.193.0
– bb-b.ix.dus / 185.66.193.1
• Frankfurt
– bb-a.fra3.fra / 185.66.194.0
– bb-b.fra3.fra / 185.66.194.1
Prinzipiell wird von jedem Freifunk-Gateway zu jedem dieser Endpunkte ein GRE-Tunnel über IPv4 aufgebaut. Die
oben aufgelisteten Endpunkte sowie die öffentliche IPv4-Adresse des Freifunk-Gateways stellen die äußeren TunnelIPs dar. Jeder GRE-Tunnel hat je ein Transfernetz für IPv4 und IPv6 für die innere Kommunikation:
• IPv4: /31
– niederwertige IP = Rheinland
– höherwertige IP = Freifunk-Gateway
• IPv6: /64
– <Prefix>::1 = Rheinland
– <Prefix>::<beliebig> = Freifunk-Gateway
32
Kapitel 3. Konfiguration
Freifunk MWU Gateway Doku, Release 0.1 beta
Dieser schematische Aufbau soll das Konstrukt etwas verdeutlichen:
Pro GRE-Tunnel wird dann je eine BGP-Session für IPv4 und IPv6 aufgebaut, über die wir die uns zugewiesene
IPv4-NAT-Adresse bzw. unsere IPv6-Prefixe announcen.
Konfiguration
Zunächst nochmal die Übersicht über alle benötigten IP-Adressen:
• öffentliche IPv6-Prefixe
– Mainz: 2a03:2260:11a::/48
– Wiesbaden: 2a03:2260:11b::/48
– aktuell wird immer das erste /64er Subnetz verwendet
– Die IPv6-Adressen der Gates ergeben sich aus dem Prefix und dem bisherigen Interface-Identifier
• öffentliche IPv4-Netze
– Mainz: 185.66.195.32/30
– Wiesbaden: 185.66.195.36/30
– diese stellen “NAT-IP-Adressen” dar, jedes Gateway erhält eine öffentliche NAT-IP-Adresse
• dazu kommen noch die inneren Transfernetze, die sich pro Gate unterscheiden
In der folgenden Tabelle halten wir die inneren Transfernetze und IPv4-NAT-Adressen der Gateways fest:
3.9. Internet-Exit
33
Freifunk MWU Gateway Doku, Release 0.1 beta
Gateway
Kaschu
Lotuswurzel
Zitronengras
Spinat
IPv4TransfernetNATze
Adresse bb-a.ak.ber
Transfernetze
bb-b.ak.ber
Transfernetze
bb-a.ix.dus
Transfernetze
bb-b.ix.dus
TransferTransfernetnetze
ze
bbbba.fra3.fra
b.fra3.fra
185.66.195.37
100.64.2.100/31 100.64.2.102/31 100.64.2.104/31 100.64.2.106/31 100.64.2.108/31100.64.2.110/31
2a03:2260:0:13b::/64
2a03:2260:0:13c::/64
2a03:2260:0:13d::/64
2a03:2260:0:13e::/64
2a03:2260:0:13f::/64
2a03:2260:0:140::/64
185.66.195.36
100.64.1.190/31 100.64.1.20/31 100.64.2.84/31 100.64.1.22/31 100.64.1.192/31100.64.2.86/31
2a03:2260:0:e9::/64
2a03:2260:0:91::/64
2a03:2260:0:133::/64
2a03:2260:0:92::/64
2a03:2260:0:ea::/64
2a03:2260:0:134::/64
185.66.195.39
100.64.2.234/31 100.64.2.236/31 100.64.2.238/31 100.64.2.240/31 ¬
2a03:2260:0:17f::/64
2a03:2260:0:180::/64
2a03:2260:0:181::/64
2a03:2260:0:182::/64
185.66.195.32
100.64.2.226/31 100.64.2.228/31 100.64.2.230/31 100.64.2.232/31 ¬
2a03:2260:0:17b::1/64
2a03:2260:0:17c::1/64
2a03:2260:0:17d::1/64
2a03:2260:0:17e::1/64
Was- 185.66.195.33
100.64.2.218/31 100.64.2.220/31 100.64.2.222/31 100.64.2.224/31 ¬
serfloh
2a03:2260:0:177::1/64
2a03:2260:0:178::1/64
2a03:2260:0:179::1/6
2a03:2260:0:17a::1/64
¬
¬
¬
Die nachfolgende Konfiguration erfolgt am Beispiel des Gateways Lotuswurzel.
Interfaces
In der /etc/network/interfaces legen wir die GRE-Tunnel an:
# GRE-Tunnel zu bb-a.ak.ber
auto ffrl-a-ak-ber
iface ffrl-a-ak-ber inet static
address 100.64.1.191
netmask 255.255.255.254
pre-up
/sbin/ip
post-up
/sbin/ip
post-up
/sbin/ip
post-down
/sbin/ip
tunnel add $IFACE mode gre local 144.76.209.100 remote 185.66.195.0
link set $IFACE mtu 1400
addr add 185.66.195.36/32 dev $IFACE
tunnel del $IFACE
iface ffrl-a-ak-ber inet6 static
address 2a03:2260:0:e9::2
netmask 64
# GRE-Tunnel zu bb-b.ak.ber
auto ffrl-b-ak-ber
iface ffrl-b-ak-ber inet static
address 100.64.1.21
netmask 255.255.255.254
pre-up
/sbin/ip
post-up
/sbin/ip
post-up
/sbin/ip
post-down
/sbin/ip
tunnel add $IFACE mode gre local 144.76.209.100 remote 185.66.195.1
link set $IFACE mtu 1400
addr add 185.66.195.36/32 dev $IFACE
tunnel del $IFACE
iface ffrl-b-ak-ber inet6 static
address 2a03:2260:0:91::2
netmask 64
34
Kapitel 3. Konfiguration
Freifunk MWU Gateway Doku, Release 0.1 beta
# GRE-Tunnel zu bb-a.ix.dus
auto ffrl-a-ix-dus
iface ffrl-a-ix-dus inet static
address 100.64.2.85
netmask 255.255.255.254
pre-up
/sbin/ip
post-up
/sbin/ip
post-up
/sbin/ip
post-down
/sbin/ip
tunnel add $IFACE mode gre local 144.76.209.100 remote 185.66.193.0
link set $IFACE mtu 1400
addr add 185.66.195.36/32 dev $IFACE
tunnel del $IFACE
iface ffrl-a-ix-dus inet6 static
address 2a03:2260:0:133::2
netmask 64
# GRE-Tunnel zu bb-b.ix.dus
auto ffrl-b-ix-dus
iface ffrl-b-ix-dus inet static
address 100.64.1.23
netmask 255.255.255.254
pre-up
/sbin/ip
post-up
/sbin/ip
post-up
/sbin/ip
post-down
/sbin/ip
tunnel add $IFACE mode gre local 144.76.209.100 remote 185.66.193.1
link set $IFACE mtu 1400
addr add 185.66.195.36/32 dev $IFACE
tunnel del $IFACE
iface ffrl-b-ix-dus inet6 static
address 2a03:2260:0:92::2
netmask 64
# GRE-Tunnel zu bb-a.fra3.fra
auto ffrl-a-fra3-fra
iface ffrl-a-fra3-fra inet static
address 100.64.1.193
netmask 255.255.255.254
pre-up
/sbin/ip tunnel add $IFACE mode gre local 144.76.209.100 remote 185.66.194.0
post-up
/sbin/ip link set $IFACE mtu 1400
post-up
/sbin/ip addr add 185.66.195.36/32 dev $IFACE
post-down
/sbin/ip tunnel del $IFACE
iface ffrl-a-fra3-fra inet6 static
address 2a03:2260:0:ea::2
netmask 64
# GRE-Tunnel zu bb-b.fra3.fra
auto ffrl-b-fra3-fra
iface ffrl-b-fra3-fra inet static
address 100.64.2.87
netmask 255.255.255.254
pre-up
/sbin/ip tunnel add $IFACE mode gre local 144.76.209.100 remote 185.66.194.1
post-up
/sbin/ip link set $IFACE mtu 1400
post-up
/sbin/ip addr add 185.66.195.36/32 dev $IFACE
post-down
/sbin/ip tunnel del $IFACE
iface ffrl-b-fra3-fra inet6 static
address 2a03:2260:0:134::2
netmask 64
Neben der ip tunnel-Direktive, die den GRE-Tunnel mit den äußeren IPv4-Adressen aufbaut, wird jeweils
immer die entsprechende IP-Adresse aus dem Transfernetz für IPv4 + IPv6 auf das Tunnel-Interface gelegt. Darüber
3.9. Internet-Exit
35
Freifunk MWU Gateway Doku, Release 0.1 beta
hinaus legen wir auf jedes Tunnel-Interface dieselbe IPv4-NAT-Adresse.
Für IPv6 erhält jede Freifunk-Bridge nun eine IPv6-Adresse aus den entpsrechenden Netzen:
auto mzBR
iface mzBR inet static
...
up
/sbin/ip address add 2a03:2260:11a::a25:17/64 dev $IFACE
...
auto wiBR
iface wiBR inet static
...
up
/sbin/ip address add 2a03:2260:11b::a38:17/64 dev $IFACE
...
Nach einem Neustart und vorausgesetzt die Gegenstellen sind alle konfiguriert sind die GRE-Tunnel nun up and
running. Die Gegenstellen der Transfernetze sind nun erreichbar, aber wir können noch keinen Traffic über die Tunnel
schicken. Für das Routing bedarf es noch BGP-Sessions.
BGP
Dynamisches Routing mittels BGP machen wir mit BIRD. Was brauchen wir alles für BGP?
• Freifunk Rheinland ASN: 201701
• Mainzer ASN: 65037
• BIRD Routing-Tabelle: ffrl
• Import-Filter
• Export-Filter
IPv4 Die BIRD Konfiguration für IPv4 liegt bei uns unter /etc/bird/bird.conf. Diese Konfiguration ist teils Geschmackssache und jeder Admin macht die etwas anders. Deshalb zeigen wir hier nur Ausschnitte, ein einfaches
Copy & Paste wird nicht funktionieren:
# interne BIRD Routing-Tabelle
table ffrl;
define ffrl_nat_address = 185.66.195.36; #ffrlnat
# Funktionen, die später aufgerufen werden
function is_ffrl_nat() {
return net ~ [
185.66.195.36/32
];
}
function is_ffrl_tunnel_nets() {
return net ~ [
100.64.1.20/31,
100.64.1.22/31,
100.64.1.190/31,
100.64.1.192/31,
100.64.2.84/31,
100.64.2.86/31
];
36
Kapitel 3. Konfiguration
Freifunk MWU Gateway Doku, Release 0.1 beta
}
# BGP Import Filter für Rheinland
filter ebgp_ffrl_import_filter {
if is_default() then accept;
reject;
}
# BGP Export Filter für Rheinland
filter ebgp_ffrl_export_filter {
if is_ffrl_nat() then accept;
reject;
}
# IP-NAT-Adresse legen wir in die interne BIRD Routing Table
protocol static ffrl_uplink_hostroute {
table ffrl;
route 185.66.195.36/32 reject;
}
# Wir legen die Transfernetze in die interne BIRD Routing Table
protocol direct {
table ffrl;
interface "ffrl-*";
import where is_ffrl_tunnel_nets();
}
# Wir exportieren über Rheinland gelernte Routen in die Kernel Table 61 (ffinetexit)
protocol kernel kernel_ffrl {
scan time 30;
import none;
export filter {
krt_prefsrc = ffrl_nat_address;
accept;
};
table ffrl;
kernel table 61;
};
# BGP Template für Rheinland Peerings
template bgp ffrl_uplink {
table ffrl;
local as 65037;
import keep filtered;
import filter ebgp_ffrl_import_filter;
export filter ebgp_ffrl_export_filter;
next hop self;
direct;
};
# P E E R I N G S
# FFRL Berlin bb-a.ak.ber
protocol bgp ffrl_ber1 from ffrl_uplink {
source address 100.64.1.191;
neighbor 100.64.1.190 as 201701;
default bgp_local_pref 200;
};
3.9. Internet-Exit
37
Freifunk MWU Gateway Doku, Release 0.1 beta
# FFRL Berlin bb-b.ak.ber
protocol bgp ffrl_ber2 from ffrl_uplink {
source address 100.64.1.21;
neighbor 100.64.1.20 as 201701;
};
# FFRL Duesseldorf bb-ba.ix.dus
protocol bgp ffrl_dus1 from ffrl_uplink {
source address 100.64.2.85;
neighbor 100.64.2.84 as 201701;
};
# FFRL Duesseldorf bb-b.ix.dus
protocol bgp ffrl_dus2 from ffrl_uplink {
source address 100.64.1.23;
neighbor 100.64.1.22 as 201701;
};
# FFRL Frankfurt bb-a.fra3
protocol bgp ffrl_fra1 from ffrl_uplink {
source address 100.64.1.193;
neighbor 100.64.1.192 as 201701;
};
# FFRL Frankfurt bb-b.fra3
protocol bgp ffrl_fra2 from ffrl_uplink {
source address 100.64.2.87;
neighbor 100.64.2.86 as 201701;
};
Wenn die BGP-Sessions aufgebaut sind schauen wir uns mal die interne BIRD Routing Table an:
[root@lotuswurzel ~] birdc show route table ffrl
BIRD 1.5.0 ready.
0.0.0.0/0
via 100.64.1.190 on ffrl-a-ak-ber [ffrlber1 12:14:10] * (100/0) [AS201701i]
via 100.64.1.20 on ffrl-b-ak-ber [ffrlber2 12:14:14] (100/0) [AS201701i]
via 100.64.2.86 on ffrl-b-fra3-fra [ffrlfra2 12:14:13] (100/0) [AS201701i]
via 100.64.2.84 on ffrl-a-ix-dus [ffrldus1 12:14:13] (100/0) [AS201701i]
via 100.64.1.192 on ffrl-a-fra3-fra [ffrlfra1 12:14:08] (100/0) [AS201701i]
via 100.64.1.22 on ffrl-b-ix-dus [ffrldus2 12:13:20] (100/0) [AS201701i]
100.64.1.20/31
dev ffrl-b-ak-ber [direct1 12:13:16] * (240)
100.64.2.84/31
dev ffrl-a-ix-dus [direct1 12:13:16] * (240)
100.64.1.22/31
dev ffrl-b-ix-dus [direct1 12:13:16] * (240)
100.64.2.86/31
dev ffrl-b-fra3-fra [direct1 12:13:16] * (240)
100.64.1.192/31
dev ffrl-a-fra3-fra [direct1 12:13:16] * (240)
100.64.1.190/31
dev ffrl-a-ak-ber [direct1 12:13:16] * (240)
185.66.195.36/32
unreachable [ffrl_uplink_hostroute 12:13:16] * (200)
Hier erkennt man die über Rheinland gelernte IPv4 Default Route über 6 verschiedene Router. Wir announcen hingegen nur die IPv4-NAT-Adresse.
IPv6 Die BIRD Konfiguration für IPv6 liegt bei uns unter /etc/bird/bird6.conf. Diese Konfiguration ist teils Geschmackssache und jeder Admin macht die etwas anders. Deshalb zeigen wir hier nur Ausschnitte, ein einfaches Copy
& Paste wird nicht funktionieren:
# interne BIRD Routing-Tabelle
table ffrl;
38
Kapitel 3. Konfiguration
Freifunk MWU Gateway Doku, Release 0.1 beta
# Funktionen, die später aufgerufen werden
function is_default() {
return net ~ [
::/0
];
}
function is_ffrl_public_nets() {
return net ~ [
2a03:2260:11a::/48,
2a03:2260:11b::/48
];
}
function is_ffrl_tunnel_nets() {
return net ~ [
2a03:2260:0:91::/64,
2a03:2260:0:92::/64,
2a03:2260:0:e9::/64,
2a03:2260:0:ea::/64,
2a03:2260:0:133::/64,
2a03:2260:0:134::/64
];
}
# BGP Import Filter für Rheinland
filter ebgp_ffrl_import_filter {
if is_default() then accept;
reject;
}
# BGP Export Filter für Rheinland
filter ebgp_ffrl_export_filter {
if is_ffrl_public_nets() then accept;
reject;
}
# Wir legen die Transfernetze in die interne BIRD Routing Table
protocol direct {
table ffrl;
interface "ffrl-*";
import where is_ffrl_tunnel_nets();
}
# Wir legen unsere Public v6-Netze in die interne BIRD Routing Table
protocol static ffrl_public_routes {
table ffrl;
route 2a03:2260:11a::/48 reject;
route 2a03:2260:11b::/48 reject;
}
# Wir exportieren über Rheinland gelernte Routen in die Kernel Table 61 (ffinetexit)
protocol kernel kernel_ffrl {
scan time 30;
import none;
export filter {
if is_default() then accept;
reject;
3.9. Internet-Exit
39
Freifunk MWU Gateway Doku, Release 0.1 beta
};
table ffrl;
kernel table 61;
}
# BGP Template für Rheinland Peerings
template bgp ffrl_uplink {
table ffrl;
local as 65037;
import keep filtered;
import filter ebgp_ffrl_import_filter;
export filter ebgp_ffrl_export_filter;
next hop self;
direct;
};
# P E E R I N G S
# FFRL Berlin bb-a.ak.ber
protocol bgp ffrl_ber1 from ffrl_uplink {
source address 2a03:2260:0:e9::2;
neighbor 2a03:2260:0:e9::1 as 201701;
}
# FFRL Berlin bb-b.ak.ber
protocol bgp ffrl_ber2 from ffrl_uplink {
source address 2a03:2260:0:91::2;
neighbor 2a03:2260:0:91::1 as 201701;
default bgp_local_pref 200;
}
# FFRL Duesseldorf bb-a.ix.dus
protocol bgp ffrl_dus1 from ffrl_uplink {
source address 2a03:2260:0:133::2;
neighbor 2a03:2260:0:133::1 as 201701;
}
# FFRL Duesseldorf bb-b.ix.dus
protocol bgp ffrl_dus2 from ffrl_uplink {
source address 2a03:2260:0:92::2;
neighbor 2a03:2260:0:92::1 as 201701;
}
# FFRL Frankfurt bb-a.fra3.fra
protocol bgp ffrl_fra1 from ffrl_uplink {
source address 2a03:2260:0:ea::2;
neighbor 2a03:2260:0:ea::1 as 201701;
}
# FFRL Frankfurt bb-b.fra3.fra
protocol bgp ffrl_fra2 from ffrl_uplink {
source address 2a03:2260:0:134::2;
neighbor 2a03:2260:0:134::1 as 201701;
}
Wenn die BGP-Sessions aufgebaut sind schauen wir uns mal die interne BIRD Routing Table an:
40
Kapitel 3. Konfiguration
Freifunk MWU Gateway Doku, Release 0.1 beta
[root@lotuswurzel ~] birdc6 show route table ffrl
BIRD 1.5.0 ready.
::/0
via 2a03:2260:0:91::1 on ffrl-b-ak-ber [ffrlber2 2015-11-19] * (100/0) [AS201701i]
via 2a03:2260:0:92::1 on ffrl-b-ix-dus [ffrldus2 10:13:44] (100/0) [AS201701i]
via 2a03:2260:0:ea::1 on ffrl-a-fra3-fra [ffrlfra1 2015-11-19] (100/0) [AS201701i]
via 2a03:2260:0:134::1 on ffrl-b-fra3-fra [ffrlfra2 2015-11-19] (100/0) [AS201701i
via 2a03:2260:0:133::1 on ffrl-a-ix-dus [ffrldus1 2015-11-19] (100/0) [AS201701i]
via 2a03:2260:0:e9::1 on ffrl-a-ak-ber [ffrlber1 2015-11-19] (100/0) [AS201701i]
2a03:2260:0:133::/64 dev ffrl-a-ix-dus [direct1 2015-11-19] * (240)
2a03:2260:0:134::/64 dev ffrl-b-fra3-fra [direct1 2015-11-19] * (240)
2a03:2260:0:e9::/64 dev ffrl-a-ak-ber [direct1 2015-11-19] * (240)
2a03:2260:0:ea::/64 dev ffrl-a-fra3-fra [direct1 2015-11-19] * (240)
2a03:2260:0:91::/64 dev ffrl-b-ak-ber [direct1 2015-11-19] * (240)
2a03:2260:0:92::/64 dev ffrl-b-ix-dus [direct1 2015-11-19] * (240)
2a03:2260:11a::/48 unreachable [ffrl_public_routes 2015-11-19] * (200)
2a03:2260:11b::/48 unreachable [ffrl_public_routes 2015-11-19] * (200)
Hier erkennt man die über Rheinland gelernte IPv6 Default Route über 6 verschiedene Router. Wir announcen hingegen unsere zugewiesenen /48er IPv6-Prefixe.
iptables
Für IPv4 natten wir weiterhin und legen dafür die entsprechenden iptables Regeln an:
iptables
iptables
iptables
iptables
iptables
-t
-t
-t
-t
-t
nat
nat
nat
nat
nat
-N
-A
-A
-A
-A
ffrl-nat
ffrl-nat -s
ffrl-nat -s
POSTROUTING
POSTROUTING
10.37.0.0/16 -o
10.56.0.0/16 -o
-s 10.37.0.0/16
-s 10.56.0.0/16
ffrl+ -j
ffrl+ -j
-o ffrl+
-o ffrl+
SNAT --to-source 185.66.195.36
SNAT --to-source 185.66.195.36
-j ffrl-nat
-j ffrl-nat
iptables-save > /etc/iptables/rules.v4
Die GRE-Tunnel haben alle eine MTU von 1400 Bytes. Leider filtern viele Systeme im Internet noch wichtige ICMP
Pakete, sodass die wunderbare Path MTU Discovery nicht immer funktioniert. Ohne weiteren Eingriff würde das dazu
führen, dass viele TCP Verbindungen einfach nicht aufgebaut werden können. Deshalb müssen wir die TCP MSS auf
die Path-MTU anpassen und ergänzen folgende iptables Regeln:
iptables
iptables
iptables
iptables
-A
-A
-A
-A
FORWARD
FORWARD
FORWARD
FORWARD
-i
-i
-i
-i
wiBR -o ffrl+
mzBR -o ffrl+
ffrl+ -o wiBR
ffrl+ -o mzBR
-p
-p
-p
-p
tcp
tcp
tcp
tcp
-m
-m
-m
-m
tcp
tcp
tcp
tcp
--tcp-flags
--tcp-flags
--tcp-flags
--tcp-flags
SYN,RST
SYN,RST
SYN,RST
SYN,RST
SYN
SYN
SYN
SYN
-j
-j
-j
-j
TCPMSS
TCPMSS
TCPMSS
TCPMSS
--clamp-mss-to-p
--clamp-mss-to-p
--clamp-mss-to-p
--clamp-mss-to-p
iptables-save > /etc/iptables/rules.v4
ip6tables
ip6tables
ip6tables
ip6tables
-A
-A
-A
-A
FORWARD
FORWARD
FORWARD
FORWARD
-i
-i
-i
-i
wiBR -o ffrl+
mzBR -o ffrl+
ffrl+ -o wiBR
ffrl+ -o mzBR
-p
-p
-p
-p
tcp
tcp
tcp
tcp
-m
-m
-m
-m
tcp
tcp
tcp
tcp
--tcp-flags
--tcp-flags
--tcp-flags
--tcp-flags
SYN,RST
SYN,RST
SYN,RST
SYN,RST
SYN
SYN
SYN
SYN
-j
-j
-j
-j
TCPMSS
TCPMSS
TCPMSS
TCPMSS
--clamp-mss-to--clamp-mss-to--clamp-mss-to--clamp-mss-to-
ip6tables-save > /etc/iptables/rules.v6
Policy Routing
Wie im Kapitel Policy Routing beschrieben müssen wir dafür sorgen, dass die richtige Routing Tabelle für das Routing befragt wird. Für das Internet-Routing über Freifunk Rheinland sind noch folgende IP Rules in der /etc/rc.local
erforderlich:
3.9. Internet-Exit
41
Freifunk MWU Gateway Doku, Release 0.1 beta
# Priority
...
ip -4 rule
ip -4 rule
ip -4 rule
ip -4 rule
ip -4 rule
ip -4 rule
...
ip -6 rule
ip -6 rule
ip -6 rule
ip -6 rule
ip -6 rule
ip -6 rule
ip -6 rule
ip -6 rule
7 - lookup rt_table mwu for all incoming traffic of freifunk related interfaces
# Priority
...
ip -4 rule
ip -6 rule
ip -6 rule
41 - lookup rt_table ffinetexit for all incoming traffic of freifunk bridges
# Priority
...
ip -4 rule
ip -4 rule
ip -4 rule
ip -4 rule
ip -4 rule
ip -4 rule
...
ip -6 rule
ip -6 rule
...
ip -6 rule
ip -6 rule
ip -6 rule
ip -6 rule
ip -6 rule
ip -6 rule
61 - at this point this is the end of policy routing for freifunk related routes
add
add
add
add
add
add
from
from
from
from
from
from
all
all
all
all
all
all
iif
iif
iif
iif
iif
iif
ffrl-a-fra3-fra lookup mwu priority 7
ffrl-b-fra3-fra lookup mwu priority 7
ffrl-a-ak-ber lookup mwu priority 7
ffrl-b-ak-ber lookup mwu priority 7
ffrl-a-ix-dus lookup mwu priority 7
ffrl-b-ix-dus lookup mwu priority 7
add
add
add
add
add
add
add
add
from
from
from
from
from
from
from
from
all iif ffrl-a-fra3-fra lookup mwu priority 7
all iif ffrl-b-fra3-fra lookup mwu priority 7
all iif ffrl-a-ak-ber lookup mwu priority 7
all iif ffrl-b-ak-ber lookup mwu priority 7
all iif ffrl-a-ix-dus lookup mwu priority 7
all iif ffrl-b-ix-dus lookup mwu priority 7
2a03:2260:11a::/48 lookup mwu priority 7
2a03:2260:11b::/48 lookup mwu priority 7
add from 185.66.195.36/32 lookup ffinetexit priority 41
add from 2a03:2260:11a::/48 lookup ffinetexit priority 41
add from 2a03:2260:11b::/48 lookup ffinetexit priority 41
add
add
add
add
add
add
from
from
from
from
from
from
all
all
all
all
all
all
iif
iif
iif
iif
iif
iif
ffrl-a-fra3-fra type unreachable priority 61
ffrl-b-fra3-fra type unreachable priority 61
ffrl-a-ak-ber type unreachable priority 61
ffrl-b-ak-ber type unreachable priority 61
ffrl-a-ix-dus type unreachable priority 61
ffrl-b-ix-dus type unreachable priority 61
add from 2a03:2260:11a::/48 type unreachable priority 61
add from 2a03:2260:11b::/48 type unreachable priority 61
add
add
add
add
add
add
from
from
from
from
from
from
all
all
all
all
all
all
iif
iif
iif
iif
iif
iif
ffrl-a-fra3-fra type unreachable priority 61
ffrl-b-fra3-fra type unreachable priority 61
ffrl-a-ak-ber type unreachable priority 61
ffrl-b-ak-ber type unreachable priority 61
ffrl-a-ix-dus type unreachable priority 61
ffrl-b-ix-dus type unreachable priority 61
...
# static mainz routes for rt_table mwu
...
/sbin/ip -6 route add 2a03:2260:11a::/64 proto static dev mzBR table mwu
# static wiesbaden routes for rt_table mwu
...
/sbin/ip -6 route add 2a03:2260:11b::/64 proto static dev wiBR table mwu
Siehe auch:
• Routing Tabellen
• Policy Routing
42
Kapitel 3. Konfiguration
Freifunk MWU Gateway Doku, Release 0.1 beta
RAdvD
Damit die Clients im Netz auch in den Genuss von öffentlichem IPv6 kommen, müssen die Public IPv6-Prefixe
zusätzlich zu den ULA-Prefixes per Router Advertisements bekannt gegeben werden. Dazu ergänzt man die Public
IPv6-Prefixe in der /etc/radvd.conf:
interface mzBR
{
...
prefix 2a03:2260:11a::/64
{
AdvValidLifetime 864000;
AdvPreferredLifetime 172800;
};
...
};
interface wiBR
{
...
prefix 2a03:2260:11b::/64
{
AdvValidLifetime 864000;
AdvPreferredLifetime 172800;
};
...
};
Siehe auch:
• RAdvD
Spenden
Der Freifunk Rheinland e.V. muss seine Infrastruktur am Leben erhalten, ausbauen, defekte Teile tauschen etc. Das
kostet viel Geld. Liebe Communities, ihr habt bisher auch Ausgaben für die VPN Provider gehabt. Spendet an den
Freifunk Rheinland e.V., damit ein so großartiger Provider Bestand hat!
Wie ihr spenden könnt erfahrt ihr auf der Spenden-Seite des Freifunk Rheinlands.
3.10 Aufräumarbeiten
3.10.1 Lokaler DNS Resolver
Nach dem die Konfiguration von BIND abgeschlossen wird der DNS-Eintrag auf sich selbst gesetzt.
Dies kommt in die inet Section des Internet Interfaces, i.d.R. eth0.
Dadurch wird der Nameserver-Eintrag
/etc/resolv.conf geschrieben
3.10. Aufräumarbeiten
durch
resolvconf
beim
Hochkommen
des
Interfaces
nach
43
Freifunk MWU Gateway Doku, Release 0.1 beta
in die /etc/network/interfaces kommt also folgendes:
iface eth0 inet static
[...]
dns-nameservers 127.0.0.1
Als Fallback DNS Server tragen wir zusätzlich noch 2 weitere freie DNS Resolver ein. Dies erledigen wir über resolvconf. Wir legen die Datei /etc/resolvconf/resolv.conf.d/tail an und tragen die freien DNS Server
ein:
nameserver 213.73.91.35
nameserver 85.214.20.141
Siehe auch:
• BIND
3.10.2 Logging
Freifunk steht unter Anderem für Netzneutralität und ist in keinster Weise an irgendwelchen Nutzer-, Meta-, Irgendwasdaten interessiert. Aus diesem Grund muss den sonst so redseligen Linux Daemonen das Logging abgewöhnt
werden.
Hier wird beschrieben, wie man das für die jeweiligen Daemons erreicht.
Rsyslog
Wir legen uns auf eine Log Facility fest, deren Ziel ein schwarzes Loch ist.
• Black-Hole Log-Facility: local6
/etc/rsyslog.d/50-default.conf
Die folgende Zeile:
*.*;auth,authpriv.none
-/var/log/syslog
durch diese ersetzen:
*.*;auth,authpriv.none;local6.none
-/var/log/syslog
/etc/rsyslog.d/99-freifunk.conf:
local6.*
/dev/null
Nun kann jeder Daemon, der per default syslog für das Loggen benutzt angewiesen werden, die Log Facility local6
zu nutzen. Dadurch wird bewirkt, dass jegliche Infos im Nirvana landen.
DHCP Server
/etc/dhcpd/dhcpd.conf:
log-facility local6;
44
Kapitel 3. Konfiguration
Freifunk MWU Gateway Doku, Release 0.1 beta
radvd
Leider kann man dem radvd das Logging nur abgewöhnen, wenn man das Init-Script anpasst,
/etc/init.d/radvd:
OPTIONS="-m none -u radvd -p $PIDFILE"
Das -m none ist hier dazugekommen und deaktivert das Logging komplett.
fastd
/etc/fastd/xxVPN/fastd.conf:
log level warn;
hide ip addresses yes;
hide mac addresses yes;
BIND
/etc/bind/named.conf.logging:
logging {
channel null { null; };
category default { null; };
};
/etc/bind/named.conf:
...
include "/etc/bind/named.conf.logging";
Apache
ServerTokens in /etc/apache2/conf-available/security.conf weniger aussagekräftig einstellen und ServerSignature auf
EMail setzen:
ServerTokens Prod
ServerSignature EMail
Um Apache das Mitloggen der Zugriffe abzugewöhnen müssen in jeder aktivierten site die Log Direktiven auskommentiert werden:
#ErrorLog ${APACHE_LOG_DIR}/error.log
#CustomLog ${APACHE_LOG_DIR}/access.log combined
Des Weiteren existiert eine Standardkonfiguration, die automatisch für jede site das Logging aktiviert, diese muss
unbedingt deaktiviert werden:
sudo a2disconf other-vhosts-access-log.conf
sudo apachectl graceful
3.10. Aufräumarbeiten
45
Freifunk MWU Gateway Doku, Release 0.1 beta
46
Kapitel 3. Konfiguration
KAPITEL 4
Betrieb
4.1 Funktionstests
4.1.1 Dienste
Laufen alle Dienste?
BIND:
service bind9 status
* bind9 is running
DHCPd:
service isc-dhcp-server status
* isc-dhcp-server start/running, process 1337
fastd:
service fastd status
* fastd 'mzVPN' is running
* fastd 'wiVPN' is running
VPN Provider:
service openvpn status
* VPN 'mullvad' is running
BIRD:
service bird status
bird start/running, process 1337
service bird6 status
bird6 start/running, process 1337
RAdvD:
service radvd status
* radvd is running
NTP:
47
Freifunk MWU Gateway Doku, Release 0.1 beta
service ntp status
* NTP server is running
4.1.2 Interfaces
Sind die Netzwerk Interfaces in Ordnung?
Ein ip a sollte folgende Interfaces auflisten:
• lo
• eth0
• mzBR
• wiBR
• mzVPN
• wiVPN
• mzBAT
• wiBAT
• exitVPN
• icVPN
Für ein spezifisches Interface nutzt man ip a show dev wiBR, Für eine Range ip a show to
10.37.0.0/16 bzw. ip a show to fd56:b4dc:4b1e::/64.
Interessant ist in diesem Kontext ist auch ip a show scope global.
4.1.3 Routing
Siehe auch:
• Routing Tabellen
• Policy Routing
• Lokaler DNS Resolver
Die IP Rules?
ip rule
0:
7:
7:
7:
7:
23:
23:
41:
41:
61:
61:
61:
61:
61:
107:
48
from
from
from
from
from
from
from
from
from
from
from
from
from
from
from
all
all
all
all
all
all
all
all
all
all
all
all
all
all
all
lookup local
iif mzBR lookup mwu
iif wiBR lookup mwu
iif icVPN lookup mwu
iif exitVPN lookup mwu
iif mzBR lookup icvpn
iif wiBR lookup icvpn
iif mzBR lookup ffinetexit
iif wiBR lookup ffinetexit
iif mzBR unreachable
iif wiBR unreachable
iif exitVPN unreachable
iif icVPN unreachable
iif eth0 unreachable
lookup mwu
Kapitel 4. Betrieb
Freifunk MWU Gateway Doku, Release 0.1 beta
107:
32766:
32767:
from all lookup icvpn
from all lookup main
from all lookup default
ip -6 rule
0:
from
7:
from
7:
from
7:
from
7:
from
23:
from
23:
from
41:
from
41:
from
61:
from
61:
from
61:
from
61:
from
61:
from
107:
from
107:
from
32766: from
all
all
all
all
all
all
all
all
all
all
all
all
all
all
all
all
all
lookup local
iif mzBR lookup mwu
iif wiBR lookup mwu
iif icVPN lookup mwu
iif exitVPN lookup mwu
iif mzBR lookup icvpn
iif wiBR lookup icvpn
iif mzBR lookup ffinetexit
iif wiBR lookup ffinetexit
iif mzBR unreachable
iif wiBR unreachable
iif exitVPN unreachable
iif icVPN unreachable
iif eth0 unreachable
lookup mwu
lookup icvpn
lookup main
Die Routing-Tables?
ip route show table mwu
10.37.0.0/18 dev mzBR proto static scope link
10.56.0.0/18 dev wiBR proto static scope link
ip -6 route show table mwu
fd37:b4dc:4b1e::/64 dev mzBR proto static metric 1024
fd56:b4dc:4b1e::/64 dev wiBR proto static metric 1024
ip route show table ffinetexit
0.0.0.0/1 via 10.3.18.136 dev exitVPN src 10.3.18.136
unreachable default
10.3.18.136 dev exitVPN scope link src 10.3.18.136
128.0.0.0/1 via 10.3.18.136 dev exitVPN src 10.3.18.136
ip -6 route show table ffinetexit
unreachable default dev lo metric 1024 error -101
ip route show table icvpn
10.0.0.0/24 via 10.207.0.59 dev icVPN proto bird src 10.207.0.56
10.0.1.0/24 via 10.207.0.79 dev icVPN proto bird src 10.207.0.56
10.5.0.0/16 via 10.207.0.114 dev icVPN proto bird src 10.207.0.56
10.7.0.0/16 via 10.207.0.11 dev icVPN proto bird src 10.207.0.56
10.8.0.0/16 via 10.207.0.36 dev icVPN proto bird src 10.207.0.56
10.11.0.0/18 via 10.207.0.17 dev icVPN proto bird src 10.207.0.56
... u.v.m. ...
ip -6 route show table icvpn
2001:67c:2d50::/48 via fec0::a:cf:0:82 dev icVPN proto bird src fec0::a:cf:0:38 metric 1024
2001:bf7:20::/48 via fec0::a:cf:0:ba dev icVPN proto bird src fec0::a:cf:0:38 metric 1024
2001:bf7:380::/64 via fec0::a:cf:0:28 dev icVPN proto bird src fec0::a:cf:0:38 metric 1024
2001:bf7:380::/44 via fec0::a:cf:0:28 dev icVPN proto bird src fec0::a:cf:0:38 metric 1024
2001:bf7:540::/44 via fec0::a:cf:1:c4 dev icVPN proto bird src fec0::a:cf:0:38 metric 1024
2001:bf7:550::/44 via fec0::a:cf:1:c4 dev icVPN proto bird src fec0::a:cf:0:38 metric 1024
... u.v.m. ...
4.1. Funktionstests
49
Freifunk MWU Gateway Doku, Release 0.1 beta
4.1.4 B.A.T.M.A.N.
Siehe auch:
• Pakete
• fastd
Die momentan genutzte B.A.T.M.A.N.-Version ermittelt man mit:
modinfo -F version /lib/modules/$(uname -r)/updates/dkms/batman-adv.ko
2014.3.0
bzw mit:
batctl -v
batctl 2014.3.0 [batman-adv: 2014.3.0]
Gateway Status überprüfen:
batctl -m mzBAT gw
server (announced bw: 96.0/96.0 MBit)
batctl -m wiBAT gw
server (announced bw: 96.0/96.0 MBit)
Schauen, was die Kollegen so treiben:
batctl -m wiBAT gwl
Gateway
(#/255)
Nexthop [outgoingIF]: advertised uplink bandwidth ... [B.A.T.M.A.N
02:00:0a:38:00:05 (255) 02:00:0a:38:00:05 [
wiVPN]: 96.0/96.0 MBit
02:00:0a:38:00:07 (255) 02:00:0a:38:00:07 [
wiVPN]: 96.0/96.0 MBit
4.1.5 A.L.F.R.E.D.
Siehe auch:
• Pakete
• A.L.F.R.E.D.
Wie geht’s Alfred?
service alfred-wi status
alfred-wi start/running, process 1337
service alfred-mz status
alfred-mz start/running, process 1337
Sind Nodes online, die gluon-announce installiert und am laufen haben, sollte man json/gzip Daten erhalten:
alfred -r 158 -u /var/run/alfred-wi.sock
[...]
{ "xx:xx:xx:xx:xx:xx", "\xxx\xxx [...] \xxx\xxx" },
[...]
Ist alfred-json installiert kann man sich die Daten gleich mit entpacken lassen:
alfred -r 158 -s /var/run/alfred-wi.sock -z
[...]
{
"xx:xx:xx:xx:xx:xx": {
50
Kapitel 4. Betrieb
Freifunk MWU Gateway Doku, Release 0.1 beta
"location": {
"longitude": 0.0,
"latitude": 0.0
},
"network": {
"mac": "xx:xx:xx:xx:xx:xx",
[...]
},
[...]
},
[...]
}
[...]
Hier nervt: Zur Angabe des Sockets nutzt alfred-json den Flag -s, alfred hingegen -u.
batadv-vis -u /var/run/alfred-mz.sock -f jsondoc
{
"source_version" : "2014.4.0",
"algorithm" : 4,
"vis" : [
{ "primary" : "xx:xx:xx:xx:xx:xx",
"neighbors" : [
{ "router" : "xx:xx:xx:xx:xx:xx",
"neighbor" : "xx:xx:xx:xx:xx:yy",
"metric" : "1.0" },
{ "router" : "xx:xx:xx:xx:xx:xx",
"neighbor" : "xx:xx:xx:xx:yy:xx",
"metric" : "1.1" }
],
"clients" : [
"xx:xx:xx:xx:xx:xx",
"xx:xx:xx:xx:yy:yy"
]
},
[...]
}
4.2 Workflows
4.2.1 fastd-keys
Damit die Nodes eine VPN-Verbindung aufbauen können, muss der öffentliche fastd Schlüssel auf die Gateways
gelangen.
Wir verwalten diese Keys in Git-Repositories:
• Mainz: peers-ffmz.git
• Wiesbaden: peers-ffwi.git
Bei dem ersten Start der Gluon Node wird ein fastd Schlüsselpaar erzeugt.
Im Beschreibungstext steht, man solle den erzeugten öffentlichen Schlüssel per Mail an unsere Listen schicken. Alternativ lässt sich auch ein Link klicken, der das Email-Programm öffnet und eine neue Mail ausfüllt.
• Mainz: keys (at) freifunk-mainz.de
4.2. Workflows
51
Freifunk MWU Gateway Doku, Release 0.1 beta
• Wiesbaden: keys (at) freifunk-wiesbaden.de
Die Empfänger dieser Liste sind am Besten auch Mitglieder des fastd-keys GitHub Teams - Mitglieder dieser Gruppe
haben Schreibrechte auf die peers Repositories.
Die neuen Keys von der Liste werden wie unten gezeigt lokal eingetragen, die Änderungen wie gewohnt gepusht.
Bemerkung: Damit der Nodebesitzer und die anderen Empfänger der Keys-Listen bescheid wissen, muss nach dem
Eintragen der Keys die Mail beantwortet werden. Den Nodebesitzer ins To:-Feld, keys@freifunk-... ins CC:
(Oder einfach auf Reply-All klicken..).
Alle 15 Minuten kommt ein Script vorbei und synchronisiert die neuen Keys von GitHub auf die Gateways.
Siehe auch:
• fastd
• Backend Scripte
4.2.2 fastd-keys Format
Ein fastd-key ist ein 64-Zeichen langer HEX-String:
0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
Damit der fastd-daemon den Schlüssel lesen kann, muss noch etwas Syntax drum rum:
key "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef";
Bei Start oder Neuladen des fastd-daemons wird das Config-File neu eingelesen. In diesem steht, fastd möge zusätzlich noch alle Dateien aus dem peers-Ordner mit einlesen (== peers-... .git Repository).
fastd nimmt den Dateinamen des keys als peer name. Hat die Node z.B. den Namen Wurstsalat ist die Struktur denkbar
einfach:
• Dateiname: Wurstsalat:
key "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef";
Einige Dateinamen werden zur einfachen Zuordnung mit einem Prefix markiert. In Benutzung/Angedacht sind:
gw Für Gateways (gw_Lotuswurzel, gw_Spinat).
srv Für Dienste-Server (srv_Aubergine).
chaos Für Nodes im cccmz (chaos_Haggis).
peng Für Nodes im pengland.
4.2.3 exitVPN Accounts
Anfragen aus dem Freifunknetz in das Internet tunneln wir durch das exitVPN, um die Störerhaftung zu umgehen.
Dies hat den Vorteil, dass Anfragen in das Internet anonymisiert werden, Anbieter sehen nur dass die Anfrage aus dem
Freifunk-Netz kommt.
Hierbei handelt es sich um OpenVPN-Angebote, meist in Schweden oder Niederlande.
Diese werden im Vorraus gezahlt, und müssen von Hand aufgeladen werden.
Problem - Dies wird all zu gerne verpeilt!
52
Kapitel 4. Betrieb
Freifunk MWU Gateway Doku, Release 0.1 beta
Im gateway-configs.git findet sich eine exitvpn.yaml
Dort wird pro Gateway hinterlegt, welcher VPN-Account hinterlegt ist, und bis zu welchem Datum dieser bezahlt ist.
Einmal tägtlich kommt ein Script vorbei, und schreibt bei nähern des Datums Mails auf die admin@-Listen, ansonsten
wird ein mal pro Woche eine Übersicht verschickt.
Siehe auch:
• VPN Provider
• Backend Scripte
4.2.4 Firmware updates
Firmware updates müssen nach dem kompilieren noch signiert werden. So stellt Gluon die Integrität der Firmware
Dateien sicher. Dazu wird die manifest datei, die Teil jedes kompilierten Gluon releases ist mittels ecdsasign signiert.
Je nach Einstellungen in der site.conf und je nach build (experimental, beta, stable) sind eine verschiedene Anzahl von
signaturen nötig.
Ecdsa utils intallieren & Key generieren
Siehe hier: http://wiki.freifunk-flensburg.de/wiki/ECDSA_Util
Der öffentliche Schlüssel muss dann noch in die site.conf im imagebuilder eingetragen werden.
Firmware signieren
Man braucht den Inhalt aus der manifest Datei, vom Anfang bis zum Ende Der Dateinamen der Router (also bis zum
—–). Diesen speichert man ab und generiert die Signatur mit:
ecdsasign manifest < $private_keyfile
Die erhaltene Signatur fügt man jetzt unten an die manifest Datei an (unter dem —–) an.
4.3 Backend Scripte
Um sich das Leben einfacher zu machen, werden immer wiederkehrende Probleme mittels Scripte gelöst.
Diese werden in einem Repository gesammelt und nutzen selbst Photon als Backend.
Repository freifunk-mwu/backend-scripts
Backend Photon
4.3.1 Installation
Photon liegt im neuesten Release im Python Package Index und wird wiefolgt installiert:
sudo pip3 install -U photon_core --pre
Die eigentlichen Backend Scripte werden normal geklont:
mkdir -p ~/clones/backend-scripts
git clone https://github.com/freifunk-mwu/backend-scripts.git ~/clones/backend-scripts
4.3. Backend Scripte
53
Freifunk MWU Gateway Doku, Release 0.1 beta
4.3.2 Einrichten
Um den Backend Scripten (Schreib-) Zugriff auf die benötigten Repos unter GitHub zu gewähren müssen diese erst
eingerichtet werden. Dazu dient das Script bootstrap_git_all.py:
python3 ~/clones/backend-scripts/bootstrap_git_all.py
Dieses erzeugt ein SSH-Schlüsselpaar und legt es unter ~/.ssh/%hostname%_rsa ab sofern dieses noch nicht
existiert. Die ~/.ssh/config wird um einen Eintrag erweitert (sofern dieser noch nicht existiert), so dass ein
Zugriff auf GitHub mittels frisch erzeugtem Schlüssel möglich ist.
Momentan: github_mwu
Den Öffentlichen Teil des Schlüssels bekommt ein extra erstellter GitHub Account hinterlegt, der duch eine Gruppen
Zugriff auf die entsprechenden Repos erhält.
Für uns ist dies der Nutzer freifunkmwu der innerhalb der Gruppe machines verweilt.
Ob alles korrekt funktioniert lässt sich durch einen einfachen Aufruf zeigen:
ssh github_mwu
Die Ausgabe sollte folgendes enthalten:
Hi freifunkmwu! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.
Die restlichen Scripte sind in der Readme des Repos beschrieben.
4.3.3 Cronjobs
Damit verschiedene Datenquellen atuell bleiben, sind eine ganze Reihe von Cronjobs notwendig. Die outputs werden
im Fehlerfall auch direkt auf die admin@ liste geleitet. Zunächst ruft man seinen Crontab editor auf:
crontab -e
Da ein Teil der neu installieren binaries unter /home/admin/ liegen, müssen wir den Pfad setzen:
PATH=/home/admin/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
Jede Minute annouced das gateway per Alfred seine Daten:
# alfred announce
* * * * * $HOME/clones/ffnord-alfred-announce/announce.sh -i mzBR -b mzBAT -f mzVPN -u /var/run/alfre
* * * * * $HOME/clones/ffnord-alfred-announce/announce.sh -i wiBR -b wiBAT -f wiVPN -u /var/run/alfre
Die aktuellste Firmware wird dreimal pro Tag vom Buildserver geholt:
# firmware sync
23 */8 * * * /usr/bin/rsync -avh --delete rsync://pudding.freifunk-mwu.de:2873/firmware /var/www/html
Die Backend Scripte werden ebenfalls aufgerufen:
# backend scripts
*/5 * * * * /usr/bin/python3 $HOME/clones/backend-scripts/draw_traffic_all.py > $HOME/.cronlog/draw_t
*/5 * * * * /usr/bin/python3 $HOME/clones/backend-scripts/check_bind_gw.py > $HOME/.cronlog/check_bin
*/5 * * * * /usr/bin/python3 $HOME/clones/backend-scripts/check_exitvpn_gw.py > $HOME/.cronlog/check_
*/5 * * * * /usr/bin/python3 $HOME/clones/backend-scripts/check_radvd_gw.py > $HOME/.cronlog/check_ra
23 * * * * /usr/bin/python3 $HOME/clones/backend-scripts/gen_website_all.py > $HOME/.cronlog/gen_webs
*/15 * * * * /usr/bin/python3 $HOME/clones/backend-scripts/sync_meshkeys_gw.py > $HOME/.cronlog/sync_
54
Kapitel 4. Betrieb
Freifunk MWU Gateway Doku, Release 0.1 beta
23 5,23 * * * /usr/bin/python3 $HOME/clones/backend-scripts/snapshot_configs_all.py > $HOME/.cronlog/
42 19 * * 2 /usr/local/bin/photon-dangerous-selfupgrade.py --sudo --repos $HOME/clones/backend-script
Die Logs der Cronjobs werden im admin Homeverzeichnis unter .cronlog (versteckt) abgelegt. Damit das funktioniert,
müssen wir es anlegen:
mkdir
$HOME/.cronlog
Als letztes müssen noch die ICVPN Daten aktuell gehalten werden:
#
0
0
0
icvpn
3 * *
4 * *
5 * *
prototypes
U /usr/bin/python3 $HOME/clones/backend-scripts/update_tinc_conf_gw.py > $HOME/.cronlog/updat
U /usr/bin/python3 $HOME/clones/backend-scripts/update_bird_conf_gw.py > $HOME/.cronlog/updat
U /usr/bin/python3 $HOME/clones/backend-scripts/update_bind_conf_gw.py > $HOME/.cronlog/updat
Dabei sollte darauf geachtet werden, dass U so gewählt wird, dass diese sich möglichst nicht mit den Tagen der anderen Gateways überlappen. Bei Änderungen der Anzahl der Gateways können hier Verschiebungen auf allen Gateways
nötig werden; U kann (und wird) mehr als einen Tag enthalten, an jedem Tag sollte auf einem Gateway das Update laufen. Sollte sich dort eine Fehlkonfiguration einschleichen, so werden auf diese Weise nicht alle ICVPN Verbindungen
gleichzeitig disfunktional.
Bemerkung: Um das oben genannte zu erreichen hier eine Übersicht der momentanen Konfiguration.
Wir müssen verhindern, dass wir uns durch ein fehlerhaftes Update gleichzeitig alle Gateways zersägen, zumindest
sollte dies zeitversetzt geschehen.
Weiterhin sollte der Zugriff auf die Git Repos auch nicht gleichzeitig stattfinden um Merge-Conflicts vorsorglich zu
verhindern.
Nächste Schritte:
• Nur Scripte nach oben gennanten Kriterien in der Tabelle auflisten
• Schema ausknobeln, wie man (z.B. anhand der Gateway-Nummer) eindeutige Zeitpunkte festlegen kann:
– Wochentag, Stunde, Minute
• Schema auf die Tabelle anwenden
• Cronjobs auf den Gateways anpassen
• ???
• Profit!
4.3. Backend Scripte
55
Freifunk MWU Gateway Doku, Release 0.1 beta
Script/Gate
Kaschu
alfred
announce
firmare sync
draw traffic
check bind
check
exitvpn
check radvd
gen website
sync
meshkeys
snapshot
configs
selfupgrade
* * * * *
update tinc
conf
update bird
conf
update bind
conf
alfred to
zone
ffmap-d3
Spinat
Wasserfloh
Aubergine
x
*/5 * * * *
23 * * * *
*/15 * * * *
x
23 5,23
* * *
42 19 *
* 2
0 3 * *
3,6
0 4 * *
3,6
0 5 * *
3,6
x
x
x
cleanup
node states
mirror
openwrt
repo
nagg
exitvpn
accouts
autobuild
gluon
x
x
x
x
Pudding
Linse
x
23 */8 * * *
*/5 * * * *
*/5 * * * *
*/5 * * * *
meshviewer
56
Lotuswurzel
42 5,23
* * *
42 17 *
* 2
0 3 * *
3,6,7
0 4 * *
3,6,7
0 5 * *
3,6,7
x
x
x
x
x
23 5,23
* * *
42 19 *
* 2
0 3 * *
2,5
0 4 * *
2,5
0 5 * *
2,5
23 5,23
* * *
42 19 *
* 2
0 3 * *
2,5
0 4 * *
2,5
0 5 * *
2,5
42 5,23
* * *
42 17 *
* 2
x
42 5,23
* * *
42 17 *
* 2
42 5,23
* * *
42 17 *
* 2
x
0 5 * *
0,1,5
*/15 *
* * *
* * * *
*
* * * *
*
*/15 *
* * *
19 1 *
* * *
x
23 19 *
* *
23 17 *
* *
x
#42 5 *
* 0,4
x
x
x
x
x
x
Kapitel 4. Betrieb
KAPITEL 5
Mitwirken
Du hast eine Stelle entdeckt, die Schreibfehler enthält, was unsauber oder falsch erklärt, nicht existiert aber sollte, oder
veraltet ist?
Gerne nehmen wir sinnvolle Vorschläge und Ergänzungen mit auf, über den Issue-Tracker (mit dem Label ‘Doku’)
oder am besten gleich per Pull Request.
57

Infoblatt Technik - Zum Harzer Jodlermeister

Mit Ihrer Unterstützung Verbindungen herstellen

Freifunk VDS Flyer (Shared)

WLAN VOR ORT - Bündnis 90/Die Grünen im Landtag NRW

eine/n engagierte/n Verlagsmitarbeiter/in / technische/r

Einladungsflyer Earth Hour EBE 2016

Freifunk Flyer - Freifunk Obernkirchen

Wlan WFB.cdr - Grüne Kaiserslautern

Freifunk in Köln/Bonn Ein Überblick

17/5260 - Niedersächsischer Landtag