Freifunk-Gateway aufsetzen: Unterschied zwischen den Versionen

Aus Freifunk Franken
Wechseln zu:Navigation, Suche
K (Seite gibt es nicht mehr)
 
(728 dazwischenliegende Versionen von 27 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
__TOC__
__TOC__
[[Kategorie:Technik]]
= 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 erreichen ("Know-Why").


= TODO =
Die Anleitung dient dazu, den Einstig zu erleichtern.</br>
* Bitte kein Wheezy mehr verwenden. Das ist oldstable, wird bald nicht mehr von Debian supported.
Viele der Dinge können später auf die eigenen Bedürfnisse angepasst und zugeschnitten werden.
* Batman-Adv aus Jessie ist zu neu. Hier muss manuell das alte gebaut werden
** aptitude install build-essential linux-headers-amd64
** clone https://github.com/freifunk-gluon/batman-adv-legacy
** make
* batctl ist auch zu neu
** wget http://downloads.open-mesh.org/batman/releases/batman-adv-2013.4.0/batctl-2013.4.0.tar.gz
** make
* fastdstart in ein git legen und verlinken
* nameserver installation
* tunnel to other gws
* olsr config


== Preface ==
Die Anleitung hat keine Garantie auf Vollständigkeit und wird stetig verändert und verbessert.</br>
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").
Wenn du beim Installieren auf Probleme oder Fehler stößt: Der nächste freut sich, wenn er auf diesen Fehler nicht mehr stößt oder eine entsprechende Anmerkung im Wiki findet. :-)


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


Für Rat und Tat empfiehlt sich die Freifunk Franken Development Mailingliste.
Für Rat und Tat empfiehlt sich die Freifunk Franken Development und die Freifunk Franken Gateway Mailingliste.
 
== Vorraussetzungen ==
* ssh-Zugang zum Server
* Root Zugriff auf den Server. Entweder man ist "root" (Annahme in diesem Artikel) oder man kann Befehle mit "root-Rechten" durch ein vorgesetztes "sudo" ausführen.
* Grundlegende Netzwerkkenntnisse
** IPv4 und Netzmaske
** Devices
** Routing (Default route, Interfaces, Routing-Table)
* Kentnisse
** im Umgang mit Texteditoren (der im Artikel verwendete Editor kann durch beliebig andere ersetzt werden, z.B. durch "nano")
** im Umgang mit der Linux Shell (z.B. Kommandozeilenparameter, Shell-Scripte, Umleitungen)
** in der (Selbständige Nach-)Installation von (fehlenden) Software-Paketen
** im Kompilieren von Software-Quellen


