Freifunk-Gateway aufsetzen
Achtung: Die Seite wird aktuell für den KeyxchangeV2 umgebaut. Daher könnte sie zeitweise Inkonsistenzen enthalten und wird sich inhaltlich stark verändern. Den letzten V1-Stand gibt es hier |
Preface
Für das Aufsetzen eines Freifunk-Gateway gibt es kein universelles Kochrezept. Auch erfahrene Admins erfahren bei der Installation kleinere und grössere Herausforderungen, die es zu überwinden gilt. Unterschiedliche Softwareinstallationen, Netzwerkkonfigurationen, Hoster und VPN Anbieter können Anpassungen zu der hier präsentierten Vorgehensweise notwendig werden lassen, z.B. indem Pakete nach installiert werden oder Netzwerkkonfigurationen angepasst werden müssen. Um dies zu erleichtern, versucht der Artikel nicht nur die Konfiguration darzulegen, die in diesem spezifischen Fall funktioniert hat ("Know-How"), sondern versucht auch kurz auf die Hintergründe einzugehen, um ggf. eine Anpassung zu erleichern ("Know-Why").
Freifunk Franken ist "Development in Progress", d.h. eine Konfiguration die heute funktioniert, wird morgen durch eine andere und vielleicht sogar bessere abgelöst. Ein einmal aufgesetztes Gateway muss sich so der Entwicklung anpassen.
Für Rat und Tat empfiehlt sich die Freifunk Franken Development und die Freifunk Franken Gateway Mailingliste.
Zum den Änderungen vom KeyxchangeV1 zum KeyxchangeV2 Gateway geht's hier: https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/keyxchangev2
Referenzen / Andere Freifunk HowTo's
- http://wiki.freifunk.net/Freifunk_Hamburg/Gateway
- http://wiki.mag.lab.sh/wiki/Freifunk_Fulda/Gateway
Voraussetzungen
Was der Server können muss
- Öffentliche IPv4 und IPv6 Adresse
- Kernelmodule laden
- Nur relativ wenig CPU und RAM nötig
- dafür relativ viel Traffic (Je nach Größe und Anzahl der Hoods durchaus im ein- bis niedrigen zweistelligen TB Bereich)
Was der Betreiber mitbringen sollte
- Grundlegende Kenntnisse mit IP-Routing (IPv4 und IPv6)
- Motivation, etwas [jede Menge] dazuzulernen und sich aktiv mit der Materie auseinanderzusetzen.
- Das Freifunk Netz ist der optimale Ort, um sich in dieser Richtung neue Kenntnisse anzueignen - zumindest wenn man sich dann auch damit (und. v.a. mit den auftretenden Problemen) auseinandersetzt.
- Es gibt viele nette Leute im IRC, die immer gerne helfen, wenn die Motivation da ist, sich auch selbst mit dem Problem zu befassen.
- Für die schnelle Abstimmung unter den GW Betreibern sollte sich jeder Betreiber auf der freifunk-gateway Mailingliste setzen. Die "große" Liste und die dev-Liste sind ebenfalls hilfreich.
- Ohne Vorkenntnisse ist es schwierig aber ganz und gar nicht unmöglich ein Gateway aufzusetzen. Soweit es nicht bei dem Kenntnisstand bleiben soll, wird auch hier gerne geholfen.
- Bereitschaft mitzuhelfen, das Wiki aktuell zu halten, damit die Ressourcenplanung (IPs!) funktioniert und für Notfälle die wichtigsten Infos und Ansprechpartner zu den Servern vorhanden sind. Die wichtigsten Seiten sind Server, Portal:Netz und Portal:Netz/IPv6.
- Ein wenig Zeit - sowohl fürs Aneignen des Verständnisses als auch fürs Aufsetzen an sich. Gehe erstmal von ganz grob 5-20 Stunden Arbeitszeit aus, um von einem "nackten" Server zu einem voll funktionstüchtigen GW zu kommen, der ja doch aus recht vielen verschiedenen Diensten besteht. Nach der Ersteinrichtung sollte man regelmäßig ein wenig Zeit investieren, um zu schauen, ob alles in Ordnung ist, Updates zu fahren, Änderungen in der Infrastruktur nachzupflegen etc.
Was das Gateway können muss
- fastd VPN
- Batman (Compat15)
- DHCP
- Router Advertisements
- Routing
- Babel Routing Protokoll
- Webserver für Hoodfiles
Näheres ist unter Dienste beschrieben.
Anonymisierung (Störerhaftung)
Sofern der Server nicht über einen Uplink verfügt, wo es egal ist was durchgeht (unseriöse Bulletproof-Hoster), möchte man vermutlich den Traffic aus dem Freifunk-Netz durch ein VPN ins Internet schieben.
Auf längere Sicht, wäre es natürlich wünschenswert, wenn die Problematik der Störerhaftung in ihrer derzeitigen Form wegfällt um beispielsweise eine dezentralere Infrastruktur zu erlauben.
Folgende VPN-Anbieter sind zu diesem Zeitpunkt jedoch empfehlenswert:
- Mullvad (Schweden, Niederlande)
- Bis zu drei gleichzeitige Verbindungen
- Kann man anonym mit Bitcoin bezahlen
- Serverauswahl über die ausgelieferte OpenVPN-Konfiguration
- Server in den Niederlanden sind abends oft stark ausgelastet
- (Gute Erfahrungen in Lübeck)
- Integrity VPN (Schweden, Port80)
- Drittes Oktett durch Auswahl des normalerweise per round.robin-dns ausgewählten OpenVPN-Servers bestimmbar, das letzte Oktett ist immer gleich. Somit muss man sich keine dynamisch vergebenen IP-Adressen mit anderen teilen. Verbindungen daher durch die Anzahl der OpenVPN-Server (derzeit 3; unterschiedliche Ports nicht ausprobiert) beschränkt.
- Hat eine überaus seriöse Webseite und eine Ltd. erfunden.™
- Hat schon mal was von IPv6 gehört. Nutzt es zurzeit jedoch nur für SEO.
- Blockiert Port 25 derzeit nicht.
- Ist ein ein neuer Anbieter, der _bisher_ unausgelastet wirkt.
- sind derzeit noch nicht nicht overselled und haben ihren Krams scheinbar halbwegs sauber konfiguriert
- Ipredator (Schweden, Niederlande, Deutschland)
- (Glänzen nicht durch Kompetenz, da sie lange Zeit nur PPTP angeboten haben)
- Mögen schnelle Reconnects nicht -> manchmal muss man OpenVPN ein paar Stunden deaktivieren, bevor es wieder funktioniert.
- Möchten bald auch IPv6 anbieten.
- Angeblich Reseller von relakks
- Cyberghost
- blockt alle SMTP Ports!!
- Perfect Privacy
- AzireVPN
Ungetestet:
- Anonine VPN (Portlane)
- privacy.io (Portlane)
- prq.se (Eigenes Netz, teuer)
- Arethusa VPN (Loggen in Frankreich, andere Server angeblich nicht)
Anbindung an andere Netze
Es gibt drei relativ relevante Netzwerke bei denen es sich lohnt, das lokale Netz damit zu verbinden:
- InterCity-VPN zwischen den meisten Freifunknetzen
- BGP
- kleine Übsicht der http://www.ddmesh.de/topology/ic-vpn-verbindungen.html
- Mehr Infos http://wiki.freifunk.net/IC-VPN
- DN42
- BGP
- Experimentelles Darknet zur Erprobung von Routing-Technologien und so weiter, wird privat betrieben. Viel interessantes Zeugs™
- Hat Routen ins ChaosVPN und IC-VPN,
wer faul ist bei der Konfiguration deckt damit also alles™ab nicht alle Routen vom IC-VPN oder ChaosVPN werden im DN42 verteilt, ob man das will kann ggf nochmal besprechen.
- ChaosVPN
- Tinc
- Relativ großes „Darknet“ zwischen vielen Hackerspaces auf der ganzen Welt.
Server-Anbieter die empfehlenswert sind
- de-punkt (Databurg, FFM)
- Schneller Speicher, gut bezahlbar, KVM, nur Traffic-Flat™® das übliche.
- Hetzner (Falkenstein)
- Bezahlbarer Extratraffic 1,19 €/TB, KVM
- colorhost (über 23media, Global Switch, FFM)
- Untersagt Nutzung für Freifunk (http://colorhost.de/server/vserver/kvm/small/)
- Achtung: Nur Xen oder Xen HVM funktionieren
- xirra (Core-Backbone, NBG)
- KVM, TB-Traffic zu 5,95€. Langweilig und funktioniert. Pflegt bisher einen guten Kontakt zu Kunden.
- BuyVM
- Begrenztes Angebot, das in Stößen rausgegeben wird. 2.50$/TB Extratraffic. Nur KVM ist brauchbar für diesen Zweck. USA Ost- und Südküste. TOS sagt, dass man da theoretisch kein weiteres VPN ins Netz brauchen würde.
- webhod
- 9,99 € für die kleinste KVM im Monat[1]
Server-Anbieter die nicht empfehlenswert sind
- WRZhost
- Aktivierung des V-Servers erst auf mehrfache Nachfrage, anschließend falsches Betriebssystem. Außerdem nur OpenVZ und somit nicht für FreiFunk nutzbar. Für andere Zwecke sicher brauchbar, da gut angebunden und offshore.
Grundinstallation des Servers
Die Installation des Betriebssystems, Absicherung des Servers, Installieren von Updates usw. sind NICHT Gegenstand dieser Anleitung. Trotzdem kurz einige Hinweise.
Folgendes sollte unbedingt beachtet werden
- Betriebssystem aktuell halten. Bei Linux wird dafür für gewöhnlich eine Paketverwaltung verwendet
- Bei Debian ist das apt
- apt update aktualisiert die Paketquellen
- apt upgrade aktualisiert die Pakete
- Sicherheit
IP-Forwarding
Um Anfragen, die das Gateway erreichen, weiterzuleiten, muss IP-Forwarding aktiviert werden.
Manuell geht dies über:
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv6/conf/default/forwarding
echo "1" > /proc/sys/net/ipv6/conf/all/forwarding
- Sonst landen ICMP-Fehlerpakete auf eth0 - mit source-IP 10.50.x.y...
- https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
echo 1 > /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr
Dauerhaft lässt sich IP-Forwarding in /etc/sysctl.conf aktivieren:
vi /etc/sysctl.conf
.. um dort die Abschnitte einzukommentieren, die das Forwarding steuern:
. . . # Uncomment the next line to enable packet forwarding for IPv4 net.ipv4.ip_forward=1 # Uncomment the next line to enable packet forwarding for IPv6 # Enabling this option disables Stateless Address Autoconfiguration # based on Router Advertisements for this host net.ipv6.conf.all.forwarding=1 . . .
Um ICMP-Fehlerpakete auf eth0 zu vermeiden, die als src-IP 10.50.x.y haben (böseböse!) dann noch
# Sonst landen ICMP-Fehlerpakete auf eth0 - mit source-IP 10.50.x.y... # https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt net.ipv4.icmp_errors_use_inbound_ifaddr = 1
einfügen
Routing Tabelle für Freifunk
Für die Routen im Freifunk Franken Netz sollte eine eigene Routingtabelle deklariert werden.
Dazu Tabellennummer und Name in /etc/iproute2/rt_tables eintragen:
10 fff
Der Inhalt der Routingtabelle kann später mit
ip route show table fff
angezeigt werden.
Konfigurieren des Freifunk-Gateways
Nachdem nun die erforderlichen Softwarepakete auf dem Gateway installiert wurden, kann man das Gateway als solches einrichten. Die Konfiguration wird exemplarisch für das Einrichten eines GW's in der Fürther Hood beschrieben, wobei erläutert wird, welche Anpassungen für nicht-Fürther Hoods gemacht werden müssen.
IPv4 des Gateways, IP-Bereich der Hood und DHCP Range des Gateway
Das Gateway benötigt eine IP aus jedem verbundenen Layer-2 Netz.
Für jede Hoods sucht man sich dafür unter Portal:Netz bzw. Portal:Netz/IPv6 eine IPv4 bzw. IPv6 Adresse (bei IPv4 aus dem statischen Bereich) der Hood aus.
Damit es keine Doppelbelegungen gibt, muss diese auch gleich "reserviert" werden, indem das Wiki entsprechend editiert wird.
Für die Peerings verwenden wir Adressen aus einem speziell dafür vorgesehenen Bereich.
Die Adressen werden mit einer /32 Netzmaske an die Peering-Interfaces gehängt, um die entsprechenden Routen kümmert sich dann babel. So spart man sich ein paar IPv4 Adressen, da nicht immer ein /31 Subnetz für ein Peering drauf geht und (wenn auch unsauber) für jedes Peeringinterface die gleiche Adresse genutzt werden kann.
Bei IPv6 genügen die Link-Local Adressen.
Möchte man auf seinem Gateway Dienste unabhängig von den Hoods anbieten, kann dafür die Peering-IP (für IPv6 ist daher ebenfalls ein Bereich dafür vorgesehen) gut verwendet werden.
An dieser Stelle sollte man sich unbedingt mit Subnetzen und der CIDR-Notation vertraut machen, falls einem das (noch) Fremdworte sind.
Ein entsprechender IP-Rechner findet sich z.B. hier.
Für die Hoods muss bei IPv4 noch ein Bereich festgelegt werden, aus dem dann später Adressen verteilt werden. Dieser muss:
- innerhalb des Subnetzes der Hood liegen.
- innerhalb der Hood eindeutig sein. (Darf sich nicht mit dem Adressbereich überschneiden, den andere DHCP Server in der Hood verwalten)
- vollständig außerhalb des statischen Bereichs der Hood liegen.
Gleichzeitig teilt der DHCP-Server den Clients mit, welchen DNS-Server und welches Default-Gateway die Clients verwenden sollen. Die Gesamtgröße aller verwalteten DHCP-Bereiche des Servers hat so direkten Einfluss auf die Arbeitslast, die der den Clients zugeteilte DNS-Server und der zugeteilte Internet-Gateway später sehen.
Bei IPv6 wird nur Gateway, DNS-Server und Subnetz per Router Advertisement in der Hood bekannt gemacht, den Rest erledigen die Clients.
Batman-adv
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/Batman-adv
VPN für die Knoten
fastd
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/VPN/fastd
l2tp mit Tunneldigger
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/VPN/l2tp
B.A.T.M.A.N Netzwerk-Interface, fff Routingregeln und -tabelle
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/interface
radvd
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/radvd
ntp Server
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/ntp
http Server für Hoodfile
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/http
Alfred Master aufsetzen
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/Alfred
OpenVPN-Tunnel einrichten
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/VPN-Exit
DNS Server
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/DNS
B.A.T.M.A.N Gateway Selection
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/Batman-Gatewayselection
DHCP Server
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/DHCP
Babel
https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/Babel Hier wird auch erklärt wie man Gateways z.b. über GRE verbindet
Testen von B.A.T.M.A.N, fastd und Autostart
Danach sollte der Aufruf von...
pgrep fastd
... mit der Prozess-ID beantwortet werden: Fastd läuft in dem Fall.
Ein Aufruf von ifconfig:
ifconfig
sollte die neu erstellten Interfaces bat0 und ffffuerthVPN zurückliefern. Exemplarisch und als Auszug:
bat0 Link encap:Ethernet HWaddr ea:95:50:07:f7:27 inet addr:10.50.32.5 Bcast:0.0.0.0 Mask:255.255.248.0 inet6 addr: fe80::e895:50ff:fe07:f727/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1089992 errors:0 dropped:0 overruns:0 frame:0 TX packets:849698 errors:0 dropped:1728 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:141311612 (134.7 MiB) TX bytes:1052934594 (1004.1 MiB) . . . ffffuerthVPN Link encap:Ethernet HWaddr e6:3b:f3:b7:fc:db inet6 addr: fe80::e43b:f3ff:feb7:fcdb/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1426 Metric:1 RX packets:32389694 errors:0 dropped:0 overruns:0 frame:0 TX packets:2699525 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:4193328694 (3.9 GiB) TX bytes:1384843740 (1.2 GiB) . . .
Aus dem ifconfig Auszug für bat0 sollte die eingerichtete IP des Gateways und die Netzmaske hervorgehen. + IPv6
Die Abfrage der IP-Regeln:
ip rule
sollte die oben definierten Regeln wieder spiegeln (fff Tabelle für Traffic, der entweder über bat0 oder 10.0.0.0/8 rein- oder rausgeht):
32757: from all to 10.0.0.0/8 lookup fff 32758: from 10.0.0.0/8 lookup fff 32759: from all iif bat0 lookup fff
Eine Abfrage der fff-Routing Tabelle
ip route show table fff
sollte die B.A.T.M.A.N Route (Device bat0) in das Netzwerk der eingerichtete Hood ergeben. In diesem Beispiel ist es die Fürther Hood:
10.50.32.0/21 dev bat0 scope link
ganze IPv6 Zeug fehlt noch
Ein Aufruf von "batctl o"
batctl o
ergibt eine Liste der MAC-Adressen von unseren nächsten Nachbarn. Exemplarisch und als Auszug:
[B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: ffffuerthVPN/e6:3b:f3:b7:fc:db (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... 96:43:c4:2e:73:68 0.004s (255) 96:43:c4:2e:73:68 [ffffuerthVPN]: 96:43:c4:2e:73:68 (255) . . .
Auf neues Batman updaten (Versionsanzeiger)
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
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
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