Version vom 15. April 2019, 23:04 Uhr

Preface

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

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

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

Referenzen / Andere Freifunk HowTo's

Voraussetzungen

Was der Betreiber mitbringen sollte

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

Was der Server können muss

Öffentliche IPv4 und IPv6 Adresse
Kernelmodule laden (Bestimmte Virtualisierungslösungen wie OpenVZ sind daher nicht möglich)
Nur relativ wenig CPU und RAM nötig
dafür relativ viel Traffic (Je nach Größe und Anzahl der Hoods durchaus im ein- bis niedrigen zweistelligen TB Bereich)

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

Anbindung an andere Netze

Neben unserem eigenen Freifunknetz gibt es weitere Netzwerke mit denen sich ein peering lohnt:

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

DN42
- BGP
- Experimentelles Darknet zur Erprobung von Routing-Technologien und so weiter, wird privat betrieben. Viel interessantes Zeugs™

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

Server-Anbieter

Empfehlenswert

Der kleinste Hetzner Cloud Server kann derzeit empfohlen werden. Rechenleistung ist ausreichend und der Traffic ist angemessen.

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

Nicht empfehlenswert

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

Installation

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

Empfohlenes Betriebssystem: Debian
Sicherheit
- SSH Login nur mit Keys, Login per Passwort abschalten (siehe hier
- root-Login per SSH höchstens per Key, besser abschalten
- Hier bekommst du weitere Tipps zur Absicherung eines Debian Servers

Vorbereitung

IP-Adressen und DHCP Range des Gateway

Um Doppelbelegungen zu vermeiden, müssen diese auch im Wiki eingetragen werden.

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

Private FFF IPs

Für jede Hood reserviert man sich einen IPv4 bzw. IPv6 Adressbereich, mit welchem die Knoten und Clients versorgt werden.

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

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

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

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

Peering-IPs

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

Bei IPv6 genügen die Link-Local Adressen.

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

OS Settings

IP-Forwarding

Per default leitet Debian keine Pakete weiter, die unser Gateway erreichen. Deswegen muss IP-Forwarding aktiviert werden. :

Manuell: echo "1" > /proc/sys/net/ipv4/ip_forward

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

echo "1" > /proc/sys/net/ipv6/conf/all/forwarding echo 1 > /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr -> Sonst landen ICMP-Fehlerpakete auf eth0 - mit source-IP 10.50.x.y... https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

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

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


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

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

und dahinter einfügen:

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

Routing Tabelle für Freifunk

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

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

10     fff

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

Die Konfiguration wird exemplarisch für das Einrichten eines GW's in der Fürther Hood beschrieben, wobei erläutert wird, welche Anpassungen für nicht-Fürther Hoods gemacht werden müssen.

Layer 3

Layer 3 Tunnelprotokolle

Für Babel ist eine direkte Verbindung mit dem Nachbar nötig (Ethernet, WiFi, ..). Wenn keine direkte Verbindung besteht, kann mithilfe eines Layer 3 Tunnels eine direkte Verbindung durch ein bestehendes Netzwerk (z.B. das Internet) hergestellt werden.

GRE

GRE benötigt auf beiden Seiten eine feste IP-Adressen und kann daher nicht sinnvoll hinter einem NAT betrieben werden. Es wird daher meist zwischen Servern in Rechenzentren eingesetzt. Der Traffic ist nicht verschlüsselt und das Protokoll hat wenig Overhead. Daher ist es sehr schnell. https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/gre

wireguard

Wireguard benötigt nur auf einer Seite eine feste IP Adresse. Die "Clientseite" darf hinter einem NAT stecken und es muss auch keine feste IP Adresse verwendet werden. Es wird daher meist hinter DSL/Kabelanschlüssen verwendet um sich zu einem Server im Rechenzentrum zu verbinden. Der Traffic wird verschlüsselt, wofür etwas Rechenleistung benötigt wird. https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/wireguard

Babel Routingprotokoll

Zwischen den Layer3-Routern wird das wird das IP-Routingprotokoll Babel verwendet.

Babel tauscht die erreichbaren IP-Bereiche zwischen den Gateways aus, sodass jedes Gateway weiß über welchen Weg es andere Subnetze erreichen kann. https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/Babel

Wohin mit dem Traffic?

Es gibt drei Wege den Traffic ins Internet zu leiten:

Direkt am eigenen Server ins Internet ausleiten
Über Layerg-Peering an ein FFF-Exit-Gateway weiterleiten
Über einen VPN Anbieter

Über Babel an ein FFF-Exit-Gateway

IPv4

Hier muss nichts weiter getan werden. Babel kümmert sich um die default Route in der 'fff' Routing-Tabelle.

Hierbei ist es notwendig einen Nachbarn zu haben, der Ressourcen übrig hat um den Traffic zu übernehmen. Hier findet ihr Peering-Partner.

IPv6

Falls man an seinem Gateway öffentlich erreichbare IPv6 Adressen verteilen möchte (hier gibt es welche: https://wiki.freifunk-franken.de/w/Portal:Layer3Peering#sonstiges ) , hängt man an jede Hood ein /64 Netz an.

In Babel config einfügen:

[...]
redistribute local ip 2001:DB8:aaaa:bbbb::/64 </br>
redistribute ip 2001:DB8:aaaa:bbbb::/64
[...]

Hier kann auch ein /48 Bereich eingefügt werden. Es handelt sich hier nur um Filterregeln. Alles was innerhalb das hier eingetragenen Subnetzes als "proto static" in die Routingtabelle eintragen wird, wird Babel weiter announcen (damit die entsprechenden BorderGateways wissen wohin sie den Traffic schicken sollen)

An batX anhängen:

[...]
# Public IPv6
post-up ip -6 addr add 2001:DB8:aaaa:bbbb::1/64 dev batX 
post-up ip -6 route add 2001:DB8:aaaa:bbbb::/64 dev $IFACE proto static tab fff </br>
[...]

Zuerst wird eine einzelne Adresse des /64 Netzes an das bat Interface gehangen. Anschließend wird für dieses Subnetz eine Route mit "proto static" angelegt, damit Babel die Route auch weiter announced. Gleichzeitig wird die route dafür verwendet, den Traffic für das Subnetz auch auf das Interface zu routen.

Und im radvd:

[...]
        MinRtrAdvInterval 60;
        MaxRtrAdvInterval 300;
        AdvDefaultLifetime 600;
[...]
        prefix 2001:DB8:aaaa:bbbb::/64 {
                AdvOnLink on;
                AdvAutonomous on;
                };
[...]

Wichtig ist, AdvDefaultLifetime darf jetzt nicht mehr 0 sein. Damit wird den Clients nun mitgeteilt das es hier eine default route gibt. Anschließend muss nur noch das prefix mit angegeben werden.

Traffic direkt am Server ins Internet ausleiten

Bevor ihr "fremden" Traffic direkt ausleitet, solltet ihr euch unbedingt über die rechtlichen Konsequenzen informieren und euch mit eurem Provider oder Serververmieter in Verbindung setzen.

IPv4

Hier muss die default route aus der main table mit proto static in die fff table kopiert werden:

christiand@fff-neptun:~$ ip ro sh | grep def
default via 84.ab.xy.z dev ens3

Diese einfach auch in die fff table eintragen:

ip r replace default via 84.ab.xy.z dev ens3 proto static tab fff

Anschließend muss noch ein NAT drauf da man viele priv. IPs über eine externe routet:

iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE

Will man diese default route auch ins Babelnetz announcen, muss der Filter angepasst werden

redistribute ip 0.0.0.0/0

IPv6

(Achtung ungetestet!)

Hier wird ein freies /64 Netz für jede Hood benötigt. Das vorgehen ähnelt im Prinzip sehr den fd43 Adressen nur das im radvd eine Default Route mitgegeben wird. Natürlich muss dafür gesorgt werden, dass das Subnetz ins Internet kann bzw. aus dem Internet erreichbar ist.

Folgendes muss getan werden:

Aus dem Subnetz muss eine einzelne IP an das bat Interface:

[...]
post-up ip -6 addr add 2001:DB8:aaaa:bbbb::1/64 dev $IFACE
[...]

Eine Route muss in die fff Tabelle:

[...]
post-up ip -6 route replace 2001:DB8:aaaa:bbbb::1/64 dev $IFACE proto static table fff
[...]

Im radvd muss eine default route announced werden dazu AdvDefaultLifetime nicht auf 0 setzen sondern erhöhen (z.b. 600). Weiterhin muss das Subnetz auch announced werden in /etc/radvd.conf:

[...]
        prefix 2001:DB8:aaaa:bbbb::/64 {
                AdvOnLink on;
                AdvAutonomous on;
        };

[...]

VPN-Tunnel zu Anonymisierungsdienst

Nicht zu empfehlen, sollte nur im Notfall verwendet werden wenn keine andere Option vorhanden ist!

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

Layer 2

Batman-adv

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

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

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

VPN für die Knoten

Es kann mit dem keyxchangev2 nun jedes VPN Protokoll einzeln verwendet werden. Fastd ist absofort nicht mehr verpflichtend es kann ein reines l2tp Gateway betrieben werden. Derzeit wird aber empfohlen (nur) fastd zu verwenden, weil l2tp auf dem Server instabil sein kann. l2tp hat als größten Vorteil die niedrigere CPU-Last und damit größeren Durchsatz v.a. auf den Routern, fastd hat als größten Vorteil neben der Stabilität die einfachere Konfiguration und bessere Verständlichkeit.

Dienste

ntp Server

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

http Server für Hoodfile

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

Alfred Master aufsetzen (Monitoring)

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

gwinfo (optional, Gateway-Daten für Monitoring)

https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/gwinfo (optional)

DNS Server

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

DHCP Server

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

radvd

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

Einbringen des Gateways in die Hood / Keyserver

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

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

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

Optimierungen

ARP Cache
nf_conntrack

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

Fehlersuche

Was so alles in einem Layer 2 Netz passieren kann

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

Port Sperren

Es empfiehlt sich folgende Ports / IPs zu sperren

Ausgehend:

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

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

-> Nur nötig wenn Traffic direkt ins Internet geleitet wird!

Einzelne IPs oder Services über anderen Server routen

wird fast nie benötigt, war für mich aber immer ein schönes Nachschlagewerk deshalb lass ich das ganz unten stehen:

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

@@ Zeile 257: / Zeile 257: @@
 Bevor ihr "fremden" Traffic direkt ausleitet, solltet ihr euch unbedingt über die rechtlichen Konsequenzen informieren und euch mit eurem Provider oder Serververmieter in Verbindung setzen.
-'''IPv4'''
+===== IPv4 =====
 Hier muss die default route aus der main table mit proto static in die fff table kopiert werden:
@@ Zeile 283: / Zeile 283: @@
 </pre>
-''' IPv6 '''
+===== IPv6 =====
 (Achtung ungetestet!)
@@ Zeile 293: / Zeile 293: @@
 <pre>
 [...]
-post-up ip -6 addr add 2aaa:xxxx:yyyy:z::1/64 dev $IFACE
+post-up ip -6 addr add 2001:DB8:aaaa:bbbb::1/64 dev $IFACE
 [...]
 </pre>
@@ Zeile 299: / Zeile 299: @@
 <pre>
 [...]
-post-up ip -6 route replace 2aaa:xxxx:yyyy:z::1/64 dev $IFACE proto static table fff
+post-up ip -6 route replace 2001:DB8:aaaa:bbbb::1/64 dev $IFACE proto static table fff
 [...]
 </pre>
@@ Zeile 305: / Zeile 305: @@
 <pre>
 [...]
-         prefix 2aaa:xxxx:yyyy:z::/64 {
+         prefix 2001:DB8:aaaa:bbbb::/64 {
                  AdvOnLink on;
                  AdvAutonomous on;

Freifunk-Gateway aufsetzen: Unterschied zwischen den Versionen

Version vom 15. April 2019, 23:04 Uhr

Preface

Voraussetzungen

Was der Betreiber mitbringen sollte

Was der Server können muss

Anbindung an andere Netze

Server-Anbieter

Empfehlenswert

Nicht empfehlenswert

Installation

Vorbereitung

IP-Adressen und DHCP Range des Gateway

Private FFF IPs

Peering-IPs

OS Settings

IP-Forwarding

Routing Tabelle für Freifunk

Layer 3

Layer 3 Tunnelprotokolle

GRE

wireguard

Babel Routingprotokoll

Wohin mit dem Traffic?

Über Babel an ein FFF-Exit-Gateway

IPv4

IPv6

Traffic direkt am Server ins Internet ausleiten

IPv4

IPv6

VPN-Tunnel zu Anonymisierungsdienst

Layer 2

Batman-adv

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

VPN für die Knoten

fastd

l2tp mit Tunneldigger

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

Dienste

ntp Server

http Server für Hoodfile

Alfred Master aufsetzen (Monitoring)

gwinfo (optional, Gateway-Daten für Monitoring)

DNS Server

DHCP Server

radvd

Einbringen des Gateways in die Hood / Keyserver

Optimierungen

Fehlersuche

Port Sperren

Einzelne IPs oder Services über anderen Server routen