Gateways

Juhu, die Zugangsdaten für meinen virtuellen Sever sind da! Damit sind die Weichen für ein unabhängiges Freifunk-Netz in Weil am Rhein gestellt. Um einzelne Knoten außer Funkreichweite miteinander verbinden zu können bedarf es eines Kunstrukts, welches ich als Mesh VPN bezeichne (nicht zu verwechseln mit dem InterCity VPN, welches die verschiedenen Freifunknetze miteinander verbindet). Das Konstrukt is relativ simpel: Mit dem Internet verbundende Knoten in den einzelnen Funkmaschen erstellen eine Tunnelverbindung zu einem oder mehreren zentralen Severn. Diese Server leiten eingehenden Netzwerkverkehr dann in die außer Reichweite befindlichen Funkmaschen weiter. Das Routing übernimmt wie in den Funkmaschen batman-adv.

Der folgende Artikel beschreibt die Einrichtung eines solchen zentralen Servers. Der gleiche Server wird zu einem späteren Zeitpunkt als Gateway ins Internet und zu anderen Freifunk-Netzen via InterCity VPN konfiguriert werden. Die zentralen Elemente sind das batman-adv Kernelmodul und der fastd VPN-Server. Als Betriebssystem wird von Debian Wheezy mit ein Linux-Kernel in der Version 3.2.41 ausgegangen. Das Vorgehen für andere Linux-Distributionen sollte ähnlich sein. Allerdings wird man in diesen Fällen um das Kompilieren von fastd und batman-adv/batctl vermutlich nicht herumkommen. Weiterhin wird von einer Einrichtung als Benutzer root ausgegangen. Falls dem nicht so ist, muss den Befehlen welche Superuser-Rechte benötigen ein sudo vorangestellt werden (Also, sudoer sollte man schon sein, sonst wird es nichts mit der Server-Einrichtung).

...

Der folgende Artikel beschreibt die Einrichtung eines Gluon Internet-Gateways, um Teilnehmern des Freifunknetzes die Verbindung mit dem Internet zu ermöglichen. Die Einrichtung des Mesh-VPN zur Vernetzung von isolierten Funkwolken unterneinander hatten wir in einem vorangehenden Artikel bereits beschrieben. Ein funktionierendes Mesh-VPN ist Voraussetzung für die folgenden Schritte.

Vom Prinzip her wird über das Mesh-VPN eingehender Verkehr, welcher an das Internet (d.h. an Adressen außerhalb des Freifunk-Netzes) gerichtet ist, mittels Routing- und Firewall-Regeln ins Internet weitergeleitet. Zwecks Anonymisierung der Verbindung und Umgehung der in Deutschland geltenden Störerhaftung wird hierbei eine weitere VPN-Verbindung zwischengeschaltet.

Zusätzlich werden wir einen DHCP-Server einrichtigen, um IPv4-Adressen dynamisch an Endgeräte zu vergeben sowie einen DNS-Proxy, der vom Mesh ausgehende DNS-Anfragen bedient. Weiterhin benötigen wir einen Radvd-Dämonen zur Umsetzung des “Neighbour Discovery Protocols”, welches die Autokonfiguration von IPv6-Adressen auf der Basis von Link-Layer-Adressen ermöglicht. Das Routing auf Layer 2 übernimmt batman-adv.

Als Vorlage für die folgenden Beschreibungen dienten die Anleitungen der Freifunk-Gemeinden Hannover und Hamburg. Diese wurden an manchen Stellen modifiziert und um Erläuterungen ergänzt. Als Betriebssystem wird von Debian Wheezy ausgegangen. Die Einrichtung des Gateway erfolgt als Benutzer root. Netzwerkschnittstellen konfigurieren

Etckeeper

Um Änderungen an der Konfiguration des Servers besser verfolgen zu können, installieren wir als erstes das Paket etckeeper:

$ apt-get install etckeeper

Im Anschluss aktivieren wir die Versionierung des Konfigurationsverzeichnisses /etc:

$ etckeeper init /etc

In seiner Standardkonfiguration verwendet etckeeper die Software git zur Versionierung. Um lästige Warnungen zu vermeiden, vervollständigen wir die git-Konfiguration mit den zwei folgenden Befehlszeilen. Falls git bereits vollständig konfiguriert wurde, kann dieser Schritt übersprungen werden.