== Referenzen / Andere Freifunk HowTo's ==
'''Referenzen / Andere Freifunk HowTo's'''
* [http://wiki.freifunk.net/Freifunk_Hamburg/Gateway Gateway FF-Hamburg]


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


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


Hardware:
=== Was der Betreiber mitbringen sollte ===
* CPU: 1x (64Bit)
* Grundlegende Kenntnisse mit IP-Routing (IPv4 und IPv6)
* RAM: 256MB .. 1GB
* Motivation, etwas ''[jede Menge]'' dazuzulernen und sich aktiv mit der Materie auseinanderzusetzen.
* HDD: > 5 GB
* 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.
* NIC: 1x
* Es gibt viele nette Leute im [[Kommunikation | 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 [[Mailinglisten#freifunk-gateway| freifunk-gateway]] Mailingliste setzen. Die "große" [[Mailinglisten#franken-freifunk| Liste]] und die [[Mailinglisten#freifunk-dev| dev-Liste]] sind ebenfalls hilfreich.
* Ohne Vorkenntnisse ist es schwierig, aber ganz und gar nicht unmöglich ein Gateway aufzusetzen. Auch hier gilt wieder: Es wird gerne geholfen, wenn man sich mit Problemen einigermaßen selbstständig auseinandersetzt und konkrete Fragen stellt.
* 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, das 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.


Software:
=== Was der Server können muss ===
* Debian Jessie (8) 64Bit Kernel
* Öffentliche IPv4 und IPv6 Adresse
* fastd v17
** Leider aktuell noch zu viele IPv4 Anschlüsse, um IPv4 außen vor zu lassen. :-(
* openvpn
** IPv6 ist pflicht.
* B.A.T.M.A.N. adv 2013.4.0
* Kernelmodule laden (Bestimmte Virtualisierungslösungen wie OpenVZ sind daher nicht möglich)
* dhcpd
* Nur relativ wenig CPU und RAM nötig
* olsr
* dafür relativ viel Traffic (Je nach Größe und Anzahl der Hoods durchaus im ein- bis niedrigen zweistelligen TB Bereich)
* bind9


Pauschal gibt es keine Mindestanforderungen für den Trafficverbrauch, folgende Staffelung könnte aber dabei helfen, sich eine Vorstellung davon zu machen, was in etwa pro Monat notwendig ist:
* Dauerlast von 2 Mbit/s: ~633 GB
* Dauerlast von 6 Mbit/s: ~1.9 TB
* Dauerlast von 10 Mbit/s: ~3.2 TB
* Dauerlast von 25 Mbit/s: ~8 TB


Nach den Erfahrungen vom Lübecker Freifunk-Projekt liegt der Traffic-Verbrauch bei zwei Gateways bei ca. 2TB im Monat je Gateway. Auf unserem derzeitigen Gateway haben wir in den letzten Monaten derartige Werte gehabt, wobei sich das Projekt noch aufbaut:
* fastd VPN
* Januar '13: 243 GB
* Batman ''(Compat15)''
* Februar '13: 309 GB
* DHCP
* Router Advertisements
* Routing
* Babel Routing Protokoll
* Webserver für Hoodfiles


=== Anonymisierung (Störerhaftung) ===
== Anbindung an andere Netze ==
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.
Neben unserem eigenen Freifunknetz gibt es weitere Netzwerke mit denen sich ein Peering lohnt:
 
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:
 
* [https://mullvad.net/en/ 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)
 
* [https://integrityvpn.com/ 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
 
* [https://ipredator.se/ Ipredator] (Schweden, Niederlande, Deutschland)
** (Glänzen nicht durch Kompetenz, da sie lange Zeit nur PPTP angeboten haben)
** Mögen schnelle Reconnects nicht -> manchmal muss man OpenVPN ein paar Stunden deaktivieren, bevor es wieder funktioniert.
** Möchten bald auch IPv6 anbieten.
** Angeblich Reseller von relakks
 
Ungetestet:
* [https://www.anonine.com/en Anonine VPN] (Portlane)
* [https://privacy.io/ privacy.io] (Portlane)
* [http://prq.se/?p=tunnel&intl=1 prq.se] (Eigenes Netz, teuer)
* [http://arethusa.su/vpn.html Arethusa VPN] (Loggen in Frankreich, andere Server angeblich nicht)
 
Einige Freifunknetze mieten auch VMs in Osteuropa. Da die VMs noch nicht an ihre Grezen stößt könnte man diese auch mitnutzen. Ansprechpartner wäre s0ma.
 
=== Anbindung an andere Netze ===
Es gibt drei relativ relevante Netzwerke bei denen es sich lohnt, das lokale Netz damit zu  verbinden:


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


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


* ChaosVPN
* ChaosVPN
** Tinc
** Tinc
** Relativ großes „Darknet“ zwischen vielen Hackerspaces auf der ganzen Welt.
** Relativ großes „Darknet“ zwischen vielen Hackerspaces auf der ganzen Welt.
<br>


=== vServer-Anbieter die empfehlenswert sind ===
== Server-Anbieter==
* [https://www.de-punkt.de/vserver.html de-punkt] (Databurg, FFM)
** Schneller Speicher, gut bezahlbar, KVM, nur Traffic-Flat™® das übliche.
* [http://www.hetzner.de/hosting/produktmatrix_vserver/vserver-produktmatrix Hetzner] (Falkenstein)
** Bezahlbar, 6.90€/TB Extratraffic, KVM
* [http://colorhost.de/server/vserver/ 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
* [http://www.xirra.net/en/v-server/productmatrix/ xirra] (Core-Backbone, NBG)
** KVM, TB-Traffic zu 5,95€. Langweilig und funktioniert. Pflegt bisher einen guten Kontakt zu Kunden.
* [http://buyvm.net/ 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.
* [http://webhod.de webhod]
** 9,99 € für die kleinste KVM im Monat[https://www.webhod.de/de/vserver/kvm.html]


=== Hoster, bei denen gute Erfahrungen gemacht wurden ===
Diese unvollständige, nicht abschließende Liste von Hostern dient nur der Orientierung.
Solange ein Hoster die weiter oben genannten Voraussetzungen erfüllt, ist er für ein Freifunk Gateway geeignet.


== Grundinstallation des Servers ==
Umso mehr verschiedene Hoster im Freifunknetz, umso besser.
Vom ausgesuchten Hoster lassen wir uns eine aktuelle Linux-Distribution installieren oder ausliefern, wobei sich die Anleitung auf ein Debian 8 / Jessie bezieht.


* [https://www.hetzner.de/hosting/produktmatrix_vserver/vserver-produktmatrix Hetzner] (Nürnberg, Falkenstein, Helsinki)
** Cloud Server, 20TB Traffic 2,96€/Monat
** Wird bedingt des vielen verfügbaren Traffics fürs Geld sehr viel genutzt
** Hetzner-interner Traffic wird nicht berechnet


=== Repositories und Update ===
* [https://www.xirra.net/en/v-server/productmatrix/ xirra] (Core-Backbone, NBG)
Als erstes bringen wir das System auf den neuesten Stand...
** KVM, TB-Traffic zu 5,95€. Langweilig und funktioniert. Pflegt bisher einen guten Kontakt zu Kunden.
 
<code>
vi /etc/apt/sources.list
</code>
 
...und schauen nach, inwieweit auf die gleichen Software-Repositories verwiesen wird:
 
<pre>
deb http://security.debian.org/ jessie/updates main
deb-src http://security.debian.org/ jessie/updates main


deb http://ftp.de.debian.org/debian/ jessie main contrib non-free
* [https://www.netcup.de/ netcup]
deb-src http://ftp.de.debian.org/debian/ jessie main contrib non-free


deb http://ftp.de.debian.org/debian/ jessie-updates main
= Installation =
deb-src http://ftp.de.debian.org/debian/ jessie-updates main
Die Installation des Betriebssystems, Absicherung des Servers, Installieren von Updates usw. sind '''NICHT''' Gegenstand dieser Anleitung. Trotzdem kurz einige Hinweise:


</pre>
* Empfohlenes Betriebssystem: Debian
** Die Anleitung basiert aktuell auf '''Debian 10 (Buster)'''. Für Einsteiger wird dringend empfohlen mit dieser Version anzufangen.
* Sicherheit
** [https://www.thomas-krenn.com/de/wiki/OpenSSH_Public_Key_Authentifizierung_unter_Ubuntu SSH Login nur mit Keys, Login per Passwort abschalten]
** root-Login per SSH höchstens per Key, besser abschalten
** Hier bekommst du weitere Tipps zur [http://www.thomas-krenn.com/de/wiki/Absicherung_eines_Debian_Servers Absicherung eines Debian Servers]


Danach speichern und das System auf einen aktuellen Stand bringen:
== Vorbereitung ==
=== IP-Adressen und DHCP Range des Gateway ===


<code>
Um Doppelbelegungen zu vermeiden, müssen diese auch im Wiki eingetragen werden.
apt-get update


apt-get upgrade
An dieser Stelle sollte man sich unbedingt mit Subnetzen und der [[CIDR|CIDR-Notation]] vertraut machen, falls einem das (noch) Fremdworte sind.<br>
</code>


=== Sicherheit ===
==== Private FFF IPs ====
Den SSH-Zugang besser schützen durch:
Für jede Hood reserviert man sich einen [[Portal:Netz|IPv4]] bzw. [[Portal:Netz/IPv6|IPv6]] Adressbereich, mit welchem die Knoten und Clients versorgt werden.
* Änderung des Ports
* login nur mit key
* Siehe [http://www.thomas-krenn.com/de/wiki/Absicherung_eines_Debian_Servers hier] für genaue Anleitung:


<code>
Für die Hoods muss bei IPv4 noch ein Bereich festgelegt werden, aus dem dann später Adressen verteilt werden. Dieser muss:
apt-get install fail2ban
* innerhalb des Subnetzes der Hood liegen.
</code>
* 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.


und [http://www.thomas-krenn.com/de/wiki/SSH_Login_unter_Debian_mit_fail2ban_absichern einrichten]
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.


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


=== B.A.T.M.A.N. adv 2013.4.0 Kernel-Modul ===
==== Peering-IPs ====
Batman-Adv aus Jessie ist zu neu. Hier muss manuell das alte B.A.T.M.A.N. advanced 2013.4.0 gebaut werden.
Für die Peerings verwenden wir Adressen aus einem speziell dafür vorgesehenen [[Portal:Netz#10.83.252.0.2F22_.28Master_IPs_for_use_as_.2F32_routed_IPs_withing_L3_network.29|Bereich]].<br>
Die Adressen werden mit einer /32 Netzmaske an die Peering-Interfaces gehängt, um die entsprechenden Routen kümmert sich dann babel. <br>
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.<br>


Hierfür benötigen wir minimal die Paketquellen build-essential linux-headers-amd64, und git:
Bei IPv6 genügen die Link-Local Adressen.


<code>
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 [[Portal:Netz/IPv6#Transfer-IPs|Bereich]] dafür vorgesehen) gut verwendet werden.
aptitude install build-essential linux-headers-amd64


aptitude install git
==== Öffentliche Adressen ====
</code>
Damit das Internet erreicht werden kann, sind öffentliche IP Adressen nötig, die im Internet bekannt sind.


Die Softwarequellen müssen heruntergeladen...
Diese können von verschiedenen Freifunkern bezogen werden, siehe [[IPv6]]
<code>
cd ~


git clone https://github.com/freifunk-gluon/batman-adv-legacy
=== OS Settings ===
==== IP-Forwarding ====
Per default leitet Debian keine Pakete weiter, die unser Gateway erreichen. Deswegen muss IP-Forwarding aktiviert werden.


cd batman-adv-legacy
Manuell (nur bis zum reboot aktiv):
</code>
 
... und kompiliert und installiert werden:
 
<code>
make
 
make install
</code>
 
Hinweis: Sollten noch Paketquellen fehlen, wird dies während des Kompilierens gemeldet. Die Software-Quellen müssen nachinstalliert werden und der letzte  Kompilierungs- und Installationsschritt so lange wiederholt werden, bis die Software erfolgreich erstellt wurde.
 
Nach erfolgreicher Erstellung kann das B.A.T.M.A.N Kernel Modul per modprobe händisch eingebunden werden:
 
<code>
modprobe batman-adv
</code>
 
Es sollte dann im Kernel-log ....
<code>
dmesg | grep batman-adv
</code>
 
... mit einem Eintrag gelistet werden:
<pre>
<pre>
  batman_adv: B.A.T.M.A.N. advanced 2013.4.0 (compatibility version 14) loaded
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv6/conf/all/forwarding
</pre>
</pre>


Das Kernelmodul von B.A.T.M.A.N. kann dann bei jedem Neustart des Systems geladen werden, indem in die Datei /etc/modules:


<code>
sysctl Einstellungen können in der Datei '''/etc/sysctl.conf''' dauerhaft eingestellt werden.
vi /etc/modules
</code>
 
..der Eintrag "batman-adv" hinzugefügt wird:


Dort gibt es für das Forwarding bereits die passenden Zeilen, die nur einkommentiert werden müssen:
<pre>
<pre>
batman-adv
</pre>


=== B.A.T.M.A.N adv 2013.4.0 batctl ===
# Uncomment the next line to enable packet forwarding for IPv4
Gleiches gilt für batctl, ein Kommandozeilenprogramm zur B.A.T.M.A.N Konfiguration. Die alte Version 2013.4.0 muss selber gebaut werden, da die Debian 8 / Jessie Paketquellen zu neu sind.
net.ipv4.ip_forward=1


Herunterladen und Entpacken der Softwarequellen:
# Uncomment the next line to enable packet forwarding for IPv6
<code>
#  Enabling this option disables Stateless Address Autoconfiguration
cd ~
#  based on Router Advertisements for this host
net.ipv6.conf.all.forwarding=1


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


cd batctl-2013.4.0.tar.gz
==== ICMP Fehlerpakete für IPv4 ====
</code>
Damit ICMP hinter unserem NAT korrekt funktioniert, müssen die ICMP Fehler passend geroutet werden, dass sie beim NAT-Server landen. Das kann in Linux mit der Option "net.ipv4.icmp_errors_use_inbound_ifaddr = 1" erreicht werden.
 
Kompilieren und Installieren:
 
<code>
make
 
make install
</code>
 
Hinweis: Auch hier müssen ggf. fehlende Quellen händisch nachinstalliert und das Kompilieren und Installieren bis zum Erfolg wiederholt werden.
 
=== FastD ===
Die Verbindung zwischen Gateway und Router wird über einen fastd-Tunnel realisiert.
 
Hierfür müssen wir ein neues Repository in der Datei /etc/apt/sources.list deklarieren:
 
<code>
vi /etc/apt/sources.list
</code>
 
Dort fügen wir folgendes Repository an:


Analog zu oben sollte diese Einstellung in sysctl.conf eingetragen werden, damit sie rebootfest ist:
<pre>
<pre>
deb http://repo.universe-factory.net/debian/ sid main
net.ipv4.icmp_errors_use_inbound_ifaddr = 1
deb-src http://repo.universe-factory.net/debian/ sid main
</pre>
</pre>


Außerdem landen dann keine ICMP Pakete mit internen Adressen als Absender auf dem Uplink [dem Hoster].


Danach die PGP Schlüssel holen:
Siehe auch [[MTU]]
<code>
gpg --keyserver hkp://pool.sks-keyservers.net --recv-key 16EF3F64CB201D9C


gpg -a --export 16EF3F64CB201D9C | apt-key add -
==== Routing Tabelle für Freifunk ====
</code>
Für die Routen im Freifunk Franken Netz muss eine eigene Routingtabelle angelegt werden.


Datenbankupdate der Paketverwaltung:
Damit die Tabelle auch mit Name aufrufbar ist, sollten Tabellennummer und Name in /etc/iproute2/rt_tables eingetragen werden:
<code>
apt-get update
</code>
 
Installation von fastd:
<code>
apt-get install fastd
</code>
 
=== Bind9 ===
Als DNS Server nehmen wir hier den de-facto-Standard bind:
<code>
apt-get install bind9
</code>
 
 
=== OLSR ===
Als Routing-Protokoll, um die einzelnen Hoods später zu einem Freifunk-Franken weit kommunizierenden Netz zu verbinden, wird OLSR installiert:
<code>
apt-get install olsrd
</code>
 
=== Neustart ===
Nach Abschluss der Softwareinstallation empfiehlt sich ein Neustart des Gateways:
 
<code>
reboot & exit
</code>
 
== Konfigurieren des Freifunk-Gateways ==
Nachdem nun die erforderlichen Softwarepakete auf dem Gateway installiert wurden, kann man das Gateway als solches einrichten. Die Konfiguration wird exemplarisch für das Einrichten eines GW's in der Fürther Hood beschrieben, wobei erläutert wird, welche Anpassungen für nicht-Fürther Hoods gemacht werden müssen. 
 
 
=== IPv4 des Gateways, IP-Bereich der Hood und DHCP Range des Gateway===
Für das Gateway suchen wir uns unter [[Portal:Netz]] eine IPv4 Adresse aus dem statischen Range der Hood aus. Für Fürth läuft der Bereich für die statischen Adressen z.B. von 10.50.32.1 - 10.50.32.255. Hiervon suchen wir uns eine '''freie''' Adresse aus, und reservieren diese, indem wir sie weiter unten in die Tabelle der statischen IPs eintragen. So sind z.Zt.  10.50.32.1 (ro1.freifunk-franken.de) bis 10.50.32.5 (klee) reserviert. Die nächste freie IPv4 in der Fürther Hood wäre (im Moment) 10.50.32.6, die als IP für ein neues Gateway reserviert werden könnte.
 
Die Fürther Hood hat den IP-Bereich 10.50.32.0-10.50.32.255. Als Netzwerk wird dieser Bereich mit 10.50.32.0/21 deklariert, d.h. die ersten 21 Bit der IP identifizieren das Netzwerk "Fürther Hood" und die restlichen 11 Bit stehen zur IP Vergabe zur Verfügung, wobei Anfang (10.50.32.0) und Ende des Bereiches (10.50.39.255) reserviert sind und nicht, weder statisch noch dynamisch durch DHCP, belegt werden dürfen. Eine alternative Schreibweise zu 10.50.32.0/21 ist das Double "Network 10.50.32.0" und "Netmask  255.255.248.0". Ein entsprechender IP-Rechner zur analogen Anwendung in anderen Hoods findet sich z.B. [http://www.heise.de/netze/tools/netzwerkrechner/ hier].
 
Ebenso sollte man einen DHCP-Bereich innerhalb des IP-Bereichs der jeweiligen Hood, die der GW bedienen soll, reservieren (d.h. in die oberer Tabelle unter [[Portal:Netz]] eintragen). Jeder DHCP-Server vergibt dynamisch IPv4 Adressen an Clients aus einem vorher definierten Adressbereich. Dieser Adressbereich sollte sich:
* innerhalb des IP-Range der Hood bewegen
* sich nicht mit dem Adressbereich überschneiden, den andere DHCP Server in der Hood verwalten
* sich nicht mit dem Bereich der statischen Adressen der Hood überschneiden
Gleichzeitig teilt der DHCP-Server den Clients mit, welchen DNS-Server und welches Default-Gateway die Clients verwenden sollen. Die Gesamtgröße aller verwalteten DHCP-Bereiche des Servers hat so direkten Einfluss auf die Arbeitslast, die der den Clients zugeteilte DNS-Server und der zugeteilte Internet-Gateway später sehen. Vom gesamten IP-Bereich der Fürther Hood vergibt z.B. das Gateway fff-nue1 die Teilmenge 10.50.35.0 - 10.50.36.255 an Clients und teilt ihnen auf dem Weg auch gleich mit, wie sie Domain-Namen in IPs auflösen und auf welchem Weg sie ins Internet oder in andere Hoods kommen.
 
=== Routing Tabelle für Freifunk ===
Fürs Routing im Freifunk Franken Netz wird eine eigene Routing Tabelle namens "fff" deklariert.
 
Dies geschieht indem man in der Datei /etc/iproute2/rt_tables ...
<code>
vi /etc/iproute2/rt_tables
</code>
 
... folgendes am Ende einfügt:


<pre>
<pre>
Zeile 349: Zeile 173:
</pre>
</pre>


Unsere Freifunk Routing Tabelle lässt sich später durch
Der Inhalt der Routingtabelle kann später mit
<code>
<pre>
ip route show table fff
ip route show table fff
</code>
bzw.
anzeigen, sobald wir die Tabelle mit Einträgen füllen.
ip -6 route show tab fff
</pre>
angezeigt werden.
<br>


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


=== B.A.T.M.A.N Netzwerk-Interface, fff Routingregeln und -tabelle ===
== Layer-3 ==
=== Generelle Layer-3 Routing Regeln ===
Damit Pakete vom Gateway selbst passend in das Freifunk Netz geroutet werden, sind einige Regeln nötig.


In der Datei /etc/network/interfaces ...
Diese können an die Debian Interfacekonfiguration des Loopback Interfaces hinzugefügt werden, damit sind sie direkt nach dem Boot des Servers verfügbar.


<code>
'''prio''' legt fest, in welcher Reihenfolge die Regeln abgearbeitet werden.
vi /etc/network/interfaces
Hier sollte sich zunächst an die im Wiki vorgegebene Reihenfolge gehalten werden, später kann man diese auf die eigenen Bedürfnisse anpassen.
</code>


fügen wir zunächst folgenden Textblock des Gateways "klee" aus der Fürther Hood an:
Außerdem können auch FFF-interne IP Adressen (10.x.x.x, fd43:5602:29bd:ffff::xx) an das Loopback Interface gehängt werden.


<pre>
<pre>
# device: bat0
iface lo inet static
auto bat0
address 10.83.252.x/32
iface bat0 inet manual
post-up ifconfig $IFACE up
    ##Einschalten post-up:
    # IP des Gateways am B.A.T.M.A.N interface:
    post-up ip addr add 10.50.32.5/21 dev $IFACE
    # Regeln, wann die fff Routing-Tabelle benutzt werden soll:
    post-up ip rule add iif $IFACE table fff
    post-up ip rule add from 10.0.0.0/8 table fff
    post-up ip rule add to 10.0.0.0/8  table fff
    # Route in die Fuerther Hood:
    post-up ip route add 10.50.32.0/21 dev $IFACE table fff
    # Start des DHCP Servers:
    post-up invoke-rc.d isc-dhcp-server restart


    ##Einschalten post-down:
up ip -4 rule add to 10.0.0.0/8 prio 500 lookup fff
    # Loeschen von oben definieren Routen, Regeln und Interface:
down ip -4 rule del to 10.0.0.0/8 prio 500 lookup fff
    post-down ip route del 10.50.32.0/21 dev $IFACE table fff
    post-down ip rule del from 10.0.0.8/8 table fff
    post-down ip rule del to 10.0.0.0/8 table fff
    post-down ip rule del iif $IFACE table fff
    post-down ifconfig $IFACE down


# VPN Verbindung in die Fuerther Hood
        #DN42
auto ffffuerthVPN
up ip -4 rule add to 172.20.0.0/14 prio 500 lookup fff
iface ffffuerthVPN inet manual
down ip -4 rule del to 172.20.0.0/14 prio 500 lookup fff
    post-up batctl -m bat0 if add $IFACE
    post-up ifconfig $IFACE up
    post-up ifup bat0
    post-down ifdown bat0
    post-down ifconfig $IFACE down
</pre>


In diesem Beispiel sind:
iface lo inet6 static
* IP des Gateway/Netzmaske der Fürther Hood: 10.50.32.5/21
address fd43:5602:29bd:ffff::xx/128
* IP des Netzwerks Fürther Hood / Netzmaske der Fürther Hood: 10.50.32.0/21.
Diese müssen gegen die oben reservierte IP des Gateways/Netzmaske der Hood und gegen die Netzwerk-IP/Netzmaske der Hood, in die das neue Gateway soll, ausgetauscht werden.


Der Eintrag "ip route add 10.50.32.0/21 dev $IFACE table fff" fügt in der fff Routingtabelle eine Route in das Netzwerk "Fürther Hood" ein. Für Hassberge müsste dieser Eintrag z.B. in 10.50.56.0/22 geändert und für die IP-Adresse des Gateways eine aus dem statischen Bereich der Hassberger Hood reserviert und verwendet werden (Siehe [[Portal]]).
up ip -6 rule add to fc00::/7 prio 500 lookup fff
down ip -6 rule del to fc00::/7 prio 500 lookup fff
</pre>


Die Regeln definieren, das Traffic der
Für Pakete die auf Interfaces, welche für Freifunk verwendet werden (z.b. Clientnetz oder alle Babelverbindungen), ankommen muss auch expliziet in die fff table geguckt werden, dies muss für IPv4 und IPv6 gesetzt werden und sollte sinnvollerweise direkt an das entsprechende Interface geschrieben werden. Diese Regeln sollten eine möglich hohe Priorität haben (niedrige Zahl) damit Transit auf jeden Fall immer funktioniert.
* aus dem Netzwerk 10.0.0.0/8 kommt
* das Netzwerk 10.0.0.0/8 zum Ziel hat
* oder über die B.A.T.M.A.N Schnittstelle übermittelt wird
von der fff Routingtabelle behandelt werden. Die Einträge sind so allgemein formuliert, dass sie für das gesamte Freifunk Franken Netz Gültigkeit haben sollten.


Im post-down Abschnitt werden die vorher definierten Regeln, Interfaces und Routen wieder gelöscht.
Der untere Abschnitt definiert einen VPN Tunnel in die Fürther Hood. Der Name des Interfaces im Beispiel (ffffuerthVPN) kann individuell neu vergeben werden.
=== FastD Start- und Verwaltungsscript ===
Für die Konfigurstion von fastd erstelen wir eine Datei in ''/etc/fastd'' mit dem Befehl:
<code>
touch fff_beispiel_fastd.sh
</code>
danach öffnen wir diese:
<code>
vi /etc/fastd/fff_beispiel_fastd.sh
</code>
und fügen folgendes [https://www.hidrive.strato.com/lnk/QVCVp477 Skript] ein:
<pre>
<pre>
#!/bin/sh
[...]
up ip -6 rule add iif $IFACE prio 200 table fff
up ip rule add iif $IFACE prio 200 table fff
[...]
</pre>


SERVER="yes"
=== Layer-3 Tunnelprotokolle ===
SERVERNAME="beispiel"
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.


hood="hood eintragen"
==== GRE ====
project="fff"
GRE benötigt an beiden Enden eine feste IP-Adresse, da die Konfiguration komplett statisch ist.
port=10004
Außerdem unterstützen viele NATs GRE nicht, ggf. muss bei IPv4 eine passende Portweiterleitung angelegt werden.


SERVERNAME="$SERVERNAME.$hood"
Dafür ist es ein sehr einfaches Protokoll, leicht zu debuggen, sehr leightgewichtig und dadurch extrem schnell.


hostname=$SERVERNAME
Es wird daher meist zwischen Servern in Rechenzentren eingesetzt. Der Traffic ist nicht verschlüsselt.


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


if [ ! -d /etc/fastd/$project.$hood ]
==== wireguard ====
then
Wireguard benötigt nur an einem Ende eine feste IP Adresse. Außerdem kann es leicht hinter NAT betrieben werden, da UDP verwendet wird.
        mkdir /etc/fastd/$project.$hood
        mkdir /etc/fastd/$project.$hood/peers


        echo "# Log warnings and errors to stderr" >> /etc/fastd/$project.$hood/$project.$hood.conf
Dafür ist das Protokoll etwas komplizierter (und verschlüsselt) und dadurch auch etwas langsamer.
        echo "log level error;" >> /etc/fastd/$project.$hood/$project.$hood.conf
Dennoch lassen sich je nach Hardware einige hundert MBit/s erreichen.
        echo "# Log everything to a log file" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "log to syslog as \"${project}${hood}\" level info;" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "# Set the interface name" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "interface \"${project}${hood}VPN\";" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "# Support xsalsa20 and aes128 encryption methods, prefer xsalsa20" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "#method \"xsalsa20-poly1305\";" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "#method \"aes128-gcm\";" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "method \"null\";" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "# Bind to a fixed port, IPv4 only" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "bind any:${port};" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "# Secret key generated by \"fastd --generate-key\"" >> /etc/fastd/$project.$hood/$project.$hood.conf
              echo "secret \"$(fastd --generate-key | grep -i Secret | awk '{print $2}')\";" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "# Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE)" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "# (see MTU selection documentation)" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "mtu 1426;" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "on up \"/etc/fastd/${project}.${hood}/up.sh\";" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "on post-down \"/etc/fastd/${project}.${hood}/down.sh\";" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "# Include peers from the directory 'peers'" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "include peers from \"/etc/fastd/${project}.${hood}/peers\";" >> /etc/fastd/$project.$hood/$project.$hood.conf
        echo "secure handshakes no;" >> /etc/fastd/$project.$hood/$project.$hood.conf


        echo "#!/bin/sh" >> /etc/fastd/$project.$hood/down.sh
[[Freifunk-Gateway_aufsetzen/wireguard]]
        echo "/sbin/ifdown \$INTERFACE" >> /etc/fastd/$project.$hood/down.sh
        chmod +x /etc/fastd/$project.$hood/down.sh


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


pubkey=$(fastd -c /etc/fastd/$project.$hood/$project.$hood.conf --show-key --machine-readable)
Zwischen den Routern werden Routen über ein Routingprotokoll ausgetauscht.
port=$(grep ^bind /etc/fastd/$project.$hood/$project.$hood.conf | cut -d: -f2 | cut -d\; -f1)


# fire up
Bei Freifunk Franken verwenden wir dafür aktuell '''Babel'''.
if [ "$(/sbin/ifconfig -a | grep -i ethernet | grep ${project}${hood}VPN)" = "" ]
then
/bin/rm /var/run/fastd.$project.$hood.pid
fastd -c /etc/fastd/$project.$hood/$project.$hood.conf -d --pid-file /var/run/fastd.$project.$hood.pid
fi


# register
Babel tauscht die erreichbaren IP-Bereiche zwischen den Routern aus, sodass jeder Router weiß über welchen Weg er andere IP-Bereiche erreichen kann.
wget -T15 "http://mastersword.de/~reddog/fff/?name=$hostname&port=$port&key=$pubkey" -O /tmp/fastd_${project}.${hood}_output
if [ "$?" != "0" ]
then
        echo "Update failed"
        echo "Exiting, no clean up, no refresh"
        exit
fi


touch /tmp/fastd_${project}.${hood}_starting
Es gibt aktuell 2 Implementierungen für Babel, aktuell wird noch mehrheitlich babeld verwendet aber auch bird2 kann verwendet werden.


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


echo "Lösche alte:"
[[Freifunk-Gateway_aufsetzen/bird2]]


find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print
=== Routing ins Internet ===
find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print | xargs /bin/rm /tmp/fastd_${project}.${hood}_starting
Es gibt verschiedene Möglichkeiten Traffic ins Internet zu routen.
* Einen anderen Router ins Internet routen lassen und dessen angebotene Route nutzen.
* Direkt am eigenen Server ins Internet routen
* Über einen VPN Anbieter ins Internet routen


#reload
[[Freifunk-Gateway_aufsetzen/Routing-ins-Internet]]
kill -HUP $(cat /var/run/fastd.$project.$hood.pid)


exit 0
== Layer-2 ==
</pre>
=== B.A.T.M.A.N. Advanced ===
Zwischen den zentralen Knoten und dem dazugehörenden Gateway wird mithilfe von Tunneln und batman-adv ein großes Layer-2 Netz aufgebaut. Dieses kann man sich vorstellen wie einen großen Switch zwischen dem Gateway und allen zentralen Knoten.


Das Skript konfiguriert fastd, indem es
Für '''dezentrale Gateways''' ohne batman-adv gilt dennoch der "Konfigurationsabschnitt" von batman-adv für das Clientinterface, nur dass die batman-adv spezifischen Einstellungen weggelassen werden.
* einen Schlüssel generiert, sollte keiner existieren
* diesen Schlüssel mit dem Keyserver austauscht
* die fastd Konfigurationsdatei anlegt
* den fastd Dämonen startet


Lediglich der Servername und die Hood müssen oben im Skript händisch angepasst werden. Der Dateiname des Skripts kann individuell angepasst werden.
[[Freifunk-Gateway_aufsetzen/Batman-adv]]


=== VPN für die Knoten ===


=== Testen von B.A.T.M.A.N, fastd und Autostart ===
Um das batman-adv der Knoten mit dem des Gateways zu verbinden, sind Layer-2 Tunnel nötig.


Hierfür booten wir das Gateway am besten erst mal neu:
Dafür gibt es aktuell zwei verschiedene Möglichkeiten. Es wird in der aktuellen Firmware immer nur eine der beiden Varianten verwendet.
<code>
Derzeit empfehlen wir aber trotz der deutlich langsameren Verbindungen fastd, da l2tp auf dem Server häufig instabil läuft.
reboot & exit
</code>


und starten das fast.d Startskript manuell:
==== fastd ====
<code>
+ wird von fast allen Gateways eingesetzt</br>
/etc/fastd/fff_beispiel_fastd.sh &
+ relativ einfach zu Konfigurieren</br>
</code>
- Läuft im Userspace, daher recht performancehungrig</br>


Beim Erststart werden Schlüsselpaare generiert und ausgetauscht, es kann also etwas dauern.
[[Freifunk-Gateway_aufsetzen/VPN/fastd]]


Danach sollte der Aufruf von...
==== l2tp mit Tunneldigger ('''Nicht mehr unterstützt''') ====
<code>
+ Läuft im Kernel, daher sehr schnell</br>
pgrep fastd
- Läuft scheinbar instabil</br>
</code>
- Aktuell kennen sich nur wenig Leute mit dieser Konfiguration aus</br>
... mit der Prozess-ID beantwortet werden: Fastd läuft in dem Fall.


Ein Aufruf von ifconfig:
'''Achtung: Ab dem nächsten Firmware-Release (Stand: 07/2019) wird L2TP nicht mehr von der Router-Firmware unterstützt!'''
<code>
ifconfig
</code>
 
sollte die neu erstellten Interfaces bat0 und ffffuerthVPN zurückliefern.
Exemplarisch:
<pre>
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)


.
[[Freifunk-Gateway_aufsetzen/VPN/l2tp]]
.
.
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)
.
.
.
</pre>
Aus dem ifconfig Auszug für bat0 sollte die eingerichtete IP des Gateways und die Netzmaske hervorgehen.


Eine Abfrage der fff-Routing Tabelle
=== vpn via vxlan ===
<code>
ip route show table fff
</code>


sollte die B.A.T.M.A.N Route (Device bato) in das Netzwerk der eingerichtete Hood wiederspiegeln. In diesem Beispiel ist es die Fürther Hood:
[[Freifunk-Gateway_aufsetzen/VPN/vxlan]]
<pre>
10.50.32.0/21 dev bat0  scope link
</pre>


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


Die Abfrage der IP-Regeln:
Um zu steuern, von welchem der Gateways Clients Adressen und damit auch das Default-Gateway beziehen, setzen wir einen weiteren großen Pfusch ein: Die Batman Gatewayselection
<code>
ip rule
</code>


sollte die oben definieren Regeln wieder spiegeln (fff Tabelle für Traffic, die entweder über bat0 oder 10.0.0.0/8 rein oder rausgeht):
Diese filtert DHCP Offers von den Gateways und lässt nur die Offers eines bestimmten Gateways bis zum Client durch. Dies funktioniert natürlich nur für IPv4. Batman-adv bleibt dennoch mit jedem Gateway verbunden, hier werden ausschließlich nur die DHCP für IPv4 Anfragen verändert.
<pre>
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
<pre>


Ein Aufruf von "batctl o"
[[Freifunk-Gateway_aufsetzen/Batman-Gatewayselection]]
<code>
batctl o
</code>


ergibt eine Liste der MAC-Adressen von unseren nächsten Nachbarn. Exemplarisch und als Auszug:
== Dienste ==
<pre>
=== SLAAC ===
[B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: ffffuerthVPN/e6:3b:f3:b7:fc:db (bat0)]
Bei IPv6 funktioniert die automatische Adresszuweisung über SLAAC.</br>
  Originator      last-seen (#/255)          Nexthop [outgoingIF]:  Potential nexthops ...
Dafür ist ein Dienst nötig, der die Router Advertisements mit den passenden Subnetzen sendet.
96:43:c4:2e:73:68    0.004s  (255) 96:43:c4:2e:73:68 [ffffuerthVPN]: 96:43:c4:2e:73:68 (255)
.
.
.
</pre>


Hat soweit alles geklappt, kann das Startscript /etc/fastd/fff_beispiel_fastd.sh bei jedem Systemstart ausgeführt werden, indem es z.B. in /etc/rc.local eingetragen wird:
[[Freifunk-Gateway_aufsetzen/radvd]]
<code>
vi /etc/rc.local
</code>


Hier spendieren wir einen Eintrag, der fastd mit 60 Sekunden Verzögerung bei jedem Systemstart mitstartet:
=== DHCP Server ===
<pre>
Die automatische Adresszuweisung funktioniert bei IPv4 mit DHCP.
# launch fastd with 60 seconds delay
Es muss ein DHCP Server installiert werden, der die Adressen passend an die Clients verteilt.
(sleep 60; sh /etc/fastd/fff_fuerth_fastd.sh) &
</pre>


'''
[[Freifunk-Gateway_aufsetzen/DHCP]]
Alternativ''' oder zusätzlich kann auch ein Cronjob angelegt werden, der das Skript z.B. alle 10 Minuten ausführt:
<code>
sudo crontab -e
</code>


Nun folgendes eingeben:
=== DNS Server ===
<pre>
Die Clients möchten Domains auflösen können, deshalb ist ein DNS-Server nötig.
*/10 * * * * sh /etc/fastd/fff_fuerth_fastd.sh
Zwar könnte einfach einer der öffentlichen {Google,Cloudflare,Quad9} DNS Server ausgeliefert werden, aber wir wollen die Anfragen ja nicht an große Unternehmen senden. :-)
</pre>


und
Außerdem können mit einem eigenen (rekursiven) DNS-Server auch die IC-VPN DNS Server erreichbar gemacht werden.


<code>
Es kann entweder selbst ein DNS-Server betrieben werden, oder in DHCP und Router Advertisement auf einen (oder mehrere) der gemeinsam betriebenen DNS Server verwiesen werden.
/etc/init.d/cron restart
</code>


=== OpenVPN-Tunnel einrichten ===
[[Freifunk-Gateway_aufsetzen/DNS]]
Die Einrichtung eines OpenVPN Tunnels kann von Anbieter zu Anbieter variieren.
Im Laufe der Zeit sollte die Dokumentation so um funktionierende Konfigurationen erweitert werden.


'''Mullvad'''
=== http Server für Hoodfile ===
Mullvad liefert in der Datei mullvadconfig.zip, die notwendigen Schlüssel (ca.crt, mullvad.crt, mullvad.key) als auch eine Konfigurationsdatei (mullvad_linux.conf) mit, die später angepasst werden muss.
Das Gateway muss ein aktuelles Hoodfile an Meshknoten ausliefern können. Dafür ist ein HTTP Server nötig.


Wie man Dateien auf einen Server Gateway steht z.B. [http://www.hypexr.org/linux_scp_help.php hier].
Dies ist nur nötig, wenn der zentrale keyxchange verwendet wird.


Als unverbindliche Richtschnur
[[Freifunk-Gateway_aufsetzen/http]]


=== Alfred Master (Monitoring) ===
Die Nodewatcher-Daten aller Knoten werden in einem Alfred Server gesammelt und am Gateway dann gemeinsam ans Monitoring übertragen.


nun sollte man seine Kundenummer sehen.
[[Freifunk-Gateway_aufsetzen/Alfred]]


Jetzt kopieren wir den Inhalt des Ordners mit unserer Kundenummer in den Ordener ''/etc/openvpn/''
Für dezentrale Gateways wird auf der Firmware layer3-20191214-beta ist alfred bereits integriert und aktiviert. Die Infos werden aus der GWConfig gezogen.


Sollte dann so aussehen:
=== ntp Server ===
Ein Dienst, der den Routern die aktuelle Uhrzeit bereitstellt.
Ist nicht für jedes Gateway zwingend nötig, es kann auch der NTP eines anderen Gateways verwendet werden.


<pre>
[[Freifunk-Gateway_aufsetzen/ntp]]
123XXXXXXXXX  crl.pem  mullvad.conf  mullvad.key
ca.crt       mullvad  mullvad.crt  mullvad-up
</pre>


Nun bearbeiten wir noch Mullvad folgendermaßen:
=== gwinfo (optional, Gateway-Daten für Monitoring) ===
gwinfo ist ein Zusätzliches Script, das Informationen vom Gateway sammelt und ebenfalls ans Monitoring sendet.
Das ganze ist optional.


<code>
[[Freifunk-Gateway_aufsetzen/gwinfo]]
sudo /etc/openvpn/mullvad-up
</code>


und ändern die Zeilen in:                                                                                 
=== xlat464 (optional, falls man kein IPv4 mehr in der Backbone routen möchte) ===
Mit xlat464 ist es möglich, den Clients ein ganz normales DualStack Netzwerk anzubieten aber in der Backbone kein IPv4 mehr routen zu müssen. Wir nutzen dazu clatd auf den Gateways


<pre>
[[Freifunk-Gateway_aufsetzen/xlat464]]
/sbin/ip route replace 0.0.0.0/1 via $5 table fff
/sbin/ip route replace 128.0.0.0/1 via $5 table fff
</pre>


speichern
= Einbringen des Gateways in die Hood / Keyserver =
Dieser Schritt ist nur nötig, wenn du ein Gateway in einer zentralen v2 Hood betreiben möchtest. Für reine Layer 3 Router o.ä. Setups ist dieser Schritt nicht nötig.


<code>
Abschliessend kann das Gateway im Keyserver als Gateway der entsprechenden Hood eingetragen werden. Hierfür benötigt man einen Keyserver-Administrator => [[KeyXchange#fff-netmon2]]. Alternativ kann die Hood natürlich auch mit festen Hoodfiles betrieben werden
sudo vi /etc/openvpn/mullvad.conf
</code>


dort nur den Server einkommentieren über den der Traffic gehen soll.
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.


z.B:
= Optimierungen =
* ARP Cache
* nf_conntrack
[[Freifunk-Gateway_aufsetzen/Optimierungen]]


<pre>
= Statistik =
#remote openvpn.mullvad.net 1194
#remote openvpn.mullvad.net 1194
#remote openvpn.mullvad.net 443
#remote openvpn.mullvad.net 53
#remote se.mullvad.net # Servers in Sweden
remote nl.mullvad.net # Servers in the Netherlands
#remote de.mullvad.net # Servers in Germany
#remote us.mullvad.net # Servers in the USA
</pre>
 
nun sollte alles über Holland gehen.
 
So, fast fertig.


=== DHCP Server ===
== MRTG ==
[[Freifunk-Gateway_aufsetzen/Statistik/mrtg|Statistik MRTG]]


Nun noch den DHCP Konfigurieren:
= Fehlersuche =
 
Zum finden von Fehlern, die erst Auftreten, wenn die Konfiguration schon einmal funktioniert hat, kann folgende Seite hilfreich sein:
<code>
sudo apt-get install isc-dhcp-server
</code>
 
Konfiguration öffnen:
 
<code>
sudo vi /etc/default/isc-dhcp-server
</code>
 
und Interface eintragen:
 
<pre>
INTERFACES="bat0"
</pre>
 
 
<code>
sudo vi /etc/dhcp/dhcpd.conf
</code>
 
und folgendes einfügen:
 
<pre>
option domain-name "freifunk-franken.de";
option domain-name-servers 10.50.16.1;
authoritative;
# beispielhood
subnet 10.50.56.0 netmask 255.255.252.0 {
        range 10.50.59.0 10.50.59.254;
        option routers 10.50.56.3;
        option domain-name-servers 10.50.56.3;
}
</pre>


die ip und die range muss natürlich in die bereits ,am Anfang im Wiki reservierten, ausgetauscht werden ;-)
[[Freifunk-Gateway_aufsetzen/Fehlersuche]]


So, nun werden wir am besten einen reboot durchführen und schauen ob alles läuft.
= 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:


[[Freifunk-Gateway_aufsetzen/spezielles_routing]]


[[Kategorie:Technik]]
[[Kategorie:Technik]]
[[Kategorie:Hoods-V2]]
[[Kategorie:Gateways]]

Aktuelle Version vom 14. März 2023, 17:54 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 erreichen ("Know-Why").

Die Anleitung dient dazu, den Einstig zu erleichtern.
Viele der Dinge können später auf die eigenen Bedürfnisse angepasst und zugeschnitten werden.

Die Anleitung hat keine Garantie auf Vollständigkeit und wird stetig verändert und verbessert.
Wenn du beim Installieren auf Probleme oder Fehler stößt: Der nächste freut sich, wenn er auf diesen Fehler nicht mehr stößt oder eine entsprechende Anmerkung im Wiki findet. :-)

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. Auch hier gilt wieder: Es wird gerne geholfen, wenn man sich mit Problemen einigermaßen selbstständig auseinandersetzt und konkrete Fragen stellt.
  • 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, das 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
    • Leider aktuell noch zu viele IPv4 Anschlüsse, um IPv4 außen vor zu lassen. :-(
    • IPv6 ist pflicht.
  • 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:

  • 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

Hoster, bei denen gute Erfahrungen gemacht wurden

Diese unvollständige, nicht abschließende Liste von Hostern dient nur der Orientierung. Solange ein Hoster die weiter oben genannten Voraussetzungen erfüllt, ist er für ein Freifunk Gateway geeignet.

Umso mehr verschiedene Hoster im Freifunknetz, umso besser.

  • Hetzner (Nürnberg, Falkenstein, Helsinki)
    • Cloud Server, 20TB Traffic 2,96€/Monat
    • Wird bedingt des vielen verfügbaren Traffics fürs Geld sehr viel genutzt
    • Hetzner-interner Traffic wird nicht berechnet
  • xirra (Core-Backbone, NBG)
    • KVM, TB-Traffic zu 5,95€. Langweilig und funktioniert. Pflegt bisher einen guten Kontakt zu Kunden.

Installation

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

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.

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.

Öffentliche Adressen

Damit das Internet erreicht werden kann, sind öffentliche IP Adressen nötig, die im Internet bekannt sind.

Diese können von verschiedenen Freifunkern bezogen werden, siehe IPv6

OS Settings

IP-Forwarding

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

Manuell (nur bis zum reboot aktiv):

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


sysctl Einstellungen können in der Datei /etc/sysctl.conf dauerhaft eingestellt werden.

Dort gibt es für das Forwarding bereits die passenden Zeilen, die nur einkommentiert werden müssen:


# 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

ICMP Fehlerpakete für IPv4

Damit ICMP hinter unserem NAT korrekt funktioniert, müssen die ICMP Fehler passend geroutet werden, dass sie beim NAT-Server landen. Das kann in Linux mit der Option "net.ipv4.icmp_errors_use_inbound_ifaddr = 1" erreicht werden.

Analog zu oben sollte diese Einstellung in sysctl.conf eingetragen werden, damit sie rebootfest ist:

net.ipv4.icmp_errors_use_inbound_ifaddr = 1

Außerdem landen dann keine ICMP Pakete mit internen Adressen als Absender auf dem Uplink [dem Hoster].

Siehe auch MTU

Routing Tabelle für Freifunk

Für die Routen im Freifunk Franken Netz muss eine eigene Routingtabelle angelegt werden.

Damit die Tabelle auch mit Name aufrufbar ist, sollten Tabellennummer und Name in /etc/iproute2/rt_tables eingetragen werden:

10     fff

Der Inhalt der Routingtabelle kann später mit

ip route show table fff
bzw.
ip -6 route show tab 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

Generelle Layer-3 Routing Regeln

Damit Pakete vom Gateway selbst passend in das Freifunk Netz geroutet werden, sind einige Regeln nötig.

Diese können an die Debian Interfacekonfiguration des Loopback Interfaces hinzugefügt werden, damit sind sie direkt nach dem Boot des Servers verfügbar.

prio legt fest, in welcher Reihenfolge die Regeln abgearbeitet werden. Hier sollte sich zunächst an die im Wiki vorgegebene Reihenfolge gehalten werden, später kann man diese auf die eigenen Bedürfnisse anpassen.

Außerdem können auch FFF-interne IP Adressen (10.x.x.x, fd43:5602:29bd:ffff::xx) an das Loopback Interface gehängt werden.

iface lo inet static
	address 10.83.252.x/32

	up ip -4 rule add to 10.0.0.0/8 prio 500 lookup fff
	down ip -4 rule del to 10.0.0.0/8 prio 500 lookup fff

        #DN42
 	up ip -4 rule add to 172.20.0.0/14 prio 500 lookup fff
	down ip -4 rule del to 172.20.0.0/14 prio 500 lookup fff

iface lo inet6 static
	address fd43:5602:29bd:ffff::xx/128

	up ip -6 rule add to fc00::/7 prio 500 lookup fff
	down ip -6 rule del to fc00::/7 prio 500 lookup fff

Für Pakete die auf Interfaces, welche für Freifunk verwendet werden (z.b. Clientnetz oder alle Babelverbindungen), ankommen muss auch expliziet in die fff table geguckt werden, dies muss für IPv4 und IPv6 gesetzt werden und sollte sinnvollerweise direkt an das entsprechende Interface geschrieben werden. Diese Regeln sollten eine möglich hohe Priorität haben (niedrige Zahl) damit Transit auf jeden Fall immer funktioniert.

[...]
up ip -6 rule add iif $IFACE prio 200 table fff
up ip rule add iif $IFACE prio 200 table fff
[...]

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 an beiden Enden eine feste IP-Adresse, da die Konfiguration komplett statisch ist. Außerdem unterstützen viele NATs GRE nicht, ggf. muss bei IPv4 eine passende Portweiterleitung angelegt werden.

Dafür ist es ein sehr einfaches Protokoll, leicht zu debuggen, sehr leightgewichtig und dadurch extrem schnell.

Es wird daher meist zwischen Servern in Rechenzentren eingesetzt. Der Traffic ist nicht verschlüsselt.

Freifunk-Gateway_aufsetzen/gre

wireguard

Wireguard benötigt nur an einem Ende eine feste IP Adresse. Außerdem kann es leicht hinter NAT betrieben werden, da UDP verwendet wird.

Dafür ist das Protokoll etwas komplizierter (und verschlüsselt) und dadurch auch etwas langsamer. Dennoch lassen sich je nach Hardware einige hundert MBit/s erreichen.

Freifunk-Gateway_aufsetzen/wireguard

Babel Routingprotokoll

Zwischen den Routern werden Routen über ein Routingprotokoll ausgetauscht.

Bei Freifunk Franken verwenden wir dafür aktuell Babel.

Babel tauscht die erreichbaren IP-Bereiche zwischen den Routern aus, sodass jeder Router weiß über welchen Weg er andere IP-Bereiche erreichen kann.

Es gibt aktuell 2 Implementierungen für Babel, aktuell wird noch mehrheitlich babeld verwendet aber auch bird2 kann verwendet werden.

Freifunk-Gateway_aufsetzen/babeld

Freifunk-Gateway_aufsetzen/bird2

Routing ins Internet

Es gibt verschiedene Möglichkeiten Traffic ins Internet zu routen.

  • Einen anderen Router ins Internet routen lassen und dessen angebotene Route nutzen.
  • Direkt am eigenen Server ins Internet routen
  • Über einen VPN Anbieter ins Internet routen

Freifunk-Gateway_aufsetzen/Routing-ins-Internet

Layer-2

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

Zwischen den zentralen Knoten und dem dazugehörenden Gateway wird mithilfe von Tunneln und batman-adv ein großes Layer-2 Netz aufgebaut. Dieses kann man sich vorstellen wie einen großen Switch zwischen dem Gateway und allen zentralen Knoten.

Für dezentrale Gateways ohne batman-adv gilt dennoch der "Konfigurationsabschnitt" von batman-adv für das Clientinterface, nur dass die batman-adv spezifischen Einstellungen weggelassen werden.

Freifunk-Gateway_aufsetzen/Batman-adv

VPN für die Knoten

Um das batman-adv der Knoten mit dem des Gateways zu verbinden, sind Layer-2 Tunnel nötig.

Dafür gibt es aktuell zwei verschiedene Möglichkeiten. Es wird in der aktuellen Firmware immer nur eine der beiden Varianten verwendet. Derzeit empfehlen wir aber trotz der deutlich langsameren Verbindungen fastd, da l2tp auf dem Server häufig instabil läuft.

fastd

+ wird von fast allen Gateways eingesetzt
+ relativ einfach zu Konfigurieren
- Läuft im Userspace, daher recht performancehungrig

Freifunk-Gateway_aufsetzen/VPN/fastd

l2tp mit Tunneldigger (Nicht mehr unterstützt)

+ Läuft im Kernel, daher sehr schnell
- Läuft scheinbar instabil
- Aktuell kennen sich nur wenig Leute mit dieser Konfiguration aus

Achtung: Ab dem nächsten Firmware-Release (Stand: 07/2019) wird L2TP nicht mehr von der Router-Firmware unterstützt!

Freifunk-Gateway_aufsetzen/VPN/l2tp

vpn via vxlan

Freifunk-Gateway_aufsetzen/VPN/vxlan

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

Um zu steuern, von welchem der Gateways Clients Adressen und damit auch das Default-Gateway beziehen, setzen wir einen weiteren großen Pfusch ein: Die Batman Gatewayselection

Diese filtert DHCP Offers von den Gateways und lässt nur die Offers eines bestimmten Gateways bis zum Client durch. Dies funktioniert natürlich nur für IPv4. Batman-adv bleibt dennoch mit jedem Gateway verbunden, hier werden ausschließlich nur die DHCP für IPv4 Anfragen verändert.

Freifunk-Gateway_aufsetzen/Batman-Gatewayselection

Dienste

SLAAC

Bei IPv6 funktioniert die automatische Adresszuweisung über SLAAC.
Dafür ist ein Dienst nötig, der die Router Advertisements mit den passenden Subnetzen sendet.

Freifunk-Gateway_aufsetzen/radvd

DHCP Server

Die automatische Adresszuweisung funktioniert bei IPv4 mit DHCP. Es muss ein DHCP Server installiert werden, der die Adressen passend an die Clients verteilt.

Freifunk-Gateway_aufsetzen/DHCP

DNS Server

Die Clients möchten Domains auflösen können, deshalb ist ein DNS-Server nötig. Zwar könnte einfach einer der öffentlichen {Google,Cloudflare,Quad9} DNS Server ausgeliefert werden, aber wir wollen die Anfragen ja nicht an große Unternehmen senden. :-)

Außerdem können mit einem eigenen (rekursiven) DNS-Server auch die IC-VPN DNS Server erreichbar gemacht werden.

Es kann entweder selbst ein DNS-Server betrieben werden, oder in DHCP und Router Advertisement auf einen (oder mehrere) der gemeinsam betriebenen DNS Server verwiesen werden.

Freifunk-Gateway_aufsetzen/DNS

http Server für Hoodfile

Das Gateway muss ein aktuelles Hoodfile an Meshknoten ausliefern können. Dafür ist ein HTTP Server nötig.

Dies ist nur nötig, wenn der zentrale keyxchange verwendet wird.

Freifunk-Gateway_aufsetzen/http

Alfred Master (Monitoring)

Die Nodewatcher-Daten aller Knoten werden in einem Alfred Server gesammelt und am Gateway dann gemeinsam ans Monitoring übertragen.

Freifunk-Gateway_aufsetzen/Alfred

Für dezentrale Gateways wird auf der Firmware layer3-20191214-beta ist alfred bereits integriert und aktiviert. Die Infos werden aus der GWConfig gezogen.

ntp Server

Ein Dienst, der den Routern die aktuelle Uhrzeit bereitstellt. Ist nicht für jedes Gateway zwingend nötig, es kann auch der NTP eines anderen Gateways verwendet werden.

Freifunk-Gateway_aufsetzen/ntp

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

gwinfo ist ein Zusätzliches Script, das Informationen vom Gateway sammelt und ebenfalls ans Monitoring sendet. Das ganze ist optional.

Freifunk-Gateway_aufsetzen/gwinfo

xlat464 (optional, falls man kein IPv4 mehr in der Backbone routen möchte)

Mit xlat464 ist es möglich, den Clients ein ganz normales DualStack Netzwerk anzubieten aber in der Backbone kein IPv4 mehr routen zu müssen. Wir nutzen dazu clatd auf den Gateways

Freifunk-Gateway_aufsetzen/xlat464

Einbringen des Gateways in die Hood / Keyserver

Dieser Schritt ist nur nötig, wenn du ein Gateway in einer zentralen v2 Hood betreiben möchtest. Für reine Layer 3 Router o.ä. Setups ist dieser Schritt nicht nötig.

Abschliessend kann das Gateway im Keyserver als Gateway der entsprechenden Hood eingetragen werden. Hierfür benötigt man einen Keyserver-Administrator => KeyXchange#fff-netmon2. Alternativ kann die Hood natürlich auch mit festen Hoodfiles betrieben werden

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.

Optimierungen

  • ARP Cache
  • nf_conntrack

Freifunk-Gateway_aufsetzen/Optimierungen

Statistik

MRTG

Statistik MRTG

Fehlersuche

Zum finden von Fehlern, die erst Auftreten, wenn die Konfiguration schon einmal funktioniert hat, kann folgende Seite hilfreich sein:

Freifunk-Gateway_aufsetzen/Fehlersuche

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:

Freifunk-Gateway_aufsetzen/spezielles_routing