Freifunk-Gateway aufsetzen: Unterschied zwischen den Versionen

Aus Freifunk Franken
Wechseln zu:Navigation, Suche
K (Seite gibt es nicht mehr)
 
(397 dazwischenliegende Versionen von 25 Benutzern werden nicht angezeigt)
Zeile 3: Zeile 3:


= Preface =
= 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").
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").


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.
Die Anleitung dient dazu, den Einstig zu erleichtern.</br>
Viele der Dinge können später auf die eigenen Bedürfnisse angepasst und zugeschnitten werden.


Für Rat und Tat empfiehlt sich die Freifunk Franken Development Mailingliste.
Die Anleitung hat keine Garantie auf Vollständigkeit und wird stetig verändert und verbessert.</br>
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. :-)


= Vorraussetzungen =
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.
* ssh-Zugang zum Server
* Root Zugriff auf den Server. Entweder man ist "root" (Annahme in diesem Artikel) oder man kann Befehle mit "root-Rechten" durch ein vorgesetztes "sudo" ausführen sowie die Möglichkeit auf dem Server Kernelmodule zu laden (kann nicht jeder VServer!)
* Grundlegende Netzwerkkenntnisse
** IPv4 und Netzmaske
** Devices
** Routing (Default Route, Interfaces, Routing-Table)
* Kentnisse
** im Umgang mit Texteditoren (der im Artikel verwendete Editor kann durch beliebig andere ersetzt werden, z.B. durch "nano")
** im Umgang mit der Linux Shell (z.B. Kommandozeilenparameter, Shell-Scripte, Umleitungen)
** in der (selbständigen Nach-)Installation von (fehlenden) Software-Paketen
** im Kompilieren von Software-Quellen
 
= Referenzen / Andere Freifunk HowTo's =
 
* http://wiki.freifunk.net/Freifunk_Hamburg/Gateway  
* http://wiki.mag.lab.sh/wiki/Freifunk_Fulda/Gateway
 
= Anforderungen an Gateways =
Die Anforderungen an das Gateway sind an sich niedrig. Wichtig ist, dass die Möglichkeit besteht, eigene Kernel-Module zu laden und das monatliche Traffic-Kontingent nicht zu niedrig ist. Entsprechend sind OpenVZ, Linux-vServer und ähnliche Containerlösungen nicht geeignet.
 
Hardware:
* CPU: 1x (64Bit)
* RAM: 256MB .. 1GB
* HDD: > 5 GB
* NIC: 1x
 
Software:
* Debian Jessie (8) 64Bit Kernel
* fastd v17
* openvpn
* B.A.T.M.A.N. adv 2013.4.0
* dhcpd
* olsr
* bind9


Pauschal gibt es keine Mindestanforderungen für den Trafficverbrauch. Es kommt sehr darauf an, wo der Server eingesetzt wird.
Für Rat und Tat empfiehlt sich die Freifunk Franken Development und die Freifunk Franken Gateway Mailingliste.
'''Momentan suchen wir aber vor allem Server mit einem kostenlosen Traffic von mindestens 10-20 TB/Monat.'''