$ git config --global user.name "Freifunk 3Laendereck"
$ git config --global user.email admin@freifunk-3laendereck.de

batman-adv

Im nächsten Schritt installieren wir das batman-adv Kernel-Modul und das zugehörige Konfigurationswerkzeug batctl. Diese sind nicht Teil der Debian-Distribution (zumindest nicht in einer aktuellen Version), sondern müssen über ein externes Depot (“Repository”) bezogen werden. Hierfür fügen wir der Datei /etc/apt/sources.list die folgende Zeile hinzu:

deb http://repo.universe-factory.net/debian/ sid main

Im Anschluss importieren wir die öffentlichen Schlüssel, mit welchen die Identität der importierten Pakete überprüft wird:

$ gpg --keyserver pgpkeys.mit.edu --recv-key AB7A88C5B89033D8
$ gpg --keyserver pgpkeys.mit.edu --recv-key 16EF3F64CB201D9C
$ gpg -a --export AB7A88C5B89033D8 | sudo apt-key add -
$ gpg -a --export 16EF3F64CB201D9C | sudo apt-key add -

Jetzt sind wir soweit, dass wir die benötigten Pakete mittels der folgenden Befehlszeilen bequem installieren können:

$ apt-get update
$ apt-get install batman-adv-dkms
$ apt-get install batctl

Im Anschluss müssen wir noch das batman-adv Modul in den Kernel laden:

$ modprobe batman-adv

Achtung: Unter Debian Jessie wird das Modul nicht installiert. Es kommt während der Installation die Meldung, dass die installierte Version neuer ist als die zu installierende Version. Lösung: Wir erzwingen die Installation des Moduls von Hand:

$ dkms remove batman-adv/2013.4.0 --all
$ dkms install --force batman-adv/2013.4.0

Danach ermitteln wir die installierten Kernel- und Kernel-Header-Module:

$ dpkg --get-selections | grep linux

Schließlich fixieren wir sämtliche Pakete mit dem Präfix "linux-headers" bzw. "linux-image" auf die aktuelle Version. Der Platzhalter <version> ist durch den zuvor angezeigten Versionsbezeichner zu ersetzen:

$ echo "linux-headers-<version>-amd64 hold" | dpkg --set-selections
$ echo "linux-headers-<ersion>-common hold" | dpkg --set-selections
$ echo "linux-image-<version>-amd64 hold" | dpkg --set-selections
$ echo "linux-headers-amd64 hold" | dpkg --set-selections
$ echo "linux-image-amd64 hold" | dpkg --set-selections

Damit das Kenel-Modul in Zukunft automatisch während des Boot-Vorgangs geladen wird, fügen wir noch die folgende Zeile der Datei /etc/modules hinzu:

batman-adv

fastd

Im nächsten Schritt richten wir den VPN-Dämonen fastd ein. Dieser kann über das gleiche Software-Depot wie batman-adv bezogen werden. Für die Installation genügt es, das folgende Kommando auszuführen:

$ apt-get install fastd

Nach erfolgter Installation muss fastd noch konfiguriert werden. Das Standardkonfigurationsverzeichnis /etc/fastd ist zum aktuellen Zeitpunkt noch leer. Zuerst erzeugen wir ein Unterverzeichnis, in dem die Konfigruationsdateien für unser Netzwerk abgelegt werden sollen:

$ mkdir /etc/fastd/ff3l
$ mkdir /etc/fastd/ff3l/peers

Als nächstes generieren wir ein Schlüsselpaar und speichern es in der Dateil keys:

$ cd /etc/fastd/ff3l
$ fastd --generate-key >> keys

Die Ausgabe der Datei sollte dem folgenden Beispiel ähneln:

$ cat keys
2014-04-26 21:15:27 +0200 --- Info: Reading 32 bytes from /dev/random...
Secret: 90722f73f2c23b672ad419f66191420444a3e7a9a69c9fa139e0da096570b857
Public: a7d7cfbd2d4a463ffd8d6faff71fffbef7761ae95d685913d774e38aa1f31596

