Freifunk-Gateway aufsetzen: Unterschied zwischen den Versionen
(Referenzen verschoben) |
(Beschreibung der verwendeten Dienste hinzugefügt) |
||
| Zeile 123: | Zeile 123: | ||
* [http://www.wrzhost.com/ WRZhost] | * [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. | ** 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. | ||
= Dienste = | |||
== B.A.T.M.A.N. == | |||
B.A.T.M.A.M. wird bei uns als Layer2 Routing-Protokoll (Ja, klingt kaputt. Ist es auch) eingesetzt, um WLAN-Mesh zu ermöglichen. | |||
Für Linux gibt es dafür das B.A.T.M.A.N. Advanced Kernel-Modul. | |||
Die Version, die beim Kernel von Debian Stretch mit dabei ist (v2016.4) ist Compat15, was die aktuell verwendete Compat-Version ist. (siehe [https://www.open-mesh.org/projects/batman-adv/wiki/Compatversion hier]) | |||
Wenn man möchte, kann man sich die aktuellste Version aus dem Open-Mesh Git kompilieren und installieren. | |||
'''Hinweis''': Wird der Kernel aktualisiert, müssen alle selbstkompilierten Kernelmodule erneut gegen die aktualisierte Kernelversion gebaut und danach installiert werden! Folglich muss ein selbstkompiliertes batman_adv nach jedem Kernelupdate neu gebaut und installiert werden. Für den Anfang empfiehlt es sich, mit dem mitgelieferten batman_adv zu arbeiten. | |||
Das Kernel-Modul kann testweise mit folgendem Befehl geladen werden: | |||
<code> | |||
modprobe batman-adv | |||
</code> | |||
Im Kernel Log sollte das Laden protokolliert werden: | |||
<pre> | |||
~# dmesg | grep batman_adv | |||
batman_adv: B.A.T.M.A.N. advanced 2018.0 (compatibility version 15) loaded | |||
</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 der Eintrag "batman-adv" hinzugefügt wird: | |||
<pre> | |||
batman-adv | |||
</pre> | |||
B.A.T.M.A.N. Advanced wird mit dem Tool batctl gesteuert. Das muss entsprechend installiert werden. Hier kann ebenfalls die Version aus den Debian Paketquellen oder die selbstkompilierte verwendet werden. | |||
<code> | |||
apt install batctl | |||
</code> | |||
<br> | |||
== FastD == | |||
Die Verbindung zwischen Gateway und zentralen Routern wird über einen fastd-Tunnel realisiert. | |||
Die fastd-Version aus den Stretch Paketquellen ist aktuell und kann (und sollte) verwendet werden. | |||
<code> | |||
apt install fastd | |||
</code> | |||
== Babel == | |||
Innerhalb von Freifunk Franken wird Babel als IP-Routingprotokoll verwendet. Damit sind alle Gateways und damit alle Hoods miteinander verbunden. | |||
Für Linux kann babeld aus den Stretch Paketquellen als Daemon für Babel verwendet werden. | |||
<code> | |||
apt install babeld | |||
</code> | |||
Auch hier gilt wieder: Die Version aus den Debian Paketquellen ist nicht super aktuell, in babeld-1.8.0 gab es einige Änderungen.<br> | |||
Auch babeld kann selbst kompiliert werden. Sourcen gibts [https://github.com/jech/babeld hier] | |||
babeld importiert und exportiert alle Routen in/aus einer Routingtabelle. Es bietet sich an, für fff eine neue Tabelle anzulegen und zu benennen. Dazu Tabellennummer und Name in /etc/iproute2/rt_tables eintragen: | |||
<pre> | |||
10 fff | |||
</pre> | |||
== Tunnel für den Backbone == | |||
TODO | |||
| Zeile 314: | Zeile 382: | ||
</code> | </code> | ||
<br> | <br> | ||
Version vom 11. August 2018, 13:25 Uhr
Preface
Für das Aufsetzen eines Freifunk-Gateway gibt es kein universelles Kochrezept. Auch erfahrene Admins erfahren bei der Installation kleinere und grössere Herausforderungen, die es zu überwinden gilt. Unterschiedliche Softwareinstallationen, Netzwerkkonfigurationen, Hoster und VPN Anbieter können Anpassungen zu der hier präsentierten Vorgehensweise notwendig werden lassen, z.B. indem Pakete nach installiert werden oder Netzwerkkonfigurationen angepasst werden müssen. Um dies zu erleichtern, versucht der Artikel nicht nur die Konfiguration darzulegen, die in diesem spezifischen Fall funktioniert hat ("Know-How"), sondern versucht auch kurz auf die Hintergründe einzugehen, um ggf. eine Anpassung zu erleichern ("Know-Why").
Freifunk Franken ist "Development in Progress", d.h. eine Konfiguration die heute funktioniert, wird morgen durch eine andere und vielleicht sogar bessere abgelöst. Ein einmal aufgesetztes Gateway muss sich so der Entwicklung anpassen.
Für Rat und Tat empfiehlt sich die Freifunk Franken Development und die Freifunk Franken Gateway Mailingliste.
Zum den Änderungen vom KeyxchangeV1 zum KeyxchangeV2 Gateway geht's hier: https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/keyxchangev2
Referenzen / Andere Freifunk HowTo's
- http://wiki.freifunk.net/Freifunk_Hamburg/Gateway
- http://wiki.mag.lab.sh/wiki/Freifunk_Fulda/Gateway
Voraussetzungen
Was der Server können muss
- Öffentliche IPv4 und IPv6 Adresse
- Kernelmodule laden
- Nur relativ wenig CPU und RAM nötig
- dafür relativ viel Traffic (Je nach Größe und Anzahl der Hoods durchaus im ein- bis niedrigen zweistelligen TB Bereich)
Was der Betreiber mitbringen sollte
- Grundlegende Kenntnisse mit IP-Routing (IPv4 und IPv6)
- Motivation, etwas [jede Menge] dazuzulernen und sich aktiv mit der Materie auseinanderzusetzen.
- Das Freifunk Netz ist der optimale Ort, um sich in dieser Richtung neue Kentnisse anzueignen - so man sich denn auch damit (und. v.a. mit den auftretenden Problemen) auseinanderzusetzen
- Es gibt viele nette Leute im IRC, die immer gerne helfen, wenn die Motivation da ist, sich auch selbst mit dem Problem zu befassen.
- Ohne Vorkenntnisse ist es schwierig aber ganz und gar nicht unmöglich ein Gateway aufzusetzen. Soweit es nicht bei dem Kenntnissstand bleiben soll, wird auch hier gerne geholfen.
Was das Gateway können muss
- fastd VPN
- Batman (Compat15)
- DHCP
- Router Advertisements
- Routing
- Babel Routing Protokoll
- Webserver für Hoodfiles
Näheres ist unter Dienste beschrieben.
Anonymisierung (Störerhaftung)
Sofern der Server nicht über einen Uplink verfügt, wo es egal ist was durchgeht (unseriöse Bulletproof-Hoster), möchte man vermutlich den Traffic aus dem Freifunk-Netz durch ein VPN ins Internet schieben.
Auf längere Sicht, wäre es natürlich wünschenswert, wenn die Problematik der Störerhaftung in ihrer derzeitigen Form wegfällt um beispielsweise eine dezentralere Infrastruktur zu erlauben.
Folgende VPN-Anbieter sind zu diesem Zeitpunkt jedoch empfehlenswert:
- Mullvad (Schweden, Niederlande)
- Bis zu drei gleichzeitige Verbindungen
- Kann man anonym mit Bitcoin bezahlen
- Serverauswahl über die ausgelieferte OpenVPN-Konfiguration
- Server in den Niederlanden sind abends oft stark ausgelastet
- (Gute Erfahrungen in Lübeck)
- Integrity VPN (Schweden, Port80)
- Drittes Oktett durch Auswahl des normalerweise per round.robin-dns ausgewählten OpenVPN-Servers bestimmbar, das letzte Oktett ist immer gleich. Somit muss man sich keine dynamisch vergebenen IP-Adressen mit anderen teilen. Verbindungen daher durch die Anzahl der OpenVPN-Server (derzeit 3; unterschiedliche Ports nicht ausprobiert) beschränkt.
- Hat eine überaus seriöse Webseite und eine Ltd. erfunden.™
- Hat schon mal was von IPv6 gehört. Nutzt es zurzeit jedoch nur für SEO.
- Blockiert Port 25 derzeit nicht.
- Ist ein ein neuer Anbieter, der _bisher_ unausgelastet wirkt.
- sind derzeit noch nicht nicht overselled und haben ihren Krams scheinbar halbwegs sauber konfiguriert
- Ipredator (Schweden, Niederlande, Deutschland)
- (Glänzen nicht durch Kompetenz, da sie lange Zeit nur PPTP angeboten haben)
- Mögen schnelle Reconnects nicht -> manchmal muss man OpenVPN ein paar Stunden deaktivieren, bevor es wieder funktioniert.
- Möchten bald auch IPv6 anbieten.
- Angeblich Reseller von relakks
- Cyberghost
- blockt alle SMTP Ports!!
- Perfect Privacy
- AzireVPN
Ungetestet:
- Anonine VPN (Portlane)
- privacy.io (Portlane)
- prq.se (Eigenes Netz, teuer)
- Arethusa VPN (Loggen in Frankreich, andere Server angeblich nicht)
Anbindung an andere Netze
Es gibt drei relativ relevante Netzwerke bei denen es sich lohnt, das lokale Netz damit zu verbinden:
- InterCity-VPN zwischen den meisten Freifunknetzen
- BGP
- kleine Übsicht der http://www.ddmesh.de/topology/ic-vpn-verbindungen.html
- Mehr Infos http://wiki.freifunk.net/IC-VPN
- DN42
- BGP
- Experimentelles Darknet zur Erprobung von Routing-Technologien und so weiter, wird privat betrieben. Viel interessantes Zeugs™
- Hat Routen ins ChaosVPN und IC-VPN,
wer faul ist bei der Konfiguration deckt damit also alles™ab nicht alle Routen vom IC-VPN oder ChaosVPN werden im DN42 verteilt, ob man das will kann ggf nochmal besprechen.
- ChaosVPN
- Tinc
- Relativ großes „Darknet“ zwischen vielen Hackerspaces auf der ganzen Welt.
Server-Anbieter die empfehlenswert sind
- de-punkt (Databurg, FFM)
- Schneller Speicher, gut bezahlbar, KVM, nur Traffic-Flat™® das übliche.
- Hetzner (Falkenstein)
- 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.
- colorhost (über 23media, Global Switch, FFM)
- Untersagt Nutzung für Freifunk (http://colorhost.de/server/vserver/kvm/small/)
- Achtung: Nur Xen oder Xen HVM funktionieren
- xirra (Core-Backbone, NBG)
- KVM, TB-Traffic zu 5,95€. Langweilig und funktioniert. Pflegt bisher einen guten Kontakt zu Kunden.
- BuyVM
- Begrenztes Angebot, das in Stößen rausgegeben wird. 2.50$/TB Extratraffic. Nur KVM ist brauchbar für diesen Zweck. USA Ost- und Südküste. TOS sagt, dass man da theoretisch kein weiteres VPN ins Netz brauchen würde.
- webhod
- 9,99 € für die kleinste KVM im Monat[1]
Server-Anbieter die nicht empfehlenswert sind
- WRZhost
- Aktivierung des V-Servers erst auf mehrfache Nachfrage, anschließend falsches Betriebssystem. Außerdem nur OpenVZ und somit nicht für FreiFunk nutzbar. Für andere Zwecke sicher brauchbar, da gut angebunden und offshore.
Dienste
B.A.T.M.A.N.
B.A.T.M.A.M. wird bei uns als Layer2 Routing-Protokoll (Ja, klingt kaputt. Ist es auch) eingesetzt, um WLAN-Mesh zu ermöglichen. Für Linux gibt es dafür das B.A.T.M.A.N. Advanced Kernel-Modul.
Die Version, die beim Kernel von Debian Stretch mit dabei ist (v2016.4) ist Compat15, was die aktuell verwendete Compat-Version ist. (siehe hier)
Wenn man möchte, kann man sich die aktuellste Version aus dem Open-Mesh Git kompilieren und installieren.
Hinweis: Wird der Kernel aktualisiert, müssen alle selbstkompilierten Kernelmodule erneut gegen die aktualisierte Kernelversion gebaut und danach installiert werden! Folglich muss ein selbstkompiliertes batman_adv nach jedem Kernelupdate neu gebaut und installiert werden. Für den Anfang empfiehlt es sich, mit dem mitgelieferten batman_adv zu arbeiten.
Das Kernel-Modul kann testweise mit folgendem Befehl geladen werden:
modprobe batman-adv
Im Kernel Log sollte das Laden protokolliert werden:
~# dmesg | grep batman_adv batman_adv: B.A.T.M.A.N. advanced 2018.0 (compatibility version 15) loaded
Das Kernelmodul von B.A.T.M.A.N. kann dann bei jedem Neustart des Systems geladen werden, indem in die Datei /etc/modules der Eintrag "batman-adv" hinzugefügt wird:
batman-adv
B.A.T.M.A.N. Advanced wird mit dem Tool batctl gesteuert. Das muss entsprechend installiert werden. Hier kann ebenfalls die Version aus den Debian Paketquellen oder die selbstkompilierte verwendet werden.
apt install batctl
FastD
Die Verbindung zwischen Gateway und zentralen Routern wird über einen fastd-Tunnel realisiert.
Die fastd-Version aus den Stretch Paketquellen ist aktuell und kann (und sollte) verwendet werden.
apt install fastd
Babel
Innerhalb von Freifunk Franken wird Babel als IP-Routingprotokoll verwendet. Damit sind alle Gateways und damit alle Hoods miteinander verbunden.
Für Linux kann babeld aus den Stretch Paketquellen als Daemon für Babel verwendet werden.
apt install babeld
Auch hier gilt wieder: Die Version aus den Debian Paketquellen ist nicht super aktuell, in babeld-1.8.0 gab es einige Änderungen.
Auch babeld kann selbst kompiliert werden. Sourcen gibts hier
babeld importiert und exportiert alle Routen in/aus einer Routingtabelle. Es bietet sich an, für fff eine neue Tabelle anzulegen und zu benennen. Dazu Tabellennummer und Name in /etc/iproute2/rt_tables eintragen:
10 fff
Tunnel für den Backbone
TODO
Grundinstallation des Servers
Vom ausgesuchten Hoster lassen wir uns eine aktuelle Linux-Distribution installieren oder ausliefern, wobei sich die Anleitung auf ein Debian 8 / Jessie bezieht.
Repositories und Update
Als erstes werfen wir einen Blick in...
vi /etc/apt/sources.list
...und schauen, inwieweit auf die gleichen Software-Repositories verwiesen wird:
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
Danach bringen wir das System auf einen aktuellen Stand:
apt-get update
apt-get upgrade
Sicherheit
Den SSH-Zugang besser schützen durch:
- Änderung des Ports
- login nur mit key
- Siehe hier für genaue Anleitung:
apt-get install fail2ban
und einrichten
So,nun sollte der Server ausreichend abgesichert sein.
B.A.T.M.A.N. adv 2013.4.0 Kernel-Modul
Batman-Adv aus Jessie ist zu neu. Hier muss manuell das alte B.A.T.M.A.N. advanced 2013.4.0 gebaut werden.
Hierfür benötigen wir minimal die Paketquellen build-essential, linux-headers-amd64 und git:
apt-get install build-essential linux-headers-amd64 git gnupg-curl
Die Softwarequellen müssen heruntergeladen...
cd ~
git clone https://github.com/freifunk-gluon/batman-adv-legacy
cd batman-adv-legacy
... und kompiliert und installiert werden:
make
make install
Hinweis: Sollten noch Paketquellen fehlen, wird dies während des Kompilierens gemeldet. Die Software-Quellen müssen nachinstalliert werden und der letzte Kompilierungs- und Installationsschritt so lange wiederholt werden, bis die Software erfolgreich erstellt wurde.
Nach erfolgreicher Erstellung kann das B.A.T.M.A.N Kernel Modul per modprobe händisch eingebunden werden:
modprobe batman-adv
Es sollte dann im Kernel-log ....
dmesg | grep batman_adv
... mit einem Eintrag gelistet werden:
batman_adv: B.A.T.M.A.N. advanced 2013.4.0-21-ga854277-dirty (compatibility version 14) loaded
Hinweis: Wird Linux mit "apt-get upgrade" aktualisiert und ist in der Distribution inzwischen eine neue Kernel-Version, dann wird das selbst modifizierte Kernel verworfen. Folglich muss nach jedem Kerneltausch das selbst kompilierte Batman-Adv neu installiert werden, wie oben beschrieben!
Das Kernelmodul von B.A.T.M.A.N. kann dann bei jedem Neustart des Systems geladen werden, indem in die Datei /etc/modules:
vi /etc/modules
..der Eintrag "batman-adv" hinzugefügt wird:
batman-adv
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:
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
Kompilieren und Installieren:
make
make install
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 (Debian < 9):
vi /etc/apt/sources.list.d/universe-factory.list
Dort fügen wir folgendes Repository an (Debian < 9):
deb http://repo.universe-factory.net/debian/ sid main deb-src http://repo.universe-factory.net/debian/ sid main
Danach die PGP Schlüssel holen (bei Fehlermeldung zu dirmngr ggf. zuvor apt-get install dirmngr):
gpg --keyserver pgpkeys.mit.edu --recv-key 16EF3F64CB201D9C
gpg -a --export 16EF3F64CB201D9C | apt-key add -
apt-get install apt-transport-https
Datenbankupdate der Paketverwaltung:
apt-get update
Installation von fastd:
apt-get install fastd
- Selbst Kompilieren
Alternativ kann man fastd auch selbst kompilieren.
OpenVPN
OpenVPN (falls benötigt) installieren wir mit:
apt-get install openvpn
DHCP
Den DHCP Server installieren wir mit:
apt-get install isc-dhcp-server
Bind9
Als DNS Server nehmen wir hier den de-facto-Standard bind:
apt-get install bind9
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.
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. 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 ...
vi /etc/iproute2/rt_tables
... folgendes am Ende einfügt:
10 fff
Unsere Freifunk Routing Tabelle lässt sich später durch
ip route show table fff
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 ...
vi /etc/network/interfaces
fügen wir zunächst folgenden Textblock des Gateways "klee" aus der Fürther Hood an:
.
.
.
# 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 replace 10.50.32.0/21 dev $IFACE proto static 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
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 wird. 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.
Hinweis: Die MTU darf nicht verstellt (vergrößert) werden, diesbezügliche Laufzeitmeldungen von batman_adv bitte ignorieren!
FastD Start- und Verwaltungsscript
Für die Konfiguration von fastd importieren wir eine Datei in /etc/fastd mit dem Befehl:
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/fff_beispiel_fastd.sh -P /etc/fastd/
Alternativ kann das Skript aus einer leeren Datei erstellt werden:
touch /etc/fastd/fff_beispiel_fastd.sh
danach öffnen wir diese:
vi /etc/fastd/fff_beispiel_fastd.sh
und editieren das Skript oder fügen ein Neues ein:
#!/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 error;"
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;"
echo "# Datenschutzeinstellungen"
echo "hide ip adresses yes;"
echo "hide mac adresses yes;"
) >> "/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
Bei Debian 9 Muss die Zeile:
if [ "$(/sbin/ifconfig -a | grep -i ethernet | grep ${project}${hood}VPN)" = "" ]
Angepasst werden zu:
if [ "$(/sbin/ifconfig -a | grep ${project}${hood}VPN)" = "" ]
Zum Schluss geben wir noch ein
chmod +x /etc/fastd/fff_beispiel_fastd.sh
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 (Groß-/Kleinschreibung), 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:
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv6/conf/default/forwarding
echo "1" > /proc/sys/net/ipv6/conf/all/forwarding
- Sonst landen ICMP-Fehlerpakete auf eth0 - mit source-IP 10.50.x.y...
- https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
echo 1 > /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr
Dauerhaft lässt sich IP-Forwarding in /etc/sysctl.conf aktivieren:
vi /etc/sysctl.conf
.. um dort die Abschnitte einzukommentieren, die das Forwarding steuern:
. . . # Uncomment the next line to enable packet forwarding for IPv4 net.ipv4.ip_forward=1 # Uncomment the next line to enable packet forwarding for IPv6 # Enabling this option disables Stateless Address Autoconfiguration # based on Router Advertisements for this host net.ipv6.conf.all.forwarding=1 . . .
Um ICMP-Fehlerpakete auf eth0 zu vermeiden, die als src-IP 10.50.x.y haben (böseböse!) dann noch
# Sonst landen ICMP-Fehlerpakete auf eth0 - mit source-IP 10.50.x.y... # https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt net.ipv4.icmp_errors_use_inbound_ifaddr = 1
einfügen
Testen von B.A.T.M.A.N, fastd und Autostart
Hierfür booten wir das Gateway am besten erst mal neu:
reboot & exit
und starten das fast.d Startskript manuell:
/etc/fastd/fff_beispiel_fastd.sh &
Beim Erststart werden Schlüsselpaare generiert und ausgetauscht, es kann also etwas dauern.
Danach sollte der Aufruf von...
pgrep fastd
... mit der Prozess-ID beantwortet werden: Fastd läuft in dem Fall.
Ein Aufruf von ifconfig:
ifconfig
sollte die neu erstellten Interfaces bat0 und ffffuerthVPN zurückliefern. Exemplarisch und als Auszug:
bat0 Link encap:Ethernet HWaddr ea:95:50:07:f7:27
inet addr:10.50.32.5 Bcast:0.0.0.0 Mask:255.255.248.0
inet6 addr: fe80::e895:50ff:fe07:f727/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1089992 errors:0 dropped:0 overruns:0 frame:0
TX packets:849698 errors:0 dropped:1728 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:141311612 (134.7 MiB) TX bytes:1052934594 (1004.1 MiB)
.
.
.
ffffuerthVPN Link encap:Ethernet HWaddr e6:3b:f3:b7:fc:db
inet6 addr: fe80::e43b:f3ff:feb7:fcdb/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1426 Metric:1
RX packets:32389694 errors:0 dropped:0 overruns:0 frame:0
TX packets:2699525 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:4193328694 (3.9 GiB) TX bytes:1384843740 (1.2 GiB)
.
.
.
Aus dem ifconfig Auszug für bat0 sollte die eingerichtete IP des Gateways und die Netzmaske hervorgehen.
Die Abfrage der IP-Regeln:
ip rule
sollte die oben definierten Regeln wieder spiegeln (fff Tabelle für Traffic, der entweder über bat0 oder 10.0.0.0/8 rein- oder rausgeht):
32757: from all to 10.0.0.0/8 lookup fff 32758: from 10.0.0.0/8 lookup fff 32759: from all iif bat0 lookup fff
Eine Abfrage der fff-Routing Tabelle
ip route show table fff
sollte die B.A.T.M.A.N Route (Device bat0) in das Netzwerk der eingerichtete Hood ergeben. In diesem Beispiel ist es die Fürther Hood:
10.50.32.0/21 dev bat0 scope link
Ein Aufruf von "batctl o"
batctl o
ergibt eine Liste der MAC-Adressen von unseren nächsten Nachbarn. Exemplarisch und als Auszug:
[B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: ffffuerthVPN/e6:3b:f3:b7:fc:db (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... 96:43:c4:2e:73:68 0.004s (255) 96:43:c4:2e:73:68 [ffffuerthVPN]: 96:43:c4:2e:73:68 (255) . . .
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:
vi /etc/rc.local
Hier spendieren wir einen Eintrag, der fastd mit 10 Sekunden Verzögerung bei jedem Systemstart mitstartet:
# launch fastd with 10 seconds delay (sleep 10; sh /etc/fastd/fff_beispiel_fastd.sh) &
Zusätzlich muss ein Cronjob angelegt werden, der das Skript z.B. alle 10 Minuten ausführt:
crontab -e
Nun folgendes eingeben:
*/5 * * * * sleep 10; sh /etc/fastd/fff_beispiel_fastd.sh
und
/etc/init.d/cron restart
OpenVPN-Tunnel einrichten
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
Unter https://mullvad.net/download/config/ Reiter "Other platforms" kann man sich die mullvadconfig_xx.zip runterladen.
Mullvad liefert in dieser Datei, die notwendigen Schlüssel (ca.crt, mullvad.crt, mullvad.key) als auch eine Konfigurationsdatei (mullvad_linux.conf) mit, die später angepasst werden muss.
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 Windows oder Linux auf das Gateway.
Als unverbindliche Richtschnur für Linux:
scp mullvadconfig.zip root@<ipv4 des Gateways>:/root
Danach loggen wir uns auf dem Gateway ein und entpacken die Datei (nicht vergessen unzip zu installieren):
ssh root@<ipv4 des Gateways>
unzip mullvadconfig.zip
cd <Kundennummernverzeichnis>
cp * /etc/openvpn
/etc/openvpn/ sollte mit dem Inhalt des entpackten mullvadconfig.zip Archivs dann so aussehen:
ca.crt crl.pem mullvad.crt mullvad.key mullvad_linux.conf mullvad_windows.conf.ovpn update-resolv-conf
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.
Wir legen ein benutzerspezifisches start-up Script namens mullvad-up an:
vi /etc/openvpn/mullvad-up
und füllen sie mit folgendem Inhalt:
#!/bin/bash
logger -t OPENVPN VPN Gateway: /sbin/ip route replace default via ${route_vpn_gateway} dev ${dev} proto static table fff
/sbin/ip route replace default via ${route_vpn_gateway} dev ${dev} proto static table fff
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE
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:
chmod +x /etc/openvpn/mullvad-up
Dieses spezifische Routing muss zwingend in mullvad_linux.conf eingepflegt werden:
vi /etc/openvpn/mullvad_linux.conf
und hier die Konfiguration entsprechend geändert werden:
. . . # 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 . . .
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).
Der openvpn Tunnel kann nun testweise gestartet werden:
cd /etc/openvpn
/usr/sbin/openvpn mullvad_linux.conf &
und sollte exemplarisch und im Auszug folgendes zurück liefern:
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
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:
ip route show table fff | grep default
Exemplarisch wäre eine Ausgabe für das Tunnel-Device tun0 und dem VPN-Gateway 10.114.0.1:
default via 10.114.0.1 dev tun0
Auch ein ifconfig Eintrag für das Tunnel Device...
ifconfig
...sollte jetzt existieren (Exemplarisch und im Auszug):
.
.
.
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)
.
.
.
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:
vi /etc/rc.local
und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:
# launch vpn with 5 seconds delay (sleep 5; /usr/sbin/openvpn /etc/openvpn/mullvad_linux.conf >> /var/log/mullvad_vpn.log &) &
NordVPN
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.
Von dem lokalen Rechner kopieren wir die zip Datei per scp für Windows oder Linux auf das Gateway.
Als unverbindliche Richtschnur für Linux:
scp config.zip root@<ipv4 des Gateways>:/root
Und entpacken diese auf dem Gateway:
cd ~
mkdir nordvpn-configs
mv config.zip nordvpn-configs
cd nordvpn-configs
unzip config.zip
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.
Im Beispiel nehmen wir se1.nordvpn.com.udp1194.ovpn und passen Sie zunächst Freifunk-spezifisch an (siehe Aussperr-Hinweis oben):
vi se1.nordvpn.com.udp1194.ovpn
Ä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:
. . . # 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 route-noexec route-delay 3 route-up /etc/openvpn/nordvpn-up . . .
Die angepasste Datei (im Beispiel se1.nordvpn.com.udp1194.ovpn) kopieren wir nach /etc/openvpn und spendieren Ihr gleichzeitig die Endung .conf, damit der Autostart Mechanismus die Konfigurationsdatei als solche erkennt:
cp se1.nordvpn.com.udp1194.ovpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf
Hier legen wir noch unser Freifunk Startskript und unsere Password Datei an und machen das Skript ausführbar:
touch /etc/openvpn/nordvpn-up
touch /etc/openvpn/nordvpn-pw
chmod +x /etc/openvpn/nordvpn-up
Man öffnet nordvpn-up...
vi /etc/openvpn/nordvpn-up
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):
#!/bin/bash
logger -t OPENVPN VPN Gateway: /sbin/ip route replace default via ${route_vpn_gateway} dev ${dev} proto static table fff
/sbin/ip route replace default via ${route_vpn_gateway} dev ${dev} proto static table fff
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE
Nun öffnet man nordvpn-pw:
vi /etc/openvpn/nordvpn-pw
Und legt in der ersten Zeile der Datei seinen NordVPN Usernamen und in der zweiten Zeile sein NordVPN Passwort ab:
(Username bei NordVPN) (Password bei NordVPN)
Der Tunnel kann nun testweise gestartet werden (hier im Beispiel mit der Konfigurationsdatei se1.nordvpn.com.udp1194.ovpn)
openvpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf &
Und sollte aufgebaut werden:
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
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:
vi /etc/rc.local
und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:
# launch vpn with 5 seconds delay (sleep 5; cd /etc/openvpn ; /usr/sbin/openvpn se1.nordvpn.com.udp1194.ovpn.conf >> /var/log/nordvpn.log &) &
Die Beispiel-Konfigurationsdatei (se1.nordvpn.com.udp1194.ovpn.conf) muss entsprechend angepasst werden.
DNS Server
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.
ACHTUNG! Freifunk Franken hat nun sein eigenes DNS System. Damit dies von überall funktioniert bitte diese Seite beachten.
Hierfür editieren wir die Datei named.conf.options...
vi /etc/bind/named.conf.options
...und tragen die DNS Server, die wir anfragen wollen, wenn wir die Information nicht selber haben, als forwarders ein:
.
.
.
forwarders {
10.83.252.11;
10.50.252.0;
};
allow-query {
127.0.0.1/8;
10.0.0.0/8;
};
.
.
.
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:
/etc/init.d/bind9 restart
Testen können wir, indem wir vom DNS Server des Gateways (localhost/127.0.0.1) eine DNS-Auflösung abfragen.
Ein DNS Resolve für freifunk-franken.de ...
dig @127.0.0.1 freifunk-franken.de
...sollte von uns selber (Server localhost; 127.0.0.1) beantwortet werden:
;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5819 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;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
B.A.T.M.A.N Gateway Selection
ACHTUNG: Dieses Script sollte erst aktiviert werden wenn sicher feststeht das:
- Babel alle Routen übertragen hat, "ip r s table fff" gibt viele routen zu 10.x.x.x und 172.x.x.x aus
- Der Server als Gateway in den KeyXchange eingetragen ist (muss man wissen, falls unbekannt bitte an die dev Liste fragen oder einen KeyXChange Admin)
- Ein funktionierender DHCP Server läuft
Man sich also prinzipiell sicher ist, das der Server komplett fertig ist. Dies sollte der allerletzte Schritt sein wenn der Server eigentlich schon Online ist.
Wird das Script vorher aktiviert, announced man sich im Batman als Gateway obwohl man keine IPs vergibt (oder nicht richtig routet). Dies führt dazu das Clients keine IPs oder kein Routing ins Freifunknetz bekommen was sehr unschön ist.
Ab Version 0.5.1 der Router Firmware ist die B.A.T.M.A.N Gateway Selection aktiviert worden. 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:
- Bandbreite der Netzanbindung (z.B. 100 Mbit/sec, gesplittet in 50 Mbit/sec up/down)
- 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:
apt-get install bc
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:
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/dyn_announce_gw_bw.sh -P /usr/local/bin/
Alternativ kann das Skript auch als leere Datei erstellt werden:
touch /usr/local/bin/dyn_announce_gw_bw.sh
Wir machen das Skript ausführbar und öffnen die Datei:
chmod +x /usr/local/bin/dyn_announce_gw_bw.sh
vi /usr/local/bin/dyn_announce_gw_bw.sh
Und Füllen dieses mit Inhalt oder editieren den importierten Inhalt:
#!/bin/bash
gwsel_lockfile="/tmp/gwsel_lockfile" # lockfile to allow for low bandwidth settings
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
if [ ! -e ${gwsel_lockfile} ]; then # lockfile not present
# 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"
else # lockfile present
Tavail_kbitPS=0
Ravail_kbitPS=0
sleep "$2"
fi
for bat in /sys/class/net/bat*; do
iface=${bat##*/}
if [ `pidof dhcpd` > "0" ]
then
batctl -m $iface gw_mode server "${Ravail_kbitPS}kbit/${Tavail_kbitPS}kbit"
else
batctl -m $iface gw_mode server off
/etc/init.d/isc-dhcp-server restart
fi
done
done
Achtung: Wenn man ein bat Interface hat, das nicht Gateway ist muss man dies aus der letzten Schleife ausschließen da sonst dort ebenfalls die Gatewayselection aktiviert wird und man eine Bandbreite announced.
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.)
Bei Existenz des oben definierten Lockfiles "/tmp/gwsel_lockfile", annonciert das Gateway nur noch eine minimale Bandbreite. Dies dient dazu, möglichst keine neuen Clients zu akquirieren, z.B. weil gerade der VPN Tunnel ausgefallen ist und nur noch eine Babel Defaultroute mit geringer Bandbreite verfügbar ist.
Ein Aufruf für eth0 als Interface, ein Update alle 5 Minuten, 12 Mbit/sec maximaler Upload und 10 Mbit/sec maximaler Download wäre z.B.:
/usr/local/bin/dyn_announce_gw_bw.sh eth0 300 12 10
Bei Debian 9 muss das Interface angepasst werden.
Als Beispiel:
/usr/local/bin/dyn_announce_gw_bw.sh ens18 300 12 10
Um die Gateway Selection beim Systemsstart zu aktivieren, können wir das Skript z.B. in rc.local aufrufen:
vi /etc/rc.local
um dort, leicht zeitverzögert, o.a. Befehl einzupflegen, wobei die Parametrisierung noch Gateway-spezifisch angepasst werden muss:
. . . #enable batman GW selection with 15 seconds delay (sleep 15; /usr/local/bin/dyn_announce_gw_bw.sh eth0 300 12 10) & . . .
auf den Routern kann der vorselektierte Gateway mit
batctl gwl
angeguckt werden.
Gatewayselection abschalten wenn Lease voll
Wenn man mit den dhcp Leases am Limit ist, sollte das Script angepasst werden das es die Gatewayselection abschaltet wenn nur noch wenige Leases offen sind. Dazu muss vor den letzten "done" folgender Teil hinzugefügt werden, Beispiel für Hood Erlangen auf nue2-gw1. Das grep muss auf die entsprechende IP Range angepasst werden und der IF Vergleich auf die maximale Menge an Leases, man sollte dabei noch einen Puffer offen halten.
# Erlangen schalten wir die Gatewayselection zur Sicherheit bei 450 leases ab, damit noch etwas Puffer nach oben ist! leasecount=$(/usr/sbin/dhcp-lease-list --parsable --lease /var/lib/dhcp/dhcpd.leases 2>&1 | grep "10.50.6" | wc -l) if [ $leasecount -gt 450 ] then batctl -m bat1 gw_mode off fi
DHCP Server
Die DHCP Konfiguration kann schon mal vorbereitet werden, sollte aber erst mit als vorletzter 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 ...
vi /etc/default/isc-dhcp-server
... das der DHCP Server für das B.A.T.M.A.N Device Anfragen beantworten soll:
. . INTERFACES="bat0" . .
Nachfolge Konfiguration wird in auskommentierter Form vorbereitet und sollte erst im letzten Schritt durch Einkommentieren und durch einen Neustart des DHCP Servers...
/etc/init.d/isc-dhcp-server restart
...aktiviert werden.
Die Konfiguration wird in dhcpd.conf vorgenommen:
vi /etc/dhcp/dhcpd.conf
und folgender Konfigurationsblock zunächst auskommentiert eingefügt, wobei Gateway und Hood spezifische Änderungen noch eingepflegt werden müssen:
.
.
.
### Freifunk Franken
#option domain-name "fff.community";
#option domain-name-servers 10.50.16.1;
#authoritative;
### Fuerth
#shared-network fff-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
# }
#}
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...
vi /etc/network/interfaces
...mit folgenden noch auf das Gateway anzupassenden Einträgen deklariert:
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 -6 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 -6 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 ip tunnel del $IFACE
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:
<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
In der Partnerkonfiguration für ro1 werden die Rollen entsprechend vertauscht:
<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
Der Tunnel kann über den Aufruf von
ifup <tunnel>
...aufgebaut werden, wobei <tunnel> der Name des GRE-Interfaces ist (im Beispiel ro1)
Nach Aufruf von ifconfig..
ifconfig
sollten wir einen Eintrag für den Tunnel (in diesem Beispiel ro1) vorfinden:
.
.
.
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)
.
.
.
Einbringen des Gateways in die Hood / Keyserver
Abschliessend muss das Gateway im Keyserver als Gateway der entsprechenden Hood eingetragen werden. Hierfür benötigt man einen Keyserver-Administrator => Server.
Bevor man das Gateway der Hood zuordnet, empfiehlt sich ein persönliches Review durch einen erfahrenen Gateway-Admin. Das neue Gateway kann auch versuchsweise zunächst einer Test-Hood zugeordnet werden, um es erstmal auf korrekte Funktion zu überprüfen.
Der DHCP-Server sollte als letzter Schritt aktiviert werden (s.o.)
Einzelne IPs oder Services über anderen Server routen
Manchmal möchte man einzelne Clients oder bestimmte Services (Achtung Netzneutralität!) über einen anderen Server ins Internet routen. Dies ist folgendermaßen möglich. In meinen Beispiel route ich auf fff-gw-cd1 den kompletten Internettraffic von nbgland über fff-pi-cd1 ins Internet um den Mullvad auf fff-gw-cd1 zu entlasten (nbgland hat ein hohes Trafficaufkommen).
Routingtabelle anlegen
Zuerst brauchen wir eine weitere Routingtabelle:
vi /etc/iproute2/rt_tables
und fügen dort hinzu:
12 nbgland
Diese Routingtabelle füllen wir mit einem neuen default
ip route add default via 10.50.252.251 dev fff-pi-cd1 table nbgland
Routing erstellen
Anschließend können wir alle Pakete mit Iptables markieren und für diese markierten Pakete in die neue Routingtabelle gucken, in unserem Beispiel:
iptables -A PREROUTING -t mangle -s 10.50.88.0/21 ! -d 10.0.0.0/8 -j MARK --set-mark 3 ip rule add fwmark 3 table nbgland
Das heißt: Markiere alle Pakete mit dem "Marker 3" die von dem IP Bereich 10.50.88.0/21 hereinkommen und nicht als Ziel 10.0.0.0/8 haben (damit wird Freifunkinterner Traffic von der Regel ausgenommen). Mit dem ip rule Regel sagen wir das für alle Pakete mit dem Marker 3 in die neue Routingtabelle nbgland geguckt werden soll wo der neue default fff-pi-cd1 drinnen steht. Da mit Iptables sehr viele möglichkeiten bestehen ist man über diesen Weg extrem flexibel, man könnte z.b. alle Torrentpakete markieren (Achtung Netzteutralität!) und über einen "Müllserver" ausleiten.
Problem wenn Server offline
Ein Problem bleibt noch, was passiert wenn fff-pi-cd1 offline ist? Genau da dies ganze am Olsr "vorbei" läuft stehen alle markierten Pakete dann ohne Exit (in unseren Fall ganz nbgland ohne Internet) da. Dazu hab ich das OpenVPN Start/Stop Automatik von Green ein wenig vereinfacht und angepasst für unsere bedürfnisse:
#!/bin/bash
ping1 () {
ping -c 3 -i 5 8.8.8.8 -I fff-pi-cd1
ping1_ExitCode=$?
echo "$(date): Exit Status: ${ping1_ExitCode}"
}
while true
do
ping1
# check if ping successful
if ([[ ${ping1_ExitCode} -eq 0 ]]); then
sleep 10;
echo "Ping success";
else
echo "Ping fault";
iptables -D PREROUTING -t mangle -s 10.50.88.0/21 ! -d 10.0.0.0/8 -j MARK --set-mark 3
fi
done
Das Script wird gestartet und läuft in einer Endlosschleife. Es wird regelmäßig versucht über fff-pi-cd1 8.8.8.8 zu pingen und falls dies nicht mehr gelingt wird die iptables Regel mit -D entfernt, somit werden die Pakete nicht mehr markiert und Olsr hat wieder die Kontrolle über den Traffic. Ein automatisches reaktivieren findet aktuell nicht statt, dies müsste ich nach beheben des Problems manuell anstoßen. Diese Konstellation läuft jetzt schon seit 6. Januar problemlos, es gab keine beschwerden und das Script musste noch nicht einmal eingreifen.
Achtung: Falls am fff-pi-cd1 der OpenVPN abstürzt baut dort Olsr auf einen anderen Server um. Da dadurch der Ping nach wie vor gelingt, wird die iptables Rule auch nicht entfernt. Man sollte also dafür sorgen das fff-pi-cd1 einen guten 2. Exit hat, falls OpenVPN abstürzt. Dies ist heute passiert und da es keinen guten Exit gab, war nbgland einige Zeit ziemlich lahm.
Problem nf_conntrack
Bei vielen Clients und vorallem NAT und anderen Iptables kann es passieren das die nf_conntrack auf den Server voll läuft. Wenn dies passiert fängt der Server an Pakete zu verwerfen und ist dann nur noch schwer erreichbar. Zu erkennen ist das auch wenn dmesg unmengen von
nf_conntrack: table full, dropping packet
um sich wirft.
Folgendes sollte man im Auge behalten:
Ermitteln des conntrack_max
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
Debian9:
cat /proc/sys/net/nf_conntrack_max
Ermitteln des aktuellen conntrack count
/sbin/sysctl net.netfilter.nf_conntrack_count
sollte die aktuell Größe nahe an die maximale Größe kommen, kann diese vergrößert werden:
sysctl -w net.netfilter.nf_conntrack_max=131072 echo 32768 > /sys/module/nf_conntrack/parameters/hashsize
zu beachten ist, das eine größere conntrack auch mehr Arbeitsspeicher fordert. Unter 4GB sollte sie nicht vergrößert werden. Der hashsize sollte 1/4 des conntrack_max Wertes betragen Der Wert kann auch permamenent angepasst werden:
vi /etc/sysctl.conf // Am Ende einfügen net.netfilter.nf_conntrack_count = 131072 vi /etc/rc.local echo 32768 > /sys/module/nf_conntrack/parameters/hashsize
zusätzlich kann das unnötig lange Timeout verringert werden um den conntrack count schon von Grund auf kleiner zu halten:
vi /etc/sysctl.conf // Am Ende einfügen net.ipv4.netfilter.ip_conntrack_generic_timeout = 120 net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 54000
bzw. die Werte sofort setzen:
sysctl -w net.ipv4.netfilter.ip_conntrack_generic_timeout=120 sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=54000
Quelle: [2]
ARP Cache erhöhen
ACHTUNG: Das ganze ist noch nicht intensiv getestet, bitte bei Änderungen beobachten! Default ist im Linux der Arp Cache relativ klein. Wenn man mehrmals hintereinander die Menge an ARP Einträgen im Cache abfragt (z.b. ip neigh show | wc -l) und man feststellt das der Cache regelmäßig aufgeräumt wird (Zahl springt alle paar Sekunden wieder auf einen deutlich kleineren Wert zurück) sollte man den Wert erhöhen um die Arp Requests im Netz zu verringern. Dies geht über sysctl Variablen:
sysctl -w net.ipv6.neigh.default.gc_thresh1=128 sysctl -w net.ipv6.neigh.default.gc_thresh2=512 sysctl -w net.ipv6.neigh.default.gc_thresh3=1024 sysctl -w net.ipv4.neigh.default.gc_thresh1=128 sysctl -w net.ipv4.neigh.default.gc_thresh2=512 sysctl -w net.ipv4.neigh.default.gc_thresh3=1024
die oben angegeben Werte sind die default Werte. Weitere Infos zu den Werten: https://wiki.manitu.de/index.php/Server:Fehlermeldung_%22kernel:_Neighbour_table_overflow%22
Ich hab z.b. auf nue2gw3 mit ~2400 Clients die Werte auf 2048 4096 8192 gesetzt.
Port Sperren
Es empfiehlt sich folgende Ports / IPs zu sperren
Ausgehend:
- tcp-25
- tcp-137
- udp-137
- ip-10.0.0.0/8
- ip-172.16.0.0/12
- ip-192.168.0.0/16
- ip-100.64.0.0/10
- ip-169.254.0.0/10
- ip-192.0.0.0/24
- ip-192.0.2.0/24
- ip-198.18.0.0/15
- ip-198.51.100.0/24
- ip-203.0.113.0/24
- ip-0.0.0.0/8
Gateways, welche beim Hoster Hetzner stehen, sollte weitere Vorkehrungen treffen. Hetzner monitored den Traffic, den die Gateways verursachen. Sollten Verbindungsversuche zu nicht gerouteten IPs dabei sein, generiert Hetzner Abuse und schickt es (Achtung!) nicht an die hinterlegte Abuse-Adresse. Was man dagegen tun kann ist hier beschrieben: Hetzner