== Anonymisierung (Störerhaftung) ==
'''Referenzen / Andere Freifunk HowTo's'''
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.
* [http://wiki.freifunk.net/Freifunk_Hamburg/Gateway Gateway FF-Hamburg]


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:
== Voraussetzungen ==


* [https://mullvad.net/en/ Mullvad] (Schweden, Niederlande)
=== Was der Betreiber mitbringen sollte ===
** Bis zu drei gleichzeitige Verbindungen
* Grundlegende Kenntnisse mit IP-Routing (IPv4 und IPv6)
** Kann man anonym mit Bitcoin bezahlen
* Motivation, etwas ''[jede Menge]'' dazuzulernen und sich aktiv mit der Materie auseinanderzusetzen.
** Serverauswahl über die ausgelieferte OpenVPN-Konfiguration
* 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.
*** Server in den Niederlanden sind abends oft stark ausgelastet
* 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.
**(Gute Erfahrungen in Lübeck)
* 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.


* [https://integrityvpn.com/ Integrity VPN] (Schweden, Port80)
=== Was der Server können muss ===
** 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.
* Öffentliche IPv4 und IPv6 Adresse
**Hat eine überaus seriöse Webseite und eine Ltd. erfunden.™
** Leider aktuell noch zu viele IPv4 Anschlüsse, um IPv4 außen vor zu lassen. :-(
**Hat schon mal was von IPv6 gehört. Nutzt es zurzeit jedoch nur für SEO.
** IPv6 ist pflicht.
**Blockiert Port 25 derzeit nicht.
* Kernelmodule laden (Bestimmte Virtualisierungslösungen wie OpenVZ sind daher nicht möglich)
**Ist ein ein neuer Anbieter, der _bisher_ unausgelastet wirkt.
* Nur relativ wenig CPU und RAM nötig
** sind derzeit noch nicht nicht overselled und haben ihren Krams scheinbar halbwegs sauber konfiguriert
* dafür relativ viel Traffic (Je nach Größe und Anzahl der Hoods durchaus im ein- bis niedrigen zweistelligen TB Bereich)


* [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:
* fastd VPN
* [https://www.anonine.com/en Anonine VPN] (Portlane)
* Batman ''(Compat15)''
* [https://privacy.io/ privacy.io] (Portlane)
* DHCP
* [http://prq.se/?p=tunnel&intl=1 prq.se] (Eigenes Netz, teuer)
* Router Advertisements
* [http://arethusa.su/vpn.html Arethusa VPN] (Loggen in Frankreich, andere Server angeblich nicht)
* Routing
 
* Babel Routing Protokoll
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.
* Webserver für Hoodfiles


== Anbindung an andere Netze ==
== Anbindung an andere Netze ==
Es gibt drei relativ relevante Netzwerke bei denen es sich lohnt, das lokale Netz damit zu  verbinden:
Neben unserem eigenen Freifunknetz gibt es weitere Netzwerke mit denen sich ein Peering lohnt:


* 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
** Achtung: Die Netzwerkarte der VM ist aus Kompatibilitätsgründen auf e1000 gesetzt. Diese "Netzwerkkarte" kommt nicht mit den vielen UDP-Paketen von fastd zurecht. Deshalb muss man vor Verwendung als Gateway die Netzwerkkarte auf "virtio" stellen.
* [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]
 
== Server-Anbieter die '''nicht''' empfehlenswert sind ==
* [http://www.wrzhost.com/ 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 =
=== Hoster, bei denen gute Erfahrungen gemacht wurden ===
Vom ausgesuchten Hoster lassen wir uns eine aktuelle Linux-Distribution installieren oder ausliefern, wobei sich die Anleitung auf ein Debian 8 / Jessie bezieht.
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.


== Repositories und Update ==
Umso mehr verschiedene Hoster im Freifunknetz, umso besser.
Als erstes werfen wir einen Blick in...


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


...und schauen, inwieweit auf die gleichen Software-Repositories verwiesen wird:
* [https://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.
<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
deb-src http://ftp.de.debian.org/debian/ jessie main contrib non-free
 
deb http://ftp.de.debian.org/debian/ jessie-updates main
deb-src http://ftp.de.debian.org/debian/ jessie-updates main
 
</pre>
 
Danach bringen wir das System auf einen aktuellen Stand:
 
<code>
apt-get update
 
apt-get upgrade
</code>
 
== Sicherheit ==
Den SSH-Zugang besser schützen durch:
* Ä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>
apt-get install fail2ban
</code>


und [http://www.thomas-krenn.com/de/wiki/SSH_Login_unter_Debian_mit_fail2ban_absichern einrichten]
* [https://www.netcup.de/ netcup]


So,nun sollte der Server ausreichend abgesichert sein.
= Installation =
Die Installation des Betriebssystems, Absicherung des Servers, Installieren von Updates usw. sind '''NICHT''' Gegenstand dieser Anleitung. Trotzdem kurz einige Hinweise:


* 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]


== B.A.T.M.A.N. adv 2013.4.0 Kernel-Modul ==
== Vorbereitung ==
Batman-Adv aus Jessie ist zu neu. Hier muss manuell das alte B.A.T.M.A.N. advanced 2013.4.0 gebaut werden.
=== IP-Adressen und DHCP Range des Gateway ===


Hierfür benötigen wir minimal die Paketquellen build-essential, linux-headers-amd64 und git:
Um Doppelbelegungen zu vermeiden, müssen diese auch im Wiki eingetragen werden.


<code>
An dieser Stelle sollte man sich unbedingt mit Subnetzen und der [[CIDR|CIDR-Notation]] vertraut machen, falls einem das (noch) Fremdworte sind.<br>
apt-get install build-essential linux-headers-amd64 git gnupg-curl
</code>


Die Softwarequellen müssen heruntergeladen...
==== Private FFF IPs ====
<code>
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.
cd ~


git clone https://github.com/freifunk-gluon/batman-adv-legacy
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.


cd batman-adv-legacy
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.
</code>


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


<code>
==== Peering-IPs ====
make
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>


make install
Bei IPv6 genügen die Link-Local Adressen.
</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.
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.


Nach erfolgreicher Erstellung kann das B.A.T.M.A.N Kernel Modul per modprobe händisch eingebunden werden:
==== Öffentliche Adressen ====
Damit das Internet erreicht werden kann, sind öffentliche IP Adressen nötig, die im Internet bekannt sind.


<code>
Diese können von verschiedenen Freifunkern bezogen werden, siehe [[IPv6]]
modprobe batman-adv
</code>


Es sollte dann im Kernel-log ....
=== OS Settings ===
<code>
==== IP-Forwarding ====
dmesg | grep batman_adv
Per default leitet Debian keine Pakete weiter, die unser Gateway erreichen. Deswegen muss IP-Forwarding aktiviert werden.
</code>


... mit einem Eintrag gelistet werden:
Manuell (nur bis zum reboot aktiv):
<pre>
<pre>
  batman_adv: B.A.T.M.A.N. advanced 2013.4.0-21-ga854277-dirty (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>
vi /etc/modules
</code>
..der Eintrag "batman-adv" hinzugefügt wird:
<pre>
batman-adv
</pre>
== B.A.T.M.A.N adv 2013.4.0 batctl ==
Gleiches gilt für batctl, ein Kommandozeilenprogramm zur B.A.T.M.A.N Konfiguration. Die alte Version 2013.4.0 muss selber gebaut werden, da die Debian 8 / Jessie Paketquellen zu neu sind.
Herunterladen und Entpacken der Softwarequellen:
<code>
cd ~
wget http://downloads.open-mesh.org/batman/releases/batman-adv-2013.4.0/batctl-2013.4.0.tar.gz
tar xzf batctl-2013.4.0.tar.gz
cd batctl-2013.4.0
</code>
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.d/universe-factory.list
</code>
Dort fügen wir folgendes Repository an:
<pre>
deb http://repo.universe-factory.net/debian/ sid main
deb-src http://repo.universe-factory.net/debian/ sid main
</pre>
Danach die PGP Schlüssel holen:
<code>
gpg --keyserver hkps://hkpspool.sks-keyservers.net --recv-key 16EF3F64CB201D9C
gpg -a --export 16EF3F64CB201D9C | apt-key add -
</code>
Datenbankupdate der Paketverwaltung:
<code>
apt-get update
</code>
Installation von fastd:
<code>
apt-get install fastd
</code>
== OpenVPN ==
OpenVPN (falls benötigt) installieren wir mit:
<code>
apt-get install openvpn
</code>
== DHCP ==
Den DHCP Server installieren wir mit:
<code>
apt-get install isc-dhcp-server
</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>
wget http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd_0.6.8.1-1_amd64.deb
dpkg -i olsrd_0.6.8.1-1_amd64.deb
wget http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd-plugins_0.6.8.1-1_amd64.deb
dpkg -i olsrd-plugins_0.6.8.1-1_amd64.deb
</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>
10    fff
</pre>
Unsere Freifunk Routing Tabelle lässt sich später durch
<code>
ip route show table fff
</code>
anzeigen, sobald wir die Tabelle mit Einträgen füllen.
== B.A.T.M.A.N Netzwerk-Interface, fff Routingregeln und -tabelle ==
'''Hinweis:''' Wenn man für einige nette Dinge um das B.A.T.M.A.N Netzwerk-Interface eine Bridge haben möchte gibt es unter [[Freifunk-Gateway aufsetzen/Batman bridge]] eine entsprechende Anleitung.
In der Datei /etc/network/interfaces ...
<code>
vi /etc/network/interfaces
</code>
fügen wir zunächst folgenden Textblock des Gateways "klee" aus der Fürther Hood an:
<pre>
.
.
.
# device: bat0
iface bat0 inet manual
post-up ifconfig $IFACE up
    ##Einschalten post-up:
    # IP des Gateways am B.A.T.M.A.N interface:
    post-up ip addr add 10.50.32.5/21 dev $IFACE
    # Regeln, wann die fff Routing-Tabelle benutzt werden soll:
    post-up ip rule add iif $IFACE table fff
    post-up ip rule add from 10.0.0.0/8 table fff
    post-up ip rule add to 10.0.0.0/8  table fff
    # Route in die Fuerther Hood:
    post-up ip route add 10.50.32.0/21 dev $IFACE table fff
    # Start des DHCP Servers:
    post-up invoke-rc.d isc-dhcp-server restart
    ##Ausschalten post-down:
    # Loeschen von oben definieren Routen, Regeln und Interface:
    post-down ip route del 10.50.32.0/21 dev $IFACE table fff
    post-down ip rule del from 10.0.0.0/8 table fff
    post-down ip rule del to 10.0.0.0/8 table fff
    post-down ip rule del iif $IFACE table fff
    post-down ifconfig $IFACE down
# VPN Verbindung in die Fuerther Hood
iface ffffuerthVPN inet manual
    post-up batctl -m bat0 if add $IFACE
    post-up ifconfig $IFACE up
    post-up ifup bat0
    post-down ifdown bat0
    post-down ifconfig $IFACE down
</pre>
In diesem Beispiel sind:
* IP des Gateway/Netzmaske der Fürther Hood: 10.50.32.5/21
* IP des Netzwerks Fürther Hood / Netzmaske der Fürther Hood: 10.50.32.0/21.
Diese müssen gegen die oben reservierte IP/Netzmaske des Gateways der Hood und gegen die Netzwerk-IP/Netzmaske der Hood, in die das neue Gateway soll, ausgetauscht werden.
Der Eintrag "ip route add 10.50.32.0/21 dev $IFACE table fff" fügt in der fff Routingtabelle eine Route in das Netzwerk "Fürther Hood" ein. Für Hassberge müsste dieser Eintrag z.B. in 10.50.56.0/22 geändert und für die IP-Adresse des Gateways eine aus dem statischen Bereich der Hassberger Hood reserviert und verwendet werden (s.o.).
Die Regeln definieren, das Traffic der
* aus dem Netzwerk 10.0.0.0/8 kommt
* das Netzwerk 10.0.0.0/8 zum Ziel hat
* oder über die B.A.T.M.A.N Schnittstelle übermittelt wird
von der fff Routingtabelle behandelt werden. Die Einträge sind so allgemein formuliert, dass sie für das gesamte Freifunk Franken Netz Gültigkeit haben sollten.
Im post-down Abschnitt werden die vorher definierten Regeln, Interfaces und Routen wieder gelöscht.
Der untere Abschnitt definiert einen VPN Tunnel in die Fürther Hood. Der Name des Interfaces im Beispiel (ffffuerthVPN) kann individuell neu vergeben werden.
== FastD Start- und Verwaltungsscript ==
Für die Konfiguration von fastd importieren wir eine Datei in ''/etc/fastd'' mit dem Befehl:
<code>
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/fff_beispiel_fastd.sh -P /etc/fastd/
</code>
Alternativ kann das Skript aus einer leeren Datei erstellt werden:
<code>
touch /etc/fastd/fff_beispiel_fastd.sh
</code>
danach öffnen wir diese:


<code>
sysctl Einstellungen können in der Datei '''/etc/sysctl.conf''' dauerhaft eingestellt werden.
vi /etc/fastd/fff_beispiel_fastd.sh
</code>


und editieren das Skript oder fügen ein Neues ein:
Dort gibt es für das Forwarding bereits die passenden Zeilen, die nur einkommentiert werden müssen:
<pre>
<pre>
#!/bin/sh
SERVERNAME="beispiel"
hood="hoodeintragen"
project="fff"
port=10004
SERVERNAME="$SERVERNAME.$hood"
hostname=$SERVERNAME
if [ ! -d /etc/fastd ]
then
        mkdir /etc/fastd
fi
if [ ! -d /etc/fastd/$project.$hood ]
then
        mkdir /etc/fastd/$project.$hood
        mkdir /etc/fastd/$project.$hood/peers
       
        #fastd config
        (
          echo "# Log warnings and errors to stderr"
          echo "log level error;"
          echo "# Log everything to a log file"
          echo "log to syslog as \"${project}${hood}\" level info;"
          echo "# Set the interface name"
          echo "interface \"${project}${hood}VPN\";"
          echo "# Support xsalsa20 and aes128 encryption methods, prefer xsalsa20"
          echo "#method \"xsalsa20-poly1305\";"
          echo "#method \"aes128-gcm\";"
          echo "method \"null\";"
          echo "# Bind to a fixed port, IPv4 only"
          echo "bind any:${port};"
          echo "# Secret key generated by \"fastd --generate-key\""
          echo "secret \"$(fastd --generate-key | grep -i Secret | awk '{print $2}')\";"                                                                     
          echo "# Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE)"                                         
          echo "# (see MTU selection documentation)"                                                                                                         
          echo "mtu 1426;"                                                                                                                                   
          echo "on up \"/etc/fastd/${project}.${hood}/up.sh\";"                                                                                             
          echo "on post-down \"/etc/fastd/${project}.${hood}/down.sh\";"                                                                                     
          echo "# Include peers from the directory 'peers'"                                                                                                 
          echo "include peers from \"/etc/fastd/${project}.${hood}/peers\";"                                                                                 
          echo "secure handshakes no;"
        ) >> "/etc/fastd/$project.$hood/$project.$hood.conf"
       
        #fastd-up
        (
          echo "#!/bin/sh"
          echo "/sbin/ifdown \$INTERFACE"
        ) >> /etc/fastd/$project.$hood/down.sh
        chmod +x /etc/fastd/$project.$hood/down.sh
        (
          echo "#!/bin/sh"
          echo "/sbin/ifup \$INTERFACE" >> /etc/fastd/$project.$hood/up.sh
        ) >> /etc/fastd/$project.$hood/up.sh
        chmod +x /etc/fastd/$project.$hood/up.sh
fi
pubkey=$(fastd -c /etc/fastd/$project.$hood/$project.$hood.conf --show-key --machine-readable)
port=$(grep ^bind /etc/fastd/$project.$hood/$project.$hood.conf | cut -d: -f2 | cut -d\; -f1)
# fire up
if [ "$(/sbin/ifconfig -a | grep -i ethernet | grep ${project}${hood}VPN)" = "" ]
then
  /bin/rm /var/run/fastd.$project.$hood.pid
  fastd -c /etc/fastd/$project.$hood/$project.$hood.conf -d --pid-file /var/run/fastd.$project.$hood.pid
fi
# register
wget -T15 -q "http://keyserver.freifunk-franken.de/${project}/?name=$hostname&port=$port&key=$pubkey" -O /tmp/fastd_${project}.${hood}_output
if [ "$?" != "0" ]
then
        echo "Update failed"
        echo "Exiting, no clean up, no refresh"
        exit
fi
touch /tmp/fastd_${project}.${hood}_starting
filenames=$(cat /tmp/fastd_${project}.${hood}_output| grep ^#### | sed -e 's/^####//' | sed -e 's/.conf//g')
for file in $filenames
do
  grep -A100 ^####$file.conf$ /tmp/fastd_${project}.${hood}_output | grep -v ^####$file.conf$ | grep -m1 ^### -B100 | grep -v ^### | sed 's/ float;/;/g' > "/etc/fastd/$project.$hood/peers/$file"
  echo 'float yes;' >> "/etc/fastd/$project.$hood/peers/$file"
done
#find old peers
OLD=$(find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print)
if [ -n "${OLD}" ] ; then
  echo "Lösche alte:"
  echo $OLD
 
  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
fi
#reload
kill -HUP "$(cat /var/run/fastd.$project.$hood.pid)"
exit 0
</pre>
Zum Schluss geben wir noch ein
<code>
chmod +x /etc/fastd/fff_beispiel_fastd.sh
</code>
ein, um das Skript ausführbar zu machen.
Das Skript konfiguriert fastd, indem es
* einen Schlüssel generiert, sollte keiner existieren
* diesen Schlüssel mit dem Keyserver austauscht
* die fastd Konfigurationsdatei anlegt
* den fastd Dämonen startet


Lediglich der Servername und die Hood müssen oben im Skript händisch angepasst werden. Der Dateiname des Skripts kann individuell angepasst werden.
Nachdem das Script ausgeführt wurde, sollte man überprüfen ob das Interface in der Konfigurationsdatei unter /etc/fastd/fff.<Hoodname>/fff.<Hoodname>.conf das gleiche ist wie vorher in /etc/network/interfaces festgelegt. Wenn der Name nicht identisch ist (Case-senistiv), werden die Interfaces nicht starten.
Hinweis: Das Gateway wird standardmässig in die Default-Hood eingebunden. Es wird hier lediglich ein Name für die Konfigurationsdatei und der Gateway Name definiert. Die Zuordnung des Gateways zu der Hood erfolgt später über den KeyXchange (siehe unten).
== IP-Forwarding ==
Um Anfragen, die das Gateway erreichen, weiterzuleiten, muss IP-Forwarding aktiviert werden.
Manuell geht dies über:
<code>
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
</code>
Dauerhaft lässt sich IP-Forwarding in /etc/sysctl.conf aktivieren:
<code>
vi /etc/sysctl.conf
</code>
.. um dort die Abschnitte einzukommentieren, die das Forwarding steuern:
<pre>
.
.
.
# Uncomment the next line to enable packet forwarding for IPv4
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1
net.ipv4.ip_forward=1
Zeile 594: Zeile 149:
#  based on Router Advertisements for this host
#  based on Router Advertisements for this host
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.all.forwarding=1
.
.
.
</pre>


== Testen von B.A.T.M.A.N, fastd und Autostart ==
Hierfür booten wir das Gateway am besten erst mal neu:
<code>
reboot & exit
</code>
und starten das fast.d Startskript manuell:
<code>
/etc/fastd/fff_beispiel_fastd.sh &
</code>
Beim Erststart werden Schlüsselpaare generiert und ausgetauscht, es kann also etwas dauern.
Danach sollte der Aufruf von...
<code>
pgrep fastd
</code>
... mit der Prozess-ID beantwortet werden: Fastd läuft in dem Fall.
Ein Aufruf von ifconfig:
<code>
ifconfig
</code>
sollte die neu erstellten Interfaces bat0 und ffffuerthVPN zurückliefern.
Exemplarisch und als Auszug:
<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)
.
.
.
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>
</pre>
Aus dem ifconfig Auszug für bat0 sollte die eingerichtete IP des Gateways und die Netzmaske hervorgehen.


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


Die Abfrage der IP-Regeln:
Analog zu oben sollte diese Einstellung in sysctl.conf eingetragen werden, damit sie rebootfest ist:
<code>
ip rule
</code>
 
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):
<pre>
<pre>
32757: from all to 10.0.0.0/8 lookup fff
net.ipv4.icmp_errors_use_inbound_ifaddr = 1
32758: from 10.0.0.0/8 lookup fff
32759: from all iif bat0 lookup fff
</pre>
</pre>


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


Eine Abfrage der fff-Routing Tabelle
Siehe auch [[MTU]]
<code>
ip route show table fff
</code>


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:
==== Routing Tabelle für Freifunk ====
<pre>
Für die Routen im Freifunk Franken Netz muss eine eigene Routingtabelle angelegt werden.
10.50.32.0/21 dev bat0  scope link
</pre>


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


Ein Aufruf von "batctl o"
<code>
batctl o
</code>
ergibt eine Liste der MAC-Adressen von unseren nächsten Nachbarn. Exemplarisch und als Auszug:
<pre>
<pre>
[B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: ffffuerthVPN/e6:3b:f3:b7:fc:db (bat0)]
10    fff
  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)
.
.
.
</pre>
</pre>


 
Der Inhalt der Routingtabelle kann später mit
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:
<code>
vi /etc/rc.local
</code>
 
Hier spendieren wir einen Eintrag, der fastd mit 10 Sekunden Verzögerung bei jedem Systemstart mitstartet:
<pre>
<pre>
# launch fastd with 10 seconds delay
ip route show table fff
(sleep 10; sh /etc/fastd/fff_beispiel_fastd.sh) &
bzw.
</pre>
ip -6 route show tab fff
 
 
'''Zusätzlich''' muss ein Cronjob angelegt werden, der das Skript z.B. alle 10 Minuten ausführt:
<code>
crontab -e
</code>
 
Nun folgendes eingeben:
<pre>
*/10 * * * * sh /etc/fastd/fff_beispiel_fastd.sh
</pre>
</pre>
angezeigt werden.
<br>


und
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>


<code>
== Layer-3 ==
/etc/init.d/cron restart
=== Generelle Layer-3 Routing Regeln ===
</code>
Damit Pakete vom Gateway selbst passend in das Freifunk Netz geroutet werden, sind einige Regeln nötig.


== OpenVPN-Tunnel einrichten ==
Diese können an die Debian Interfacekonfiguration des Loopback Interfaces hinzugefügt werden, damit sind sie direkt nach dem Boot des Servers verfügbar.
Die Einrichtung eines OpenVPN Tunnels kann von Anbieter zu Anbieter variieren.
Im Laufe der Zeit sollte die Dokumentation so um funktionierende Konfigurationen verschiedener Anbieter erweitert werden.


=== Mullvad ===
'''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.


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


Man kopiert nun die zip-Datei auf das Gateway, entpackt sié und kopiert das Kundenummern-Verzeichnis mit dem Dateien ca.crt, crl.pem, mullvad.crt, mullvad.key, mullvad_linux.conf nach /etc/openvpn:
Von dem lokalen Rechner kopieren wir die zip Datei per scp für [http://ged.msu.edu/angus/tutorials/using-putty-on-windows.html Windows] oder [http://www.hypexr.org/linux_scp_help.php Linux] auf das Gateway.
Als unverbindliche Richtschnur für Linux:
<code>
scp mullvadconfig.zip root@<ipv4 des Gateways>:/root
</code>
Danach loggen wir uns auf dem Gateway ein und entpacken die Datei:
<code>
ssh root@<ipv4 des Gateways>
unzip mullvadconfig.zip
cd <Kundennummernverzeichnis>
cp * /etc/openvpn
</code>
''/etc/openvpn/'' sollte mit dem Inhalt des entpackten mullvadconfig.zip Archivs dann so aussehen:
<pre>
<pre>
ca.crt crl.pem  mullvad.crt  mullvad.key  mullvad_linux.conf  mullvad-up  mullvad_windows.conf.ovpn 
iface lo inet static
</pre>
address 10.83.252.x/32


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


Wir legen ein benutzerspezifisches start-up Script namens mullvad-up an:
        #DN42
<code>
up ip -4 rule add to 172.20.0.0/14 prio 500 lookup fff
touch /etc/openvpn/mullvad-up
down ip -4 rule del to 172.20.0.0/14 prio 500 lookup fff
</code>


öffnen die Datei:                                                                                  
iface lo inet6 static
<code>
address fd43:5602:29bd:ffff::xx/128
vi /etc/openvpn/mullvad-up
</code>


und füllen sie mit folgendem Inhalt:
up ip -6 rule add to fc00::/7 prio 500 lookup fff
<pre>
down ip -6 rule del to fc00::/7 prio 500 lookup fff
#!/bin/bash
logger -t OPENVPN VPN Gateway: /sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff
/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE
</pre>
</pre>
Das Skript definiert in der fff-Routingtabelle zunächst den VPN Anbieter als Standard-Gateway ("/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff"). D.h. Traffic, der über das Freifunk-Netz hereinkommt (Definiert über die fff IP rules) und für den keine anderweitigen Routinginformationen bekannt sind (z.B. Internet Traffic), wird pauschal in Richtung des VPN Gateways geschickt (IP ${route_vpn_gateway}, Device ${dev}). Das Default-Gateway für Traffic, der nicht freifunkbezogen ist, bleibt unangetastet, um sich nicht selber auszusperren.
Da wir Anfragen vieler Clients (verschiedene IPs) über eine VPN IP schieben, müssen wir darüber hinaus "Network Adress Translation" (NAT) betreiben ("iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE"). Dies ist auch erforderlich, da der Freifunk IPv4 Adressbereich 10.0.0.0/8 für lokale Netze reserviert ist und nicht im Internet geroutet wird.
Das Skript mullvad-up muss ferner ausführbar sein:
<code>
chmod +x /etc/openvpn/mullvad-up
</code>


Dieses spezifische Routing muss zwingend in mullvad_linux.conf eingepflegt werden:
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.
<code>
vi /etc/openvpn/mullvad_linux.conf
</code>


und hier die Konfiguration entsprechend geändert werden:
<pre>
<pre>
.
[...]
.
up ip -6 rule add iif $IFACE prio 200 table fff
.
up ip rule add iif $IFACE prio 200 table fff
# Allow calling of built-in executables and user-defined scripts.
[...]
script-security 2
 
# Parses DHCP options from openvpn to update resolv.conf
#up /etc/openvpn/update-resolv-conf
#down /etc/openvpn/update-resolv-conf
 
# Enable Freifunk specific Routing
route-noexec
route-delay 3
route-up    /etc/openvpn/mullvad-up
.
.
.
</pre>
</pre>
Script security muss auf "2" stehen, damit benutzerspezifische Skripte ausgeführt werden dürfen. Unser Freifunk spezifisches Routing wird über "route-up /etc/openvpn/mullvad-up" ausgeführt, wobei wir vorher openvpn mit "route-noexec" verbieten, automatisch selber Routen anzulegen. Aus Sicherheitsgründen führen wir einen kleinen Zeitpuffer von 3 Sekunden ein ("route-delay 3"). Vorhandene Start/Stop-Skripte (up/down) sollten auskommentiert werden.


Wer möchte, kann in mullvad_linux.conf auch Länder definieren, über die der VPN Traffic laufen soll (Ein- /Auskommentieren).
=== 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.


Der openvpn Tunnel kann nun testweise gestartet werden:
Dafür ist es ein sehr einfaches Protokoll, leicht zu debuggen, sehr leightgewichtig und dadurch extrem schnell.
<code>
cd /etc/openvpn


/usr/sbin/openvpn mullvad_linux.conf  &
Es wird daher meist zwischen Servern in Rechenzentren eingesetzt. Der Traffic ist nicht verschlüsselt.
</code>


und sollte exemplarisch und im Auszug folgendes zurück liefern:
[[Freifunk-Gateway_aufsetzen/gre]]
<pre>
Sun Sep  6 12:45:20 2015 OpenVPN 2.3.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec  1 2014
Sun Sep  6 12:45:20 2015 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08
Sun Sep  6 12:45:20 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
.
.
.
Sun Sep  6 12:45:23 2015 /sbin/ip link set dev tun0 up mtu 1500
Sun Sep  6 12:45:23 2015 /sbin/ip addr add dev tun0 10.114.0.45/16 broadcast 10.114.255.255
Sun Sep  6 12:45:23 2015 /sbin/ip -6 addr add fdef:e287:a479:72::102b/112 dev tun0
Sun Sep  6 12:45:23 2015 /etc/openvpn/mullvad-up tun0 1500 1558 10.114.0.45 255.255.0.0 init
Sun Sep  6 12:45:23 2015 Initialization Sequence Completed
</pre>
Wichtig ist hierbei, dass in der vorletztes Zeile unser Freifunk-spezifisches Routing durchgeführt wird.


Das VPN-Gateway sollte nun als Default Route in der fff-Routingtabelle auftauchen:
==== wireguard ====
<code>
Wireguard benötigt nur an einem Ende eine feste IP Adresse. Außerdem kann es leicht hinter NAT betrieben werden, da UDP verwendet wird.
ip route show table fff | grep default
</code>


Exemplarisch wäre eine Ausgabe für das Tunnel-Device tun0 und dem VPN-Gateway 10.114.0.1:
Dafür ist das Protokoll etwas komplizierter (und verschlüsselt) und dadurch auch etwas langsamer.
<pre>
Dennoch lassen sich je nach Hardware einige hundert MBit/s erreichen.
default via 10.114.0.1 dev tun0
</pre>


[[Freifunk-Gateway_aufsetzen/wireguard]]


Auch ein ifconfig Eintrag für das Tunnel Device...
=== Babel Routingprotokoll ===
<code>
ifconfig
</code>


...sollte jetzt existieren (Exemplarisch und im Auszug):
Zwischen den Routern werden Routen über ein Routingprotokoll ausgetauscht.
<pre>
.
.
.
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
          inet addr:10.114.0.76  P-t-P:10.114.0.76  Mask:255.255.0.0
          inet6 addr: fdad:bdef:735d:72::104a/112 Scope:Global
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:1012476 errors:0 dropped:0 overruns:0 frame:0
          TX packets:640206 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:1250196616 (1.1 GiB)  TX bytes:84979294 (81.0 MiB)
.
.
.
</pre>


Bei Freifunk Franken verwenden wir dafür aktuell '''Babel'''.


Wenn alles geklappt hat, kann man (sofern openvpn nicht korrekt beim Systemstart geladen wird), den openvpn Tunnel in der /etc/rc.local bei jedem Systemstart laden:
Babel tauscht die erreichbaren IP-Bereiche zwischen den Routern aus, sodass jeder Router weiß über welchen Weg er andere IP-Bereiche erreichen kann.
<code>
vi /etc/rc.local
</code>


und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:
Es gibt aktuell 2 Implementierungen für Babel, aktuell wird noch mehrheitlich babeld verwendet aber auch bird2 kann verwendet werden.
<pre>
# launch vpn with 5 seconds delay
(sleep 5; cd /etc/openvpn ; /usr/sbin/openvpn mullvad_linux.conf >> /var/log/mullvad_vpn.log &) &
</pre>


=== NordVPN ===
[[Freifunk-Gateway_aufsetzen/babeld]]
NordVPN liefert die Datei config.zip mit, die für jeden verwendbaren VPN-Server eine seperate Konfigurationsdatei enthält.


'''Hinweis:''' Auch hier gilt - Wer sich nicht ungewollt von seinem Gateway aussperren möchte, muss vor dem Starten von OpenVPN und vor einem neuen Reboot die Konfigurationsdatei anpassen.
[[Freifunk-Gateway_aufsetzen/bird2]]


Von dem lokalen Rechner kopieren wir die zip Datei per scp für [http://ged.msu.edu/angus/tutorials/using-putty-on-windows.html Windows] oder [http://www.hypexr.org/linux_scp_help.php Linux] auf das Gateway.
=== 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


Als unverbindliche Richtschnur für Linux:
[[Freifunk-Gateway_aufsetzen/Routing-ins-Internet]]
<code>
scp config.zip root@<ipv4 des Gateways>:/root
</code>


Und entpacken diese auf dem Gateway:
== Layer-2 ==
<code>
=== B.A.T.M.A.N. Advanced ===
cd ~
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.


mkdir nordvpn-configs
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.


mv config.zip nordvpn-configs
[[Freifunk-Gateway_aufsetzen/Batman-adv]]


cd nordvpn-configs
=== VPN für die Knoten ===


unzip config.zip
Um das batman-adv der Knoten mit dem des Gateways zu verbinden, sind Layer-2 Tunnel nötig.
</code>


Danach wählen wir einen VPN Server aus, z.B. unter dem Gesichtspunkt das er wenige Hops vom Gateway entfernt ist und/oder in einem Land unserer Wahl steht.
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.


Im Beispiel nehmen wir se1.nordvpn.com.udp1194.ovpn und passen Sie zunächst Freifunk-spezifisch an (siehe Aussperr-Hinweis oben):
==== fastd ====
+ wird von fast allen Gateways eingesetzt</br>
+ relativ einfach zu Konfigurieren</br>
- Läuft im Userspace, daher recht performancehungrig</br>


<code>
[[Freifunk-Gateway_aufsetzen/VPN/fastd]]
vi se1.nordvpn.com.udp1194.ovpn
</code>


Änhlich wie bei Mullvad, bestimmen wir dass wir das Routing mit einem eigenen Skript festlegen wollen (/etc/openvpn/nordvpn-up) und openvpn die Route nicht selber definieren soll. Zusätzlich geben wir eine Datei an, in die wir später Password und Benutzername des NordVPN Zugangs (/etc/openvpn/nordvpn-pw) ablegen:
==== l2tp mit Tunneldigger ('''Nicht mehr unterstützt''') ====
<pre>
+ Läuft im Kernel, daher sehr schnell</br>
.
- Läuft scheinbar instabil</br>
.
- Aktuell kennen sich nur wenig Leute mit dieser Konfiguration aus</br>
.
# Provide Username and Password
auth-user-pass /etc/openvpn/nordvpn-pw
.
.
.
# Allow calling of built-in executables and user-defined scripts.
script-security 2


# Enable Freifunk specific Routing
'''Achtung: Ab dem nächsten Firmware-Release (Stand: 07/2019) wird L2TP nicht mehr von der Router-Firmware unterstützt!'''
route-noexec
route-delay 3
route-up    /etc/openvpn/nordvpn-up
.
.
.
</pre>


Die angepasste Datei (im Beispiel  se1.nordvpn.com.udp1194.ovpn) kopieren wir nach /etc/openvpn:
[[Freifunk-Gateway_aufsetzen/VPN/l2tp]]
<code>
cp se1.nordvpn.com.udp1194.ovpn /etc/openvpn
</code>


Hier legen wir noch unser Freifunk Startskript und unsere Password Datei an und machen das Skript ausführbar:
=== vpn via vxlan ===
<code>
touch /etc/openvpn/nordvpn-up


touch /etc/openvpn/nordvpn-pw
[[Freifunk-Gateway_aufsetzen/VPN/vxlan]]


chmod +x /etc/openvpn/nordvpn-up
=== B.A.T.M.A.N Gateway Selection ===
</code>


Man öffnet nordvpn-up...
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>
vi /etc/openvpn/nordvpn-up
</code>


und füllt die Datei mit identischem Inhalt wie mullvad-up. Bei Interesse stehen weitere Hinweise bei mullvad (Network Adress Translation, Default Gateway für Freifunk Traffic):
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>
#!/bin/bash
logger -t OPENVPN VPN Gateway: /sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff
/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE
</pre>


[[Freifunk-Gateway_aufsetzen/Batman-Gatewayselection]]


Nun öffnet man nordvpn-pw:
== Dienste ==
<code>
=== SLAAC ===
vi /etc/openvpn/nordvpn-pw
Bei IPv6 funktioniert die automatische Adresszuweisung über SLAAC.</br>
</code>
Dafür ist ein Dienst nötig, der die Router Advertisements mit den passenden Subnetzen sendet.


Und legt in der ersten Zeile der Datei seinen NordVPN Usernamen und in der zweiten Zeile sein NordVPN Passwort ab:
[[Freifunk-Gateway_aufsetzen/radvd]]
<pre>
(Username bei NordVPN)
(Password bei NordVPN)
</pre>


Der Tunnel kann nun testweise gestartet werden (hier im Beispiel mit der Konfigurationsdatei se1.nordvpn.com.udp1194.ovpn)
=== DHCP Server ===
<code>
Die automatische Adresszuweisung funktioniert bei IPv4 mit DHCP.
openvpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn &
Es muss ein DHCP Server installiert werden, der die Adressen passend an die Clients verteilt.
</code>


Und sollte aufgebaut werden:
[[Freifunk-Gateway_aufsetzen/DHCP]]
<pre>
Sun Sep 27 09:07:13 2015 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec  1 2014
.
.
.
Sun Sep 27 09:07:15 2015 /sbin/ip link set dev tun0 up mtu 1500
Sun Sep 27 09:07:15 2015 /sbin/ip addr add dev tun0 local 10.8.8.226 peer 10.8.8.225
Sun Sep 27 09:07:18 2015 Initialization Sequence Completed
</pre>


Wenn alles geklappt hat, kann man (sofern openvpn nicht korrekt beim Systemstart geladen wird), den openvpn Tunnel in der /etc/rc.local bei jedem Systemstart laden:
=== DNS Server ===
<code>
Die Clients möchten Domains auflösen können, deshalb ist ein DNS-Server nötig.
vi /etc/rc.local
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. :-)
</code>


und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:
Außerdem können mit einem eigenen (rekursiven) DNS-Server auch die IC-VPN DNS Server erreichbar gemacht werden.
<pre>
# launch vpn with 5 seconds delay
(sleep 5; cd /etc/openvpn ; /usr/sbin/openvpn se1.nordvpn.com.udp1194.ovpn >> /var/log/nordvpn.log &) &
</pre>
Die Beispiel-Konfigurationsdatei (se1.nordvpn.com.udp1194.ovpn) muss entsprechend angepasst werden.


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


Hierfür editieren wir die Datei named.conf.options...
[[Freifunk-Gateway_aufsetzen/DNS]]
<code>
vi /etc/bind/named.conf.options
</code>


...und tragen die DNS Server, die wir anfragen wollen, wenn wir die Information nicht selber haben, als forwarders ein:
=== http Server für Hoodfile ===
<pre>
Das Gateway muss ein aktuelles Hoodfile an Meshknoten ausliefern können. Dafür ist ein HTTP Server nötig.
.
.
.
forwarders  {
              10.50.32.1;
              10.50.32.2;
              8.8.8.8;
            };
allow-query {
              127.0.0.1/8;
              10.0.0.0/8;
            };
.
.
.
</pre>
In diesem Fall werden die Freifunk Gateways ro1 (10.50.32.1) und fff-nue1 (10.50.32.2) der Fürther Hood als auch Google DNS (8.8.8.8) als Forwarders definiert. Für andere Hoods muss die lokale Adresse der Freifunk DNS Server unter [[Portal:Netz]] ermittelt werden (z.B. 10.50.48.1 für ro1 in der Ansbacher Hood).
Darüber hinaus ist es sinnvoll, nur Anfragen zu beantworten, die das Gateway selber stellt (localhost; 127.0.0.1/8) oder die aus dem Freifunk Netz kommen (10.0.0.0/8). Der zugehörige Parameter heißt "allow-query".


Neustart des DNS-Servers mit der neuen Konfiguration:
Dies ist nur nötig, wenn der zentrale keyxchange verwendet wird.
<code>
/etc/init.d/bind9 restart
</code>


[[Freifunk-Gateway_aufsetzen/http]]


Testen können wir, indem wir auf dem Gateway das Gateway selber als DNS-Server eintragen. Das Gateway beantwortet seine DNS-Anfragen quasi selbst. Hierfür kommentieren wir bestehende Nameserver in resolv.conf aus ...
=== Alfred Master (Monitoring) ===
<code>
Die Nodewatcher-Daten aller Knoten werden in einem Alfred Server gesammelt und am Gateway dann gemeinsam ans Monitoring übertragen.
vi /etc/resolv.conf
</code>


...und tragen stattdessen localhost ein:
[[Freifunk-Gateway_aufsetzen/Alfred]]
<pre>
localhost
#nameserver 8.8.8.8
</pre>
 
 
Ein DNS Resolve für freifunk-franken.de ...
<code>
dig freifunk-franken.de
</code>
...sollte von uns selber (Server localhost; 127.0.0.1) beantwortet werden:
<pre>
;; global options: +cmd


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


;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5819
=== ntp Server ===
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1
Ein Dienst, der den Routern die aktuelle Uhrzeit bereitstellt.
;; OPT PSEUDOSECTION:
Ist nicht für jedes Gateway zwingend nötig, es kann auch der NTP eines anderen Gateways verwendet werden.
; EDNS: version: 0, flags:; udp: 4096


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


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


== B.A.T.M.A.N Gateway Selection ==
[[Freifunk-Gateway_aufsetzen/gwinfo]]
In der nächsten Version der Router Firmware (> V0.5) wird voraussichtlich [http://www.open-mesh.org/projects/batman-adv/wiki/Gateways B.A.T.M.A.N Gateway Selection] aktiviert. Der Router wählt sein bevorzugtes Gateway anhand der Verbindungsqualität und dessen noch verfügbaren Bandbreite aus und selektiert das GW für die Clients vor.


Die noch verfügbare Bandbreite muss vom Gateway an die Router annonciert werden. Hierfür muss man vorab die maximal zur Verfügung stehende Up- und Downloadkapazität des Gateways festlegen. Dies kann z.B. unter folgenden Gesichtspunkten geschehen:
=== xlat464 (optional, falls man kein IPv4 mehr in der Backbone routen möchte) ===
* Bandbreite der Netzanbindung (z.B. 100 Mbit/sec, gesplittet in 50 Mbit/sec up/down)
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
* Freier Traffic des Hosters (z.B.: 5 TByte/Monat, entspricht einer Grundlast von 15 Mbit/sec, z.B. gesplittet in 5 Mbit/sec down, 10 Mbit/sec up)
* Erfahrungswerten / eigenes Ermessen
* Bandbreite, bei dem der Gateway Prozessor ausgelastet ist


eventuell muss zuerst bc nachinstalliert werden falls nicht vorhanden:
[[Freifunk-Gateway_aufsetzen/xlat464]]


<code>
= Einbringen des Gateways in die Hood / Keyserver =
apt-get install bc
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>
 
Wir sollten nur die Bandbreite annoncieren, die tatsächlich noch frei ist: Also unsere Gesamtkapazität abzüglich der verwendeten Bandbreite. Hierfür kann man ein Skript verwenden, dass die aktuell verwendete (zeitlich gemittelte) Bandbreite vom Gateway ausliest, mit der Gesamtkapazität vergleicht und die noch freie Bandbreite an die GW Selection weitergibt.
 
Importieren des Skripts aus einer Vorlage:
<code>
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/dyn_announce_gw_bw.sh -P /usr/local/bin/
</code>
 
Alternativ kann das Skript auch als leere Datei erstellt werden:
<code>
touch /usr/local/bin/dyn_announce_gw_bw.sh
</code>
 
Wir machen das Skript ausführbar und öffnen die Datei:
<code>
chmod +x /usr/local/bin/dyn_announce_gw_bw.sh
 
vi /usr/local/bin/dyn_announce_gw_bw.sh
</code>
 
Und Füllen mit Inhalt:
<pre>
#!/bin/bash
 
if [ -z "$1" ]; then
        echo
        echo "usage: $0 <network-interface> <update_interval [sec]> <total BW up [Mbit/sec]> <total BW down [Mbit/sec]>"
        echo
        echo "e.g. $0 eth0 60 10 10"
        echo
        exit
fi
 
while true
do
        # Bandwidth currently used (time averaged)
        R1=$(cat "/sys/class/net/$1/statistics/rx_bytes")
        T1=$(cat "/sys/class/net/$1/statistics/tx_bytes")
        sleep "$2"
        R2=$(cat "/sys/class/net/$1/statistics/rx_bytes")
        T2=$(cat "/sys/class/net/$1/statistics/tx_bytes")
        TkbitPS=$(echo "scale=0; ($T2 - $T1) / 1024 * 8 / $2" | bc -l)
        RkbitPS=$(echo "scale=0; ($R2 - $R1) / 1024 * 8 / $2" | bc -l)
#        echo "BW used      -- up $1: $TkbitPS kBit/s; down $1: $RkbitPS kBit/s"
 
        # Remaining bandwidth available; cut-off negative values
        Tavail_kbitPS=$(echo "scale=0; if (($3 * 1024 - $TkbitPS) >0) ($3 * 1024 - $TkbitPS) else 0" | bc -l)
        Ravail_kbitPS=$(echo "scale=0; if (($4 * 1024 - $RkbitPS) >0) ($4 * 1024 - $RkbitPS) else 0" | bc -l)
#        echo "BW available -- up $1: $Tavail_kbitPS kBit/s; down $1: $Ravail_kbitPS kBit/s"
 
        # Pass calculated figures to B.A.T.M.A.N Gateway Selection
#        echo "batctl gw_mode server ${Ravail_kbitPS}kbit/${Tavail_kbitPS}kbit"
        batctl gw_mode server "${Ravail_kbitPS}kbit/${Tavail_kbitPS}kbit"
done
</pre>
 
Das Skript übernimmt als Parameter:
* Netzwerkinterface, das es zu überwachen gilt (i.d.R. eth0)
* Updateintervall in Sekunden, in denen ein neuer Wert durch die B.A.T.M.A.N GW Selection annonciert wird (Um nicht allzu volatil auf Kurzzeitschwankungen im Durchsatz zu reagieren empfiehlt sich ein Mittelungsintervall zwischen 30 und 120 Sekunden)
* Upload Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)
* Download Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)
 
Ein Aufruf für eth0 als Interface, ein Update alle 120 Sekunden, 12 Mbit/sec maximaler Upload und 10 Mbit/sec maximaler Download wäre z.B.:
<code>
/usr/local/bin/dyn_announce_gw_bw.sh eth0 120 12 10
</code>
 
Um die Gateway Selection beim Systemsstart zu aktivieren, können wir das Skript z.B. in rc.local aufrufen:
<code>
vi /etc/rc.local
</code>


um dort, leicht zeitverzögert, o.a. Befehl einzupflegen, wobei die Parametrisierung noch Gateway-spezifisch angepasst werden muss:
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
<pre>
.
.
.
#enable batman GW selection with 15 seconds delay
(sleep 15; /usr/local/bin/dyn_announce_gw_bw.sh eth0 120 12 10) &
.
.
.
</pre>
 
auf den Routern kann der vorselektierte Gateway mit
 
<code>
cat /sys/kernel/debug/batman_adv/bat0/gateways
</code>
 
angeguckt werden. Ich vermute das der Gateway mit den Pfeil vorne der vorselektierte Gateway ist, allerdings machen erste beobachtete Daten bisher in meinen Augen noch keinen wirklichen Sinn.
 
== DHCP Server ==
Die DHCP Konfiguration kann schon mal vorbereitet werden, sollte aber erst mit als letzter Schritt scharf geschaltet werden. Ein DHCP-Server, der Clients nicht funktionierende DNS-Server oder ein nicht funktionierendes Gateway mitteilt, sperrt diese aus dem Freifunk Netz aus.
 
In isc-dhcp-server definieren wir ...
<code>
vi /etc/default/isc-dhcp-server
</code>
 
... das der DHCP Server für das B.A.T.M.A.N Device Anfragen beantworten soll:
<pre>
.
.
 
INTERFACES="bat0"
.
.
</pre>
 
 
Nachfolge Konfiguration wird in auskommentierter Form vorbereitet und sollte erst im letzten Schritt durch Einkommentieren und durch einen Neustart des DHCP Servers...
<code>
/etc/init.d/isc-dhcp-server restart
</code>
...aktiviert werden.
 
Die Konfiguration wird in dhcpd.conf vorgenommen:
<code>
vi /etc/dhcp/dhcpd.conf
</code>
 
und folgender Konfigurationsblock zunächst auskommentiert eingefügt, wobei Gateway und Hood spezifische Änderungen noch eingepflegt werden müssen:
<pre>
.
.
.
### Freifunk Franken
#option domain-name "freifunk-franken.de";
#option domain-name-servers 10.50.16.1;
#authoritative;
### Fuerth
#subnet 10.50.32.0 netmask 255.255.248.0 {                  # Netzwerk und Netzmaske der Fuerther Hood
#        range 10.50.38.0 10.50.39.254;                    # IP-Range die der DHCP-Server innerhalb der Fuerther Hood verwaltet
#        option routers 10.50.32.5;                        # Default-Gateway, dass Clients mitgeteilt wird
#        option domain-name-servers 10.50.32.5, 10.50.32.1; # Name-Server, die Clients mitgeteilt werden
#}
</pre>
 
Netzwerk und Netzmaske müssen derjenigen der Hood des Gateways entsprechen. Im Beispiel ist dies Fürth, für z.B. Hassberge hieße der Eintrag "subnet 10.50.56.0 netmask 255.255.252.0".
 
Der IP-Bereich (Range), die der DHCP-Server in der Hood verwaltet, wurde zuvor unter [[Portal:Netz]] reserviert.
 
Unter Routers wird den Clients das Default-Gateway mitgeteilt: Das Gateway, über das Clients das Internet oder eine andere Hood erreichen. In unserem Beispiel routet das aufgesetzte Gateway selber via VPN ins Internet oder via olsr (später) in andere Hoods. Als Default-Gateway wird also die eigene statische IP des Gateways, aus der eigenen Hood, die in [[Portal:Netz]] reserviert wurde, verwendet.
 
Ähnlich verhält es sich mit den Nameservern: Auf unserem Gateway wurde ein DNS Server eingerichtet, also kann der domain-name-server unser eigenes Gateway, mit der reservierten statische IP aus der Hood, wie in [[Portal:Netz]], sein. Als Backup empfiehlt sich ein weiterer DNS-Server aus der Hood, in unserem Beispiel ro1 in der Fürther.
 
== GRE-Tunnel zu anderen Gateways ==
Um die einzelnen Hoods miteinander zu verbinden, werden die jeweiligen Gateways über GRE-Tunnel miteinander verbunden. Es reicht dabei nicht, den GRE Tunnel nur auf einem Gateway einzurichten, vielmehr müssen beide zu verbindende Gateways konfiguriert werden. Hierfür muss man mit dem Admin des jeweiligen Tunnelpartners in Kontakt treten => [[Server]].
 
Der GRE-Tunnel wird in /etc/network/interfaces...
<code>
vi /etc/network/interfaces
</code>
 
...mit folgenden noch auf das Gateway anzupassenden Einträgen deklariert:
<pre>
auto <tunnel>
iface <tunnel> inet static
address <Eigene IPv4 (Freifunk Netz)>
pre-up ip -4 tunnel add $IFACE mode gre local <Eigene IPv4 (Internet)> remote <IPv4 des Tunnelpartners (Internet)> ttl 255
#pre-up ip -6 tunnel add $IFACE mode ip6gre local <Eigene IPv6 (Internet)> remote <IPv6 des Tunnelpartners (Internet)> ttl 255
 
up ifconfig $IFACE multicast
pointopoint <IPv4 des Tunnelpartners (Freifunk Netz)>
post-up iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu
post-up ip rule add iif $IFACE table fff
post-up ip rule add from 10.50.0.0/16 table fff
post-up ip rule add to 10.50.0.0/16 table fff
post-down ip rule del iif $IFACE table fff
post-down ip rule del from 10.50.0.0/16 table fff
post-down ip rule del to 10.50.0.0/16 table fff
post-down iptables -t mangle -D POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu
post-down iptunnel del $IFACE
</pre>
 
Der Tunnelname, die Internetadresse beider Tunnelpartner und die Freifunkadresse beider Tunnelpartner  müssen hierbei eingefügt werden. Für GRE-Tunnel wurde der Adressbereich 10.50.252.0/22 in [[Portal:Netz]] reserviert, in denen beiden Tunnelpartnern eine dezidierte IPv4 zugewiesen wird. Das Vorgehen wurde gewählt, um auch Hood-übergreifend Tunnel erstellen zu können. Hier verwendete IP-Adressen '''müssen''' in die Tabelle eingetragen werden und so als belegt gekennzeichnet werden.
 
'''Beispiel:'''
Um als fff-nue1 einen Tunnel zu ro1 aufzubauen, können die IP-Adressen wie folgt gewählt werden:
<pre>
<tunnel>                                  ro1
<Eigene IPv4 (Freifunk Netz)>            fff-nue1      10.50.252.1
<IPv4 des Tunnelpartners (Freifunk Netz)> ro1          10.50.252.0
<Eigene IPv4 (Internet)>                  fff-nue1      31.172.33.99
<IPv4 des Tunnelpartners (Internet)>      ro1          176.126.221.7
</pre>
 
In der Partnerkonfiguration für ro1 werden die Rollen entsprechend vertauscht:
<pre>
<tunnel>                                  fff-nue1
<Eigene IPv4 (Freifunk Netz)>            ro1          10.50.252.0
<IPv4 des Tunnelpartners (Freifunk Netz)> fff-nue1      10.50.252.1
<Eigene IPv4 (Internet)>                  ro1          176.126.221.7
<IPv4 des Tunnelpartners (Internet)>      fff-nue1      31.172.33.99       
</pre>
 
Der Tunnel kann über den Aufruf von
<code>
ifup <tunnel>
</code>
...aufgebaut werden, wobei <tunnel> der Name des GRE-Interfaces ist (im Beispiel ro1)
 
Nach Aufruf von ifconfig..
<code>
ifconfig
</code>
sollten wir einen Eintrag für den Tunnel (in diesem Beispiel ro1) vorfinden:
<pre>
.
.
.
ro1      Link encap:UNSPEC  HWaddr B0-7B-1C-73-30-30-3A-35-00-00-00-00-00-00-00-00 
          inet addr:10.50.252.1  P-t-P:10.50.252.0  Mask:255.255.255.255
          inet6 addr: fe80::200:5efe:b07b:1c73/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1476  Metric:1
          RX packets:160913 errors:0 dropped:0 overruns:0 frame:0
          TX packets:146654 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:66984353 (63.8 MiB)  TX bytes:10675001 (10.1 MiB)
.
.
.
</pre>
 
== OLSR ==
=== Konfiguration ===
Mittels OLSR können die Gateways selbstständig Routinginformationen austauschen. Ähnlich wie B.A.T.M.A.N einzelne Router innerhalb einer Hood vermesht (Level 2 Netz), handelt es sich bei olsr um ein mesh zwischen den Gateways (Level 3). Es ermöglicht ein Freifunk Franken internes Routing: z.B. kann eine beliebige IPv4 aus der Nürnberger Hood von aus der Fürth Hood aus erreicht werden.
 
Vorlagen können unter Sicherung der Originaldateien wie folgt importiert werden:
<code>
mv /etc/default/olsrd /etc/default/olsrd.orig
 
mv /etc/olsrd/olsrd.conf /etc/olsrd/olsrd.conf.orig
 
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/olsrd -P /etc/default/
 
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/olsrd.conf -P /etc/olsrd/
</code>
 
Zunächst zeigen wir die Interfaces an, unter dem wir olsr Routing Informationen austauschen:
<code>
vi /etc/default/olsrd
</code>
 
Im Beispiel wird über die 2 GRE-Tunnel nue1 und ro1 ausgetauscht, dies muss entsprechend der GRE-Tunnel Konfiguration angepasst werden: 
<pre>
.
.
#
# Uncomment the next line run olsrd automatically at startup
#
START_OLSRD="YES"
 
#
# Uncomment the next line to force-configure the wifi interface to be setup
# for ad-hoc mode using the /usr/sbin/olsrd-adhoc-setup script whenever olsrd
# is started.
#
SETUP_ADHOC="NO"
.
.
.
#
# Specify the network interfaces that olsrd will run on, this will most likely
# be your wifi interface.
#
MESH_IF="nue1 ro1"
.
.
</pre>
 
 
Weiter wird dann hier ...
<code>
vi /etc/olsrd/olsrd.conf
</code>
... konfiguriert. 
Da unser Beispiel-Gateway ins Netz der Fürther Hood eingebunden ist, teilen wir dies andern Gateways über den Eintrag 10.50.32.0/21 mit:
<pre>
.
.
.
# HNA IPv4 routes
# syntax: netaddr netmask
# Example Internet gateway:
# 0.0.0.0 0.0.0.0
 
Hna4
{
#  Internet gateway:
#  0.0.0.0      0.0.0.0
#  more entries can be added:
#  192.168.1.0  255.255.255.0
10.50.32.0/21
}
.
.
.
</pre>
 
Hier wird das olsr Webinterface auf port 8080 konfiguriert:
 
<pre>
.
.
.
LoadPlugin "olsrd_httpinfo.so.0.1"
{
  # defaults to 1978
  PlParam "Port" "8080"
  # if you dont set these, the default is to listen only on the loopback device
  #PlParam "Host"  "80.23.53.22"
  #PlParam "Net"    "10.0.0.0 255.0.0.0"
  PlParam "Net" "0.0.0.0 0.0.0.0"
  #PlParam "Host"  "127.0.0.1"
}
.
.
.
</pre>
 
 
Ferner wird der VPN-Tunnel (hier tun0) per persönlich angepasstem ping Kommando auf sein Funktion hin überwacht. Sollte der VPN-Tunnel ausfallen, ermöglicht olsr im Zusammenspiel mit der Routing Priorisierung (s.u) und der OpenVPN Start-/Stop Automatik (s.u.) ein automatisches Re-Routing:
<pre>
.
.
.
LoadPlugin "olsrd_dyn_gw.so.0.5"
{
  # Here parameters are set to be sent to the
  # plugin. Theese are on the form "key" "value".
  # Parameters ofcause, differs from plugin to plugin.
  # Consult the documentation of your plugin for details.
 
  # Example: dyn_gw params
 
  # how often to check for Internet connectivity
  # defaults to 5 secs
  PlParam    "Interval"  "5"
 
  # if one or more IPv4 addresses are given, do a ping on these in
  # descending order to validate that there is not only an entry in
  # routing table, but also a real internet connection. If any of
  # these addresses could be pinged successfully, the test was
  # succesful, i.e. if the ping on the 1st address was successful,the
  # 2nd won't be pinged
  PlParam    "Ping"      "8.8.8.8"
  PlParam    "Ping"      "82.165.230.17"
  PlParam    "pingcmd"    "ping -c 1 -q -I tun0 %s"
}
.
.
.
</pre>
 
Folgender Konfigurationsblock muss ans Ende der Konfigurationsdatei angefügt werden. Es ermöglich olsr die Manipulation der fff-Routingtabelle:
<pre>
.
.
.
# Specify the proto tag to be used for routes olsr inserts into kernel
# currently only implemented for linux
# valid values under linux are 1 .. 254
# 1 gets remapped by olsrd to 0 UNSPECIFIED (1 is reserved for ICMP redirects)
# 2 KERNEL routes (not very wise to use)
# 3 BOOT (should in fact not be used by routing daemons)
# 4 STATIC
# 8 .. 15 various routing daemons (gated, zebra, bird, & co)
# (defaults to 0 which gets replaced by an OS-specific default value
# under linux 3 (BOOT) (for backward compatibility)
#
RtProto 8
#
# Specifies the routing Table olsr uses
# RtTable is for host routes, RtTableDefault for the route to the default
# internet gateway (2 in case of IPv6+NIIT) and RtTableTunnel is for
# routes to the ipip tunnels, valid values are 1 to 254
# There is a special parameter "auto" (choose default below)
# (with smartgw: default is 254/223/224)
# (without smartgw: default is 254/254/254, linux main table)
#
RtTable 10
RtTableDefault 10
RtTableTunnel 10
#
# Specifies the policy rule priorities for the three routing tables and
# a special rule for smartgateway routing (see README-Olsr-Extensions)
# Priorities can only be set if three different routing tables are set.
# if set the values must obey to condition
# RtTablePriority < RtTableDefaultOlsrPriority
# < RtTableTunnelPriority < RtTableDefaultPriority.
# There are two special parameters, "auto" (choose fitting to SmartGW
# mode) and "none" (do not set policy rule)
# (with smartgw: default is none/32776/32776/32796)
# (without smartgw: default is none/none/none/none)
#
# RtTablePriority auto
# RtTableDefaultOlsrPriority auto
# RtTableTunnelPriority auto
# RtTableDefaultPriority auto
</pre>
 
 
Das Freifunk Franken intere Routing kann nun getestet werden.
 
Zunächst einmal starten wir olsr neu:
<code>
/etc/init.d/olsrd restart
</code>
 
 
Die Routinginformationen des olsr-meshes sollten in der fff-Routingtabelle auftauchen:
<code>
ip route show table fff
</code>
 
Exemplarischer Auszug:
<pre>
.
.
.
10.50.32.1 via 10.50.32.1 dev ro1  proto gated  metric 2 onlink
10.50.32.2 via 10.50.32.2 dev nue1  proto gated  metric 2 onlink
10.50.40.0/21 via 10.50.32.1 dev ro1  proto gated  metric 2 onlink
.
.
.
</pre>
 
 
Eine IP4 aus der Nürnberger Hood (10.50.40.0/21) sollte z.B. von Fürth aus (10.50.32.0/21) erreichbar sein:
 
<code>
ping 10.50.40.1
</code>
 
Antwort:
<pre>
PING 10.50.40.1 (10.50.40.1) 56(84) bytes of data.
64 bytes from 10.50.40.1: icmp_seq=1 ttl=64 time=12.7 ms
64 bytes from 10.50.40.1: icmp_seq=2 ttl=64 time=12.4 ms
^C
--- 10.50.40.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 12.414/12.572/12.731/0.194 ms
</pre>
 
=== OpenVPN Start/Stop Automatik ===
 
OLSR testet mit dem Dynamic Gateway Plugin, ob die Default Route über den OpenVPN Tunnel noch funktioniert, indem regelmässig teilweise mehrere verschiedene Ziele über den Tunnel angepingt werden. Sollte der OpenVPN Tunnel nicht mehr funktionieren, baut OLSR eine neue Default-Route zu einem anderem Gateway auf, über das dann der Internet-Traffic läuft. Beide Default-Routen, die über den OpenVPN Tunnel und die von OLSR, existieren parallel, wobei zunächst weiterhin die OpenVPN Verbindung verwendet wird.
 
Da die OpenVPN Verbindung ausgefallen ist, aber trotzdem noch als bevorzugte Default-Route eingetragen ist, ist die Internetanbindung bis die Störung VPN-Server seitig behoben ist, trotzdem nicht verfügbar.
 
Für diesen Anwendungsfall wird ein Skript vorgeschlagen, dass die Funktion des OpenVPN Tunnels überwacht und den Tunnel (und die OpenVPN Default-Route) bei Nicht-Funktion abbaut. Um die Funktion zu überprüfen werden in regelmässigen Abständen 2 verschiedene Ziele über den Tunnel angepingt. Scheitert dies, wird der Tunnel für einen gewissen Zeitraum abgebaut, in dem dann stattdessen das OLSR Dynamic Gateway Plugin das Routing übernimmt. Danach wird die Verbindung wieder aufgebaut.  Anschliessend wird überprüft, ob der OpenVPN-Tunnel wieder funktioniert. Tut er es nicht, wird er wieder abbgebaut, funktioniert er, bleibt er bis zur Detektion der nächsten Störung als Internetanbindung erhalten.
 
Man importiert die Vorlage:
<code>
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/auto_start-stop_ovpn.sh -P /usr/local/bin/
</code>
 
Alternativ kann man statt der Vorlage auch eine leere Datei anlegen:
<code>
touch /usr/local/bin/auto_start-stop_ovpn.sh
</code>
 
Man macht das Skript ausführbar:
<code>
chmod +x /usr/local/bin/auto_start-stop_ovpn.sh
</code>
 
 
Nun öffnet man die Datei im Editor ...
<code>
vi /usr/local/bin/auto_start-stop_ovpn.sh
</code>
 
... und füllt sie mit Inhalt oder editiert den importierten Inhalt:
<pre>
#!/bin/bash
IF="tun0"                            # Interface used for ping
ping1_target="8.8.8.8"              # IP no. 1 used for ping
ping2_target="82.165.229.31"        # IP no. 2 used for ping
ping_interval="5"                    # waiting time in-between two pings
switchback_interval="3600"          # waiting time for interface to recover before probing again
start_grace="10"                    # waiting time to allow for tunnel restart
logfile="/dev/null"                  # logfile for debug
 
openvpn_stop-cmd () {                # command used disabling tunnel
    #service openvpn stop            # ubuntu
    /etc/init.d/openvpn stop        # debian
    #killall openvpn                  # hardcore
}
 
openvpn_start-cmd () {                # command used enabling tunnel
    #service openvpn start            # ubuntu
    /etc/init.d/openvpn start        # debian
    #openvpn /etc/openvpn/*.conf &    # hardcore
}
 
ping1 () {
    echo "$(date): ping -q -c 3 -i ${ping_interval} ${ping1_target} -I $IF" &>> $logfile
    ping -q -c 3 -i ${ping_interval} ${ping1_target} -I $IF &>> $logfile
    ping1_ExitCode=$?
    echo "$(date): Exit Status: ${ping1_ExitCode}" &>> $logfile
}
 
ping2 () {
    echo "$(date): ping -q -c 3 -i ${ping_interval} ${ping2_target} -I $IF" &>> $logfile
    ping -q -c 3 -i ${ping_interval} ${ping2_target} -I $IF &>> $logfile
    ping2_ExitCode=$?
    echo "$(date): Exit Status: ${ping2_ExitCode}" &>> $logfile
}
 
 
while true
do
    # wait for interface build-up, if interface not present
    if [ ! -h "/sys/class/net/$IF" ]; then
        echo "$(date): Interface $IF not detected. Waiting ${start_grace} seconds." &>> $logfile
        sleep ${start_grace}
    fi
 
    # perform ping
    ping1
    ping2
 
    # check if ping successful
    if ([[ ${ping1_ExitCode} -eq 0 ]] || [[ ${ping2_ExitCode} -eq 0 ]]); then
        sleep ${ping_interval}
    else
        logger -t "$0" ${ping1_target} and ${ping2_target} not reached via interface $IF.
        echo "$(date): ${ping1_target} and ${ping2_target} not reached via interface $IF." &>> $logfile
 
        if [ -h "/sys/class/net/$IF" ]; then
            logger -t "$0" Stopping interface $IF.
            echo "$(date): Stopping interface $IF." &>> $logfile
            openvpn_stop-cmd &>> $logfile
        fi
 
        sleep ${switchback_interval}
 
        if [ ! -h "/sys/class/net/$IF" ]; then
            logger -t "$0" Restoring interface $IF to probe for recovery.
            echo "$(date): Restoring interface $IF to probe for recovery." &>> $logfile
            openvpn_start-cmd &>> $logfile
        fi
    fi
done
</pre>
 
Hierbei können im Skript folgende Anpassungen vorgenommen werden:
*openvpn_stop-cmd: Der Befehl, mit dem der OpenVPN Tunnel '''abgebaut''' wird. Sollte dies auf dem normalen Weg nicht funktionieren, kann er alternativ als Prozess gekillt werden.
*openvpn_start-cmd: Der Befehl, mit dem der OpenVPN tunnel '''aufgebaut''' wird. Sollte dies auf dem normalen Weg nicht funktionieren, kann er alternativ per openvpn Kommandozeilenaufruf gestartet werden.
*IF: Das OpenVPN Tunnel Device. Normalerweise ist das tun0.
*ping1_target,ping2_target: Die IP-Adressen die über das Tunnel-Interface IF angepingt werden, um den Tunnel auf Funktion zu überprüfen. Vorauswahl: Google DNS und Web.de
*ping_interval: Der zeitliche Anstand zwischen zwei Ping-Versuchen. Vorauswahl: 5 Sekunden.
*switchback_interval: Der Zeitraum, den der Tunnel abgebaut bleibt, sollte er als nicht-funktionierend erkannt worden sein. Es wird ein träges Verhalten empfohlen. Vorauswahl: 3600 Sekunden.
*start_grace: Der Zeitraum, der dem Tunnel zum Starten eingeräumt wird. Die Timer-Funktion macht ferner das Skript gegen Restarts des Tunnels unempfindlich.
*logfile: Für Debug Zwecke kann man detaillierte Ausgaben hier in eine Datei umleiten.
 
Das Skript selber kann manuell ...
<code>
auto_start-stop_ovpn.sh &
</code>
 
...und bei jedem Systemstart mit gestartet werden, indem es z.B. in /etc/rc.local ...
<code>
vi /etc/rc.local
</code>
 
...wie folgt eingetragen wird:
<pre>
.
.
.
#enable tunnel monitoring with 60 seconds delay
(sleep 60; auto_start-stop_ovpn.sh &) &
.
.
.
</pre>
 
 
Getestet werden kann das Skript z.B., indem man sich alle Default-Routen der fff-Tabelle anzeigen lässt:
<code>
watch "ip route show table fff | grep default"
</code>
 
und parallel dazu auf einer zweiten Shell das openvpn deaktiviert:
<code>
killall openvpn
</code>
 
Es sollte eine neue Default-Route zu einem anderen Gateway aufgebaut werden, über die der Internet-Traffic dann läuft. Die Route über den OpenVPN Tunnel sollte verschwinden. Nach der eingestellten Zeit wird der OpenVPN Tunnel durch das Skript wieder reaktiviert. Danach existieren beide Default-Routen parallel, bis OLSR seine Route automatisch wieder abbaut. Die OpenVPN Default-Route bleibt und ist wieder aktiv.
 
=== Priorisieren von OLSR Routen ===
OLSR erstellt die fff-Routingtabelle selbstständig, indem es die Linkqualität anhand von Algorithmen bewertet. Diese Bewertung ist recht volatil, was dazu führen kann, das die von OLSR ausgesuchte Default-Route häufig wechselt. Für die verbundenen Clients wechselt jedes mal die externe Internet IP mit, je nachdem über welches Gateway OLSR den Internet-Traffic gerade abwirft. Bei IP-Wechsel stoppen z.B. Downloads aus dem Internet, stoppen Videos im Abspielen, werden ssh Verbindungen gekappt.
 
Um diese Dynamik nicht allzu schnell zu gestalten, empfiehlt es sich OLSR eine oder zwei Default-Routen mitzuteilen, die bevorzugt verwendet werden. Zusätzlich wird  NatThreshold, ein Schwellwert den neue die Default-Route besser sein muss als die alte bevor gewechselt wird, definiert.
 
Dies geschieht über Gewichtungsfaktoren in olsrd.conf:
 
<code>
vi /etc/olsrd/olsrd.conf
</code>
 
Routen kann man im Abschnitt InterfaceDefaults priorisieren:
<pre>
.
.
.
  # If a certain route should be preferred
  # or ignored by the mesh, the Link Quality
  # value of a node can be multiplied with a factor
  # entered here. In the example the route
  # using 192.168.0.1 would rather be ignored.
  # A multiplier of 0.5 will result in a small
  # (bad) LinkQuality value and a high (bad)
  # ETX value.
 
  # preferred link
  LinkQualityMult <tunnel1_ip> 0.99
 
  # preferred link
  LinkQualityMult <tunnel2_ip> 0.99
 
  # This multiplier applies to all other nodes
  LinkQualityMult default 0.7
.
.
.
</pre>
 
Hier können Gewichtungsfaktoren für die GRE-Tunnel zu anderen Gateways eingeführt werden, mit denen die Link-Qualität beeinflusst werden kann.
 
Im Beispiel werden alle Routen herabgestuft (Faktor 0.7), mit der Ausnahme derer die über <tunnel1_ip> oder <tunnel2_ip> laufen (Faktor 0.99). <tunnel_ip1> sind dabei die Point-to-Point Partner IPs der GRE Tunnel der jeweiligen Gateways im Freifunk Netz. Die nicht herabgestuften Routen können analog als priorisiert betrachtet werden. Für eine Priorisierung der Route von nue1 zu ro1 wäre die <tunnel1/2_ip> z.B.  die 10.50.252.1 (Vgl. [[Portal:Netz]]).
 
NatThreshold wird im Hauptabschnitt von olsrd.conf definiert:
<pre>
.
.
  # If the NAT-Endpoint (the preferred 0/0 HNA emitting node)
  # is to be changed, the ETX value of the current 0/0 is
  # multiplied with the NatThreshold value before being
  # compared to the new one
  # The parameter can be a value between 0.1 and 1.0, but
  # should be close to 1.0 if changed.
 
  NatThreshold 0.7
.
.
</pre>
 
Im Beispiel muss die Linkqualität der neuen Default-Route muss um 30% besser bewertet als die aktuelle sein, bevor die Default-Route gewechselt wird.
 
Die Änderungen werden nach Neustart von OLSR aktiv:
<code>
/etc/init.d/olsrd restart
</code>
 
= 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.
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
= Transparent Proxy =
* nf_conntrack
Auf dem Gateway kann (aber muss nicht) ein Proxy-Server installiert werden, der Dateien (z.B. Bilder), die schon mal angefragt wurden, nicht aus dem Internet holt, sondern als "lokal" gespeicherte Datei direkt vom Gateway bereitstellt. Die Clients werden dabei über den Proxy gezwungen, d.h. das Gateway leitet die Anfragen pauschal an den Proxy weiter, welcher entscheidet ob der die Anfrage selber bedient oder Gateway-extern anfragt.
[[Freifunk-Gateway_aufsetzen/Optimierungen]]
 
Die Einrichtung eines Proxys ist '''optional''', d.h. der Proxy ist für die Funktion des Gateways nicht notwendig. Proxy-Server reduzieren Antwortzeiten und Traffic für sich '''häufig''' wiederholende Anfragen (z.B. Spiegel Online, Windows Update).
 
== Installation ==
Installiert wird der de-facto-Standard squid:
<code>
apt-get install squid3
</code>
 
Für die kommende Konfiguration stoppen wir squid wieder:
<code>
/etc/init.d/squid3 stop
</code>
 
== Konfiguration ==
Die mit installiere Konfigurationsdatei squid.conf ist sehr umfangreich und bietet eine gute Dokumentationsbasis, ist damit aber auch etwas unhandlich.
 
Aus diesem Grund empfiehlt es sich, die Datei umzubenennen:
<code>
mv /etc/squid3/squid.conf /etc/squid3/squid.conf.orig
</code>
 
Wir importieren die Datei von einer Vorlage:
<code>
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/squid.conf -P /etc/squid3/
</code>
 
Alternativ können wir die Datei auch leer erstellen:
<code>
touch /etc/squid3/squid.conf
</code>
 
Danach öffnen wir die Konfigurationsdatei...
<code>
vi /etc/squid3/squid.conf
</code>
 
...und füllen diese mit Inhalt, der allerdings noch auf das Gateway angepasst werden muss:
<pre>
# cache size in MB / no. of subdirectories / no. of subsubdirectories
cache_dir ufs /var/spool/squid3 100 16 256
 
#maximum object size in cache (default: 4 MB)
#maximum_object_size 128 MB
maximum_object_size 4 MB
 
# Memory used for caching
cache_mem 32 MB
 
# No access log
#access_log /var/log/squid3/access.log combined
access_log none
 
# Hostname shown in messages
visible_hostname fff
 
# Bind Squid to port ... and configure as transparent proxy
http_port 3128 intercept
# In addition a forward proxy is required
http_port 3129
 
refresh_pattern ^ftp:          1440    20%    10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0    0%      0
refresh_pattern .              0      20%    4320


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


# DNS by Freifunk-IP of localhost and Google DNS
== MRTG ==
dns_nameservers 10.50.32.5 8.8.8.8
[[Freifunk-Gateway_aufsetzen/Statistik/mrtg|Statistik MRTG]]


# Bind outgoing address to Freifunk-Server IP to allow for VPN Routing
= Fehlersuche =
tcp_outgoing_address 10.50.32.5
Zum finden von Fehlern, die erst Auftreten, wenn die Konfiguration schon einmal funktioniert hat, kann folgende Seite hilfreich sein:
udp_outgoing_address 10.50.32.5


# Privacy options                 
[[Freifunk-Gateway_aufsetzen/Fehlersuche]]
via off
forwarded_for delete


# standard http anonymizer
= Einzelne IPs oder Services über anderen Server routen =
request_header_access From deny all
#request_header_access Referer deny all
#request_header_access User-Agent deny all


## paranoid http anonymizer
wird fast nie benötigt, war für mich aber immer ein schönes Nachschlagewerk deshalb lass ich das ganz unten stehen:
#request_header_access Authorization allow all
#request_header_access Proxy-Authorization allow all
#request_header_access Cache-Control allow all
#request_header_access Content-Length allow all
#request_header_access Content-Type allow all
#request_header_access Date allow all
#request_header_access Host allow all
#request_header_access If-Modified-Since allow all
#request_header_access Pragma allow all
#request_header_access Accept allow all
#request_header_access Accept-Charset allow all
#request_header_access Accept-Encoding allow all
#request_header_access Accept-Language allow all
#request_header_access Connection allow all
#request_header_access All deny all


# Access controls
[[Freifunk-Gateway_aufsetzen/spezielles_routing]]
acl SSL_ports port 443          # https
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443        # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210        # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280        # http-mgmt
acl Safe_ports port 488        # gss-http
acl Safe_ports port 591        # filemaker
acl Safe_ports port 777        # multiling http


acl CONNECT method CONNECT
[[Kategorie:Technik]]
http_access deny !Safe_ports
[[Kategorie:Hoods-V2]]
http_access deny CONNECT !SSL_ports
[[Kategorie:Gateways]]
http_access allow localhost manager
http_access deny manager
http_access allow fff
http_access allow localhost
http_access deny all
</pre>
 
Hier '''müssen''' angepasst werden:
* cache_dir: Die Gesamtgröße des Caches (hier: 100 MByte) muss so bemessen sein, dass auf der Partition auch bei Maximalgröße des Caches noch Speicher frei bleibt. Squid Standardeinstellung ist 100 MB bei 16 Verzeichnissen und jeweils 256 Unterverzeichnissen. Freier Speicherplatz kann mit "df -h" ermittelt werden.
* dns_nameservers: Hier sollten die '''Freifunk-IPv4''' des Gateways (in diesem Beispiel 10.50.32.5) und eine externe IP (hier Google DNS 8.8.8.8) eingetragen werden. Wichtig ist, '''nicht localhost''' einzutragen, da die Anfrage im Zusammenspiel mit der "outgoing address" (s.u.) über die fff-Routingtabelle laufen muss.
* tcp_outgoing_address und udp_outgoing_address: Diese beide Einträge sind elementar wichtig. Zwar funktioniert der Proxy auch ohne, routet aber nicht über das VPN sondern direkt vom Gateway ins Internet. Damit die fff-Routingtabelle verwendet wird, für die als Default-Gateway eine VPN Verbindung eingerichtet ist, tragen wir hier die Freifunk-IP des Gateways ein (10.50.<irgendwas>). In diesem Beispiel ist die Freifunk-IPv4 des Gateways die 10.50.32.5.
* access_log: Das Access log sollte deaktiviert bleiben (access_log none), da es ein lebendiges Beispiel für Vorratsdatenspeicherung ist und die log-Dateien auch sehr schnell, sehr groß werden.
 
Danach erstellen wir die Verzeichnisstruktur des Proxy:
<code>
squid3 -z
</code>
 
Jetzt sind wir fast fertig. Wir starten den Proxy:
<code>
/etc/init.d/squid3 start
</code>
 
Anfragen, die auf Port 80 (http) reinkommen, müssen nun noch auf Port 3128 umgeleitet werden. Auf Port 3128 lauscht unser Proxy, http-Anfragen werden quasi transparent (oder zwangsweise) über den Proxy geleitet :
<code>
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128
</code>
 
Damit unsere Portumleitung mit jedem Start von Squid eingerichtet und mit jedem Stopp aufgehoben wird, pflegen wir sie (nicht ganz sauber) im squid start/stop Skript mit ein:
<code>
vi /etc/init.d/squid3
</code>
 
und fügen '''zwei''' iptables Einträge nach dem Start und vor dem Stopp von Squid ein:
<pre>
.
.
.
start () {
cache_dir=`find_cache_dir cache_dir`
cache_type=`grepconf cache_dir`
 
#
# Create run dir (needed for several workers on SMP)
#
create_run_dir
 
#
# Create spool dirs if they don't exist.
#
if test -d "$cache_dir" -a ! -d "$cache_dir/00"
then
log_warning_msg "Creating $DESC cache structure"
$DAEMON -z -f $CONFIG
fi
 
umask 027
ulimit -n 65535
cd $cache_dir
start-stop-daemon --quiet --start \
--pidfile $PIDFILE \
--exec $DAEMON -- $SQUID_ARGS < /dev/null
        # Use as transparent proxy
        iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128
return $?
}
 
stop () {
PID=`cat $PIDFILE 2>/dev/null`
        # Use as transparent proxy
        iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128
start-stop-daemon --stop --quiet --pidfile $PIDFILE --exec $DAEMON 
#
# Now we have to wait until squid has _really_ stopped.
#
.
.
.
</pre>

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

Abgerufen von „https://wiki.freifunk-franken.de/mediawiki/index.php?title=Freifunk-Gateway_aufsetzen&oldid=20656“
Creative Commons „Namensnennung, Weitergabe unter gleichen Bedingungen“
Powered by MediaWiki