Den privaten Schlüssel speichern wir in der Datei /etc/fastd/ff3l/secret.conf in Form der folgenden Zeile:

secret "90722f73f2c23b672ad419f66191420444a3e7a9a69c9fa139e0da096570b857";

Der eingetragene Schlüssel muss selbstverständlich durch den tatsächlich generierten Schlüssel ersetzt werden. Beide Dateien (keys und secret.conf) schützen wir durch eine Einschränkung der Rechte vor dem Zugriff Dritter:

$ chmod 600 keys
$ chmod 600 secret.conf

Der öffentliche Schlüssel wird nicht für die Konfiguration von fastd benötigt, wohl aber später für die Konfiguration der Klienten. Abschließend erzeugen wir die zentrale Konfigurationsdatei /etc/fastd/ff3l/fastd.conf mit folgendem Inhalt:

# Log warnings and errors to stderr
log level info;
# Log everything to syslog
log to syslog level info;
# Set the interface name
interface "ff3l-mesh-vpn";
# Enable encryption methods
method "salsa2012+umac";
method "salsa2012+gmac";
method "xsalsa20-poly1305";
method "aes128-gcm";
# Bind to a fixed port, IPv4 only
bind 0.0.0.0:10000;
# Secret key generated by `fastd --generate-key`
include "secret.conf";
# Enforce secure handshakes
secure handshakes yes;
# Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE)
# (see MTU selection documentation)
mtu 1426;
# Include peers from the directory 'peers'
include peers from "peers";
# Activate batman-adv network interface
on up "
 ifup bat0
 ip link set address <MAC address> up dev $INTERFACE 
";
# Deactivate batman-adv network interface
on down "
 ifdown bat0
";

Der Platzhalter <MAC address> ist mit einer beliebigen, jedoch für das jeweilige Gateway eindeutigen MAC-Adresse zu ersetzen. Im Unterverzeichnis /etc/fastd/freifunk/peers werden wir zu einem späteren Zeitpunkt für jeden Klienten eine Datei mit dem öffentlichen Schlüssel anlegen. Der öffentliche Schlüssel wird von Gluon auf den Knoten zum Zeitpunkt der Erstkonfiguration angelegt und muss per e-Mail an die Gateway-Administratoren übermmittelt werden. Beispiel für eine Konfigurationsdatei:

# <Name des Klienten>
# <Kontaktadresse>
key "INCOMING_CONNECTION_PARTNER_PUBLIC_KEY";

Jetzt müssen wir den fastd-Server nur noch starten:

/etc/init.d/fastd start

Da mit der Installation von fastd gleichzeitig die zugehörigen Links in den /etc/rc.X-Verzeichnissen erstellt wurde, startet fastd beim nächsten Bootvorgang automatisch.

Netzwerkschnittstellen

Für die Konfiguration des Gateways benötigen wir die sogenannten bridge-utils, welche wir mit folgenden Befehlen installieren:

$ apt-get update
$ apt-get install bridge-utils

Zusätzlich aktivieren wir die IP-Weiterleitung durch Hinzufügen der folgenden Zeilen zur Datei /etc/sysctl.conf:

net.ipv4.ip_forward=1 
net.ipv6.conf.all.forwarding = 1

Im Anschluss übernehmen wir die Änderung durch Ausführung der folgenden Befehlszeile:

$ sysctl -p /etc/sysctl.conf

Im ersten Schritt richten wir unter /etc/network/interfaces eine Netzwerkbrücke mit dem Namen br-ff3l ein. Die Brücke dient der statischen IPv4- und IPv6-Konfiguration des Gateways. Später wird der Brücke noch die Batman-Schnittstelle bat0 zugewiesen. Beide IP-Adressen müssen innherhalb des Freifunk-Netzes liegen und für das Gateway eindeutig sein. Die Platzhalter <IPv6 address> und <IPv4 address> sind entsprechend zu ersetzen:

# FF3L mesh interfaces
iface br-ff3l inet6 static
  bridge-ports none
  address <IPv6 address>
  netmask 44

iface br-ff3l inet static
 address <IPv4 address>
 netmask 255.255.0.0

Neben der Brücke konfigurieren wir in der selben Datei die Batman-Schnitstelle 'bat0':

iface bat0 inet6 manual
 pre-up modprobe batman-adv
 pre-up batctl gw server
 pre-up batctl if add mesh-vpn
 up ip link set $IFACE up
 post-up brctl addif br-ff3l $IFACE
 post-up batctl it 10000
 post-up ip rule add from all fwmark 0x1 table 42
 pre-down brctl delif br-ff3l $IFACE || true
 down ip link set $IFACE down

Bevor die Schnittstelle aktiviert wird, stellen wir mittels des Kommandos “pre-up modprobe batman-adv” sicher, dass das Kernelmodul batman-adv geladen und aktiv ist. Im Anschluss konfigurieren wir das Gateway mittels “pre-up batctl gw server” als Server, so dass DHCP-Anfragen von Batman zugestellt werden. Mittels “pre-up batctl if add mesh-vpn” ordnen wir die Schnittstelle für das Mesh-VPN der Batman-Schnittstelle zu und aktivieren somit das automatische Routing. Im Anschluss aktivieren wir die Schnittstelle mittels “up ip link set $IFACE up”.

Danach ordnen wir die Batman-Schnittstelle mittels “brctl addif br-ff3l $IFACE” der zuvor angelegten Brück zu, so dass die statische IP-Konfiguration greift. Das Originator-Intervall für Batman setzen wir mit “post-up batctl it 10000″ auf 10000 ms (also 10 s). Als letztes leiten wir mittels “post-up ip rule add from all fwmark 0x1 table 42″ mit der Ziffer 0x1 markierten eingehenden Verkehr gemäß der Routing-Tabelle 42 weiter (siehe Firewall-Konfiguration weiter unten). Vor dem Herunterfahren von bat0 lösen wir die Schnitstelle mit “pre-down brctl delif br-ff3l $IFACE || true” wieder von der Brücke.

Nach der Einrichtung der Brücke müssen wir diese ein einziges Mal von Hand starten. Zusätzlich starten wir den fastd-Dämonen erneut, welcher im Zuge des Neustarts wiederum die Batman-Schnittstelle bat0 aktiviert (siehe “on up”-Answeisung in der fastd-Konfiguration).

$ ifup br-ff3l
$ service fastd restart

DHCP-Server

Als nächstes richten wir einen DHCP-Server ein, um mit dem Freifunk-Netz verbundenen Endgeräten dynamisch eine IPv4-Adresse zuzuweisen und ihnen die zugehörige Netzwerkkonfiguration mitzuteilen. Hierfür verwenden wir den ISC-DHCP-Server, welchen wir zuvor installieren müssen:

$ apt-get install isc-dhcp-server

Die Konfiguration des Servers unter /etc/dhcp/dhcpd.conf ändern wir gemäß dem folgenden Absatz. Die Top-Level-Domain (“.ff3l”), Netzadresse (10.119.0.0), Netzmaske (255.255.240.0) sowie die Adresse des DNS-Servers/Routers (10.119.0.2) sind ggf. anzupassen. Die Adresse des DNS-Servers/Routers ist der statischen Adresse des Gateways (Freifunknetz – nicht Internet!) gleichzusetzen. Beim zu vergebenden Adressbereich (hier 10.119.1.1 bis 10.119.255.254) empfiehlt es sich einen kleineren Bereich des Neztes für die statische Vergabge von IPv4-Adressen auszusparen (hier 10.119.0.1 bis 10.119.0.254). Die Adresse des Gateways muss in diesem Bereich liegen.

ddns-update-style none;
option domain-name ".ff3l";
default-lease-time 600;
max-lease-time 3600;
log-facility local7;
subnet 10.119.0.0 netmask 255.255.0.0 {
 authoritative;
 range 10.119.1.1 10.119.255.254;
 option domain-name-servers 10.119.0.2;
 option routers 10.119.0.2;
}
include "/etc/dhcp/static.conf";

Vorsorglich legen wir noch die (leere) Datei /etc/dhcp/static.conf für die statische Konfiguration von Klienten an, auch wenn wir diese vorerst nicht nutzen und starten im Anschluss den Dämonen neu:

$ touch /etc/dhcp/static.conf
$ service isc-dhcp-server restart

Radvd

Um die Autokonfiguration von IPv6- auf der Basis von Link-Layer-Adressen zu ermöglichen, richten wir einen radvd-Dämonen ein, welcher das “Neighbor Discovery Protocol” implementiert. Zu allererst installieren wir den Dämonen:

$ apt-get install radvd

Danach passen wir die Konfiguration unter /etc/radvd.conf gem. dem folgenden Abschnitt an. Wir aktivieren den Dämonen auf der Brücke br-ff3l und damit der Batman-Schnittstelle, welche automatisch zugewiesen wird (siehe oben). Weiterhin teilen wir dem Dämonen unseren IPv6-Präfix (fdc7:3c9d:b889:a272) mit sowie die statische IPv6-Adresse unseres Gateways (fdc7:3c9d:b889:a272::2) als rekursiven DNS-Server zur Namensauflösung.

interface br-ff3l
{
 AdvSendAdvert on;
 MaxRtrAdvInterval 200;
 prefix fdc7:3c9d:b889:a272::/64 {
 };
 RDNSS fdc7:3c9d:b889:a272::2 {
 };
};

Damit die Änderungen wirksam werden, starten wir radvd neu:

$ service radvd restart

DNS-Proxy

Zur Auflösung von Hostnamen richten wir auf dem Gateway mittels dnsmasq einen DNS-Proxy ein, der eingehende DNS-Anfragen an von uns definierte DNS-Server weiterleitet. Wie zuvor installieren wir als erstes den Dämonen:

$ apt-get install dnsmasq

Die Konfiguration in /etc/dnsmasq.conf ändern wir wie im folgenden Absatz aufgeführt. Mit “bind-interfaces” und “interface=br-ff3l” zwingen wir dnsmasq lediglich an unsere Brücke br-ff3l zu binden. Das Loopback-Interface schließen wir mit “except-interface=lo” aus, um Konflikte mit einem bereits existierenden DNS-Server (z.B. bind9) zu vermeiden. Zum gleichen Zweck lassen wir dnsmasq mittels der Option “listen-address=127.0.0.2″ auf einer anderen lokalen Adresse lauschen. Die DHCP-Serverfunktion wird mittels “no-dhcp-interface=br-ff3l” deaktiviert. Die Option “domain-needed” bewirkt, dass Hostnamen ohne Domain nicht aufgelöst werden. Die Optionen “no-resolve” und “no-hosts” verhindern die Verwendung der DNS-Konfiguration unter /etc/resolv.conf sowie der Host-Einträge in /etc/hosts. Mit “cache-size=4096″ erhöhen wir die Zahl der im Zwischenspeicher gehaltenen Namenseinträge auf 4096. Log-Einträge leiten wir mittels “log-facility=/var/log/dnsmasq.log” in eine eigene Log-Datei um.

bind-interfaces
except-interface=lo
interface=br-ff3l
listen-address=127.0.0.2
no-dhcp-interface=br-ff3l
domain-needed
no-resolv
no-hosts
cache-size=4096
log-facility=/var/log/dnsmasq.log

Um die Konfiguration abzuschließen, tragen wir unter /etc/dnsmasq.d/rules noch die von uns favorisierten DNS-Server ein. Die Wahl erfolgt hierbei nach Gusto. Später werden wir in dieser Datei zusätzlich Einträge auf eigene DNS-Server aufnehmen, um Einträge unter diversen Freifunk-Domains aufzulösen. Für den Moment belassen wir es jedoch dabei, alle Anfragen auf externe DNS-Server über die noch einzurichtende VPN-Schnittstelle tun0 ins Internet weiterzuleiten.

# Forward DNS requests via wan-vpn
server=85.214.20.141@tun0 # FoeBud
server=213.73.91.35@tun0  # dnscache.berlin.ccc.de

Damit die Änderungen wirksam werden, starten wir dnsmasq neu:

$ service dnsmasq restart

OpenVPN-Verbindung

Um ausgehenden Netzverkehr zu anonymisieren (d.h. um die IP-Adresse des Gateways und damit unsere Identität zu verstecken), richten wir eine Tunnelverbindung zu einem VPN-Server ein. Entsprechende Tunnelverbindungen werden von zahlreichen Providern als Dienstleistung angeboten. In unserem Fall haben wir uns für CyberghostVPN entschieden. Nicht unbedingt der billigste Anbieter. Dafür hat man die Wahl zwischen einer Vielzahl von Serven, welche in der Regel recht performant sind. Die Verbindung zu CyberghostVPN-Servern erfolgt (unter anderem) mittels OpenVPN. Hierfür installieren wir als erstes das benötigte Paket:

$ apt-get install openvpn

CyberghostVPN bietet für OpenVPN-Verbindungen monolothische Konfigurationsdateien zum Download an, welche bereits alle Einstellungen und Schlüssel enthalten. Eine solche Konfigurationsdatei kopieren wir in das Verzeichnis /etc/openvpn unter dem Namen cyberghost.conf.

Um zu verhindern, dass sämtlicher ausgehender Verkehr über den VPN-Tunnel umgeleitet wird, entfernen wir in der Konfigurationsdatei den Eintrag

redirect-gateway def1

Aus dem gleichen Grund nehmen wir zusätzlich die folgende Zeile auf:

route-noexec

Um Fehlermeldungen zu vermeiden, sind die folgenden Zeilen zu entfernen:

dhcp-renew
dhcp-release

Da CyberghostVPN die Authentifizierung mittels eines Benutzernamens und Passworts verlangt, verweisen wir in der Konfiguration auf eine externe Datei, in welcher wir diese hinterlegen:

auth-user-pass ./cyberghost/cyberghost.secret

Zusätzlich konfigurieren wir ein Start-Skript, welches benötigt wird, um Manipulationen am Routing durchzuführen sobald die Tunnelverbindung steht:

up ./cyberghost/cyberghost-up

Nach Abschluss der beschriebenen Modifikationen sollte der Kopf der Konfigurationsdatei /etc/openvpn/cyberghost.conf in etwa wie folgt aussehen:

client
remote se.openvpn.cyberghostvpn.com 9081
dev tun 
proto udp
auth-user-pass ./cyberghost/cyberghost.secret
resolv-retry infinite 
persist-key
persist-tun
nobind
route-noexec
cipher AES-256-CBC
auth MD5
ping 5
ping-exit 60
ping-timer-rem
explicit-exit-notify 2
script-security 2
remote-cert-tls server
route-delay 5
tun-mtu 1500 
fragment 1300
mssfix 1300
verb 4
comp-lzo
up ./cyberghost/cyberghost-up

Wir legen als nächstes das Unterverzeichnis /etc/openvpn/cyberghost an:

$ mkdir /etc/openvpn/cyberghost

In diesem hinterlegen wir unseren CyberghostVPN-Benutzernamen und Schlüssel in der datei /etc/openvpn/cyberghost/cyberghost.secret. Die Dateiu enthält in der ersten Zeile den Benutzernamen und in der zweiten Zeile den Schlüssel. Die Datei sollte in etwa wie folgt aussehen:

CG7043533734
8jDDks,d003dD

Um unberechtigten Zugriff zu verhindern, beschränken wir den Zugriff auf den Besitzer der Datei (root):

$ chmod 600 /etc/openvpn/cyberghost/cyberghost.secret

Jetzt fehlt nur noch das Start-Skript. Dieses platzieren wir in der Datei /etc/openvpn/cyberghost/cyberghost-up. Die Befehle in der 2. und 3. Zeile richten in der Routing-Tabelle 42 eine Standardroute zum VPN-Server ein. Die Routing-Tabelle 42 regelt das Routing des über das Mesh-VPN eingehenden Verkehrs (siehe Konfiguration der bat0-Schnittstelle oben und der Firewall weiter unten). Die Adresse des VPN-Servers wird über den Platzhalter $5 übergeben. Danach starten wir mit “service dnsmasq restart” dnsmasq neu, so dass der Dämon die neue Netzwerkverbindung wahrnimmt und DNS-Server über den Tunnel anspricht.

#!/bin/sh
ip route replace 0.0.0.0/1 via $5 table 42
ip route replace 128.0.0.0/1 via $5 table 42
service dnsmasq restart
exit 0

Das Skript machen wir noch mit dem folgenden Befehl ausführbar:

$ chmod +x /etc/openvpn/cyberghost/cyberghost-up

Danach sind wir soweit, dass wir die Tunnelverbindung aufbauenkönnen:

$ service openvpn start

In Zukunft wird die Verbindung automatisch aufgebaut werden, wenn das Gateway hochgefahren wird. Nach kurzer Zeit sollte eine zusätzliche Netzwerkschnittstelle tun0 erscheinen (Abfrage mittels ifconfig). Sollte dies nicht der Fall sein, empfiehlt es sich die Log-Einträge unter /var/log/daemon.log zu überprüfen. OpenVPN-Verbindung automatisch überprüfen

Ein generelles Problem mit VPN-Verbindungen ist, dass diese abreißen können. In diesem Fall würde batman-adv nachwievor versuchen, den ausgehenden Internetverkehr über das Gateway weiterzuleiten. Der Grund hierfür ist, dass wir batman-adv im Zuge der Aktivierung mittels “batctl gw server” in den Server-Modus versetzt haben. Die betroffenen Pakete würden verloren gehen und die verbundenen Klienten wären vom Internet abgeschnitten. Um dies zu verhindern, legen wir in der Datei /usr/local/bin/check-gateway das folgende Skript an:

#!/bin/bash
INTERFACE=tun0      # Set to name of VPN interface
shopt -s nullglob

# Test whether gateway is connected to the outer world via VPN
ping -q -I $INTERFACE 8.8.8.8 -c 4 -i 1 -W 5 >/dev/null 2>&1

if test $? -eq 0; then
 NEW_STATE=server
else
 NEW_STATE=off
fi

# Iterate through network interfaces in sys file system
for MESH in /sys/class/net/*/mesh; do
 # Check whether gateway modus needs to be changed
 OLD_STATE="$(cat $MESH/gw_mode)"
 [ "$OLD_STATE" == "$NEW_STATE" ] && continue
 echo $NEW_STATE > $MESH/gw_mode
 echo 54MBit/54MBit > $MESH/gw_bandwidth
 logger "batman gateway mode changed to $NEW_STATE"

 # Check whether gateway modus has been deactivated
 if [ "$NEW_STATE" == "off" ]; then
  # Shutdown DHCP server to prevent renewal of leases
  service isc-dhcp-server stop 
  # Shutdown radvd daemon to prevent advertisment of server as gateway
  service radvd stop
 fi 

 # Check whether gateway modus has been activated
 if [ "$NEW_STATE" == "server" ]; then
  # Restart DHCP server and radvd daemon
  service isc-dhcp-server start
  service radvd start
 fi
done

Das Skript pingt über die OpenVPN-Schnittstelle tun0 den Google DNS-Server 8.8.8.8 an. Ist dieser nicht erreichbar, wird der Gateway-Modus in batman-adv über das Sys-Dateisystem deaktiviert. Zusätzlich deaktivieren wir den DHCP-Server und radvd-Dämonen. Klienten im Freifunknetz haben damit die Möglichkeit, sich einen alternativen Weg ins Internet zu suchen (d.h. über ein anderes Gateway). Umgekehrt wird der Gateway-Modus wieder aktiviert, sobald der DNS-Server erreichbar ist. Mit den folgenden Kommandos stellen wir sicher, dass das Skript allein von root ausgeführt werden kann:

$ chown root.root check-gateway
$ chmod ug+x check-gateway

Danach nehmen wir die folgenden Zeilen in die Datei /etc/crontab auf, um das Skript einmal pro Minute auszuführen und damit den Gateway-Status zu überprüfen.

# Check whether internet still reachable via openvpn tunnel
* * * * * root check-gateway > /dev/null

Die Änderungen übernehmen durch einen Neustart des Cron-Dämonen:

$ service cron restart

Firewall

Endspurt! Jetzt fehlt uns nur noch die Konfiguration der Firewall bevor wir am Ziel sind. Um die Firewall-Konfiguration permanent zu speichern, installiern wir zunächst das folgende Paket:

$ apt-get install iptables-persistent

Im Anschluss ersetzen wir den Inhalt der Datei /etc/iptables/rules.v4 mit dem folgenden Absatz. In der Grund-Konfiguration bleibt die Firewall komplett offen. Die Zahlenwerte in den eckigen Klammern sind Paket- und Byte-Zähler und können an dieser Stelle ignoriert werden. Für die Umleitung des ausgehenden Internetverkehrs über den VPN-Tunnel sind die PREROUTING und POSTROUTING Befehle unter *mangle und *nat entscheidend. Der Eintrag “-A PREROUTING -i br-ff3l -j MARK –set-xmark 0x1/0xffffffff” bewirkt, dass über die Brücke br-ff3l (und damit über das Mesh-VPN) eingehender Verkehr mittels der Ziffer 0x1 markiert wird. Die im Zuge der Kongifuration der bat0-Schnittstelle angelegte Routing-Regel (siehe oben) bewirkt wiederum, dass mit der Ziffer 0x1 markierter Verkehr gemäß der Routing-Tabelle 42 weitergeleitet wird. In dieser hatten wir eine Standardroute über den VPN-Tunnel definiert. Damit alle über den VPN-Tunnel ausgehende Pakete auch eine globale IP-Adresse aufweisen, aktivieren wir mittels “-A POSTROUTING -o tun0 -j MASQUERADE” das IP-Masquerading. Die Firewall ersetzt in der Folge lokale IP-Adressen aus dem Freifunk-Netz mit der globalen IP-Adresse des Gateways. Eingehende Pakete werde analog modifiziert, so dass sie ihren Weg zurück in das Freifunknetz finden. Wer sich durch die Details der Konfiguration arbeiten möchte, dem sei folgendes Howto empfohlen.

# Generated by iptables-save v1.4.14 on Sat May 10 00:21:44 2014
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -i br-ff3l -j MARK --set-xmark 0x1/0xffffffff
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o tun0 -j MASQUERADE
COMMIT
# Completed on Sat May 10 00:21:44 2014

Noch eine allerletzte Tat, damit die Regeln für die Umleitung auch greifen: Im Skript /etc/rc.local nehmen wir die Zeilen des folgenden Abschnitts auf, um das Routing für unzustellbare Pakete sowie über die Brücke br-ff3l eingehende Pakete (angezeigt durch die Markierung 0x1) gemäß Routing-Tabelle 42 zu aktivieren:

/sbin/ip route add unreachable default table 42
/sbin/ip rule add from all fwmark 0x1 table 42
exit 0

Nach der ersten Einrichtung starten wir das Skript manuell. In Zukunft wird es beim Hochfahren des Gateway automatisch ausgeführt werden:

$ /etc/rc.local

Abschluss

Damit sind wir eigentlich am Ziel. Um die aktuelle Konfiguration noch zu sichern, senden wir eine letzte Kommandozeile an etckeeper:

$ etckeeper commit "Configuration IntraCity VPN server completed."

Jetzt fehlen eigentlich nur noch die Clients. Im nächsten Artikel werde ich darüber berichten, wie sich Gluon konfigurieren und kompilieren lässt. Danach sind wir bereit für den Erstkontakt und es wird spanned!

...

Sollte alles wie beschrieben funktioniert haben, so seid ihr ab sofort stolzer Betreiber eines Gluon-Internet-Gateways! Ob das Gateway tatsächlich funktioniert, testet man am besten mittels eines Endgeräts, welches über einen Gluon WLAN-Router aufs Internet zugreift. Euer Gateway muss hierfür selbstverständlich vor der Kompilierung des Gluon-Images in der site.conf konfiguriert worden sein (siehe Gluon kompilieren). Sollte der Zugriff vom Endgerät aufs Internet nicht auf Anhieb funktionieren, empfiehlt es sich zuerst zu überprüfen, ob eine Verbindung des Routers über fastd zustande kommt. Im Anschluss sollte man überprüfen, ob der Router mittels DHCP eine IPv4-Adresse beziehen konnte und DNS-Server übermittelt wurden. Sollte dies alles einwandfrei funktionieren, so ist die Firewall-Konfiguration noch einmal gründlich zu überprüfen. Wir wünschen gutes Gelingen